互联网多活技术架构及运维饿了么多活系统架构饿了么业务快速发展，给技术带来了海量请求和高并发、微服务的挑战，同时开发团队快节奏的版本迭代和服务快速上线的要求也驱动运维团队提供稳定、高效的运维服务。

我是饿了么的技术运营负责人，见证了饿了么业务的飞速发展。

记得2015 年加入饿了么的时候，我们的日订单量只有30 万笔；而到了2017 年，我们的日订单量已经超过1000 万笔。

考虑到我们在整个市场的体量和单个机房至多只能处理2000 万笔订单的上限，我们逐步推进了面向百分之百冗余多活的新规划。

今天的分享主要分为三个部分：•多活场景及业务形态•饿了么多活运维挑战•饿了么运营体系探索多活场景及业务形态饿了么多活的现状首先介绍一下饿了么整个多活的现状：我们在北京和上海共有两个机房提供生产服务。

机房和ezone 是两个不同的概念，一个机房可以扩展多个ezone，目前是一对一关系。

我们还有两个部署在公有云的接入点，作为全国流量请求入口。

它们分别受理南北方的部分流量请求，接入点都部署在阿里云上面，同时从运维容灾角度出发。

我们考虑到两个云入口同时“宕掉”的可能性，正在筹建IDC 内的备用接入点，作为灾备的方案。

多活从2017 年 5 月份的第一次演练成功到现在，我们经历过16 次整体性的多活切换。

这16 次切换既包含正常的演练，也包含由于发生故障而进行的真实切换。

其中，最近的一次切换是因为我们上海机房的公网出口发生了故障，我们将其所有流量都切换到了北京。

实现多活的背景下面我从五方面介绍实施多活之前的一些背景状况：•业务特点•技术复杂•运维兜底•故障频发•机房容量业务特点：我们有三大流量入口，分别是用户端、商户端以及骑手端。

一个典型的下单流程是：用户打开App 产生一个订单，店家在商户端进行接单，然后生成一个物流派送服务的运单。

而该流程与传统电商订单的区别在于：如果在商城生成一个订单，后台商户端可以到第二天才收到，这种延时并无大碍。

但是对于饿了么就不行，外卖的时效性要求很高，如果在10 分钟之内商户还未接单的话，用户要么会去投诉，要么可能就会取消订单，更换美团、百度外卖，从而会造成用户的流失。

另外，我们也有很强的地域性。

比如说在上海生成的订单，一般只适用于上海本地区，而不会需要送到其他地方。

同时，我们的业务也有着明显的峰值，上午的高峰，一般在11 点；而下午则会是在5 点到 6 点之间。

我们通过整个监控曲线便可对全链路的请求一目了然。

这就是我们公司乃至整个外卖行业的业务特点。

技术复杂：上图是流量请求从进入到底层的整个技术架构。

SOA（面向服务的体系结构）系统架构本身并不复杂，其实大部分互联网公司的技术架构演进到最后都是类似的。

我们真正的复杂之处在于：各种组件、基础设施以及整个的接入层存在多语言的问题。

在2015 年之前，我们的前端是用PHP 写的，而后端则是Python 写的。

在经历了两年的演进之后，我们现在已把所有由PHP 语言写的部分都替换掉了。

而为了适用多种语言，我们的组件不得不为某一种语言多做一次适配。

比如说：我们要跟踪（trace）整个链路，而且用到了多种语言，那么我们就要为之研发出多种SDK，并需要花大量的成本去维护这些SDK。

可见，复杂性往往不在于我们有多少组件，而是我们要为每一种组件所提供的维护上。

我们当前的整个SOA 框架体系主要面向两种语言：Python 和Java，逐渐改造成更多地面向Java。

中间的API Everything 包含了许多为不同的应用场景而开发的各种API 项目。

而我们基础设施方面，主要包括了整个存储与缓存，以及公有云和私有云。

运维兜底：在业务飞速发展的过程当中，我们的运维团队做得更多的还是“兜底”工作。

最新的统计，我们现在有将近16000 台服务器、1600 个应用、1000 名开发人员、4 个物理IDC、以及部署了防护层的两朵云。

也有一些非常小的第三方云服务平台，包括AWS 和阿里聚石塔等。

在业务增长过程当中，基于整个IDC 的基础设施环境，我们对交付的机型统一定制，并且改进了采购的供应链，包括：标准化的整机柜交付和数据清洗等。

对于应用使用的数据库与缓存，我们也做了大量的资源拆分与改造工作，比如数据库，改造关键路径隔离，垂直拆分，sharding，SQL 审核，接入数据库中间件dal，对缓存redis 使用治理，迁移自研的redis cluster 代理corvus，联合框架实现存储使用的规范化，服务化。

曾经面临比较大的挑战是数据库DDL，表设计在每家公司都有一些自己的特点，例如阿里、百度他们每周DDL 次数很少。

但是我们每周则会有将近三位数的DDL 变更，这和项目文化以及业务交付有关。

DBA 团队以及DAL 团队为此做了几件事情：表数据量红线，基于Gh-OST 改进online schema change 工具，Edb 自助发布。

这样大大减少了数据库DDL 事故率以及变更效率。

在多活改造过程中，工具的研发速度相对落后，我们在运维部署服务，组件的推广和治理过程中，大部分都还是人工推广、治理。

我们还负责全网的稳定性，以及故障管理，包括预案演练、故障发现、应急响应、事故复盘等，以及对事故定损定级。

故障管理并不是为了追责，而是通过记录去分析每一次故障发生的原因，以及跟进改进措施，避免故障再次发生。

我们还定义了一个全网稳定性计数器，记录未发生重大事故的累计时间，当故障定级应达到P2 以上时清零重新开始。

历史上我们保持最长的全网稳定性纪录是135 天，而美团已经超过了180 天，还有一些差距。

故障频发：根据上图“故障频发”所反映的数据，大家可以看到，2015 年和2016 年的数据惨不忍睹。

按天计算，我们经常会出现P2 级别以上的事故，最短的是隔 1 天就出现 1 个P2 以上事故。

我们不得不进行改进，于是我们组建了一个叫NOC（Notification Operation Center）的团队。

这个是参照Google SRE 所建立的负责7*24 应急响应团队，以及初步原因判断，执行常规的演练，组织复盘，跟进复盘改进落地情况。

NOC 定义公司通用故障定级定损/定责的标准：P0—P5 的事故等级，其参照的标准来自于业务特性的四个维度，它们分别是：•在高峰期/非高峰期的严重影响，包括受损时间段和受损时长。

•对全网业务订单的损失比。

•损失金额。

•舆情的影响。

包括与美团、百度外卖、其他平台的竞争。

不过区别于外卖食材的本身品质，我们这里讨论的是技术上的故障。

比如商家无缘无故取消了客户的订单，或是由于其他各种原因导致客户在微博、或向客服部门投诉的数量上升。

上述这些不同的维度，结合高峰期与低峰期的不同，都是我们定级的标准。

根据各种事故运营定级/定责的规范，我们建立了响应的排障SOP（标准操作流程），进而我们用报表来进行统计。

除了故障的次数之外，MTTR（平均恢复时间）也是一个重要的指标。

通过响应的SOP，我们可以去分析某次故障的本身原因，是因为发现的时间较长，还是响应的时间较长，亦或排障的时间比较长。

通过落地的标准化流程，并且根据报表中的MTTR，我们就可以分析出在发生故障之后，到底是哪个环节花费了较长的时间。

提到“故障频发”，我们认为所有的故障，包括组件上的故障和底层服务器的故障，都会最终反映到业务曲线之上。

因此我们NOC 办公室有一个大屏幕来显示重要业务曲线，当曲线的走势发生异常的时候，我们就能及时响应通知到对应的人员。

在订单的高峰期，我们更讲求时效性。

即发生了故障之后，我们要做的第一件事，或者说我们的目标是快速地止损，而不是去花时间定位问题。

这就是我们去实现多活的目的，而多活正是为我们的兜底工作进行“续命”。

原来我只有一个机房，如果该机房的设施发生了故障，而正值业务高峰期的时候，后果是不堪设想的。

机房容量：我们再来看看整个机房的容量，在2015 年之前，当时订单量很少，我们的服务器散落在机房里，机型也比较随意。

而到了2015 年，我们大概有了1500 台服务器；在2016 年间，我们增长到了6000 台；2017 年，我们则拥有将近16000 台。

这些还不包括在云上的ECS 数量。

有过IDC 相关工作经历的同学可能都知道：对于大型公司的交付，往往都是以模块签的合同。

但初期我们并不知道业务发展会这么快，服务器是和其他公司公用模块和机架，服务器也是老旧而且非标准化，同时组网的环境也非常复杂。

甚至有一段时期，我们就算有钱去购买服务器，机房里也没有扩容的空间。

为什么要做多活为什么要做多活，总结一下有四个方面：容灾续命、服务扩展、单机房容量、和其他的一些原因。

如上图右侧所示，我们通过一个类似X/Y 轴的曲线进行评估。

随着业务规模的增长，技术投入，服务扩展，故障损失已不是一种并行增长的关系了。

饿了么多活运维挑战下面分享一下我们当时做了哪些运维的规划，主要分为五个部分：•多活技术架构•IDC 规划•SOA 服务改造•数据库改造•容灾保障多活技术架构我们通过设置既可把昆山划分到上海，又可以划到苏州（这与行政区无关、仅关系到外卖的递送半径）。

因此我们提出了地理围栏的概念，研发了GZS 组件。

我们把全国省市在GZS（globalzone service）服务上区分地理围栏，将全国分成了32 个Shard，来自每个Shard 的请求进入系统之后，通过GZS 判断请求应该路由到所属的机房。

如图最下方所示，对于一些有强一致性需求的数据要求，我们提出了Global zone 的概念。

属于Global zone 的数据库，写操作仅限于在一个机房，读的操作可以在不同zone 内的local slave 上。

多活技术架构五大核心组件：•API Router：流量入口API Router，这是我们的第一个核心的组件，提供请求代理及路由功能。

•GZS：管理地理围栏数据及Shard 分配规则。

•DRC：DRC（Data replication center）数据库跨机房同步工具，同时支持数据变更订阅，用于缓存同步。

•SOA proxy：多活非多活之间调用。

•DAL：原本是数据库中间件，为了防止数据被路由到错误的机房，造成数据不一致的情况，多活项目中配合做了一些改造。

整个多活技术架构的核心目标在于：始终保证在一个机房内完成整个订单的流程。

为了实现这个目标，研发了 5 大功能组件，还调研识别有着强一致性的数据需求，一起从整体上做了规划和改造。

IDC 规划在2016 年底启动多活项目，确定了南北两个机房，以及流量入口，开始进行IDC 选型，实地考察了几家上海的IDC 公司，最终选择了万国数据机房。

同时结合做抗100% 流量服务器预算、提交采购部门采购需求。

规划多活联调测试环境，模拟生产双ezone、划分vpc，以及最后的业务同期改造。