[.com原稿]饿了么业务的高速发展，给技术带来了海量请求、高并发、微服务等挑战。同时，开发团队快节奏的版本迭代和快速上线的需求，也带动运维团队提供稳定高效的运维服务。2017年12月1日-2日，由主办方主办的WOTD全球软件开发技术峰会在深圳中州万豪酒店隆重举行。饿了么技术运营负责人程艳玲与来宾分享了《跨界——饿了么的多直播运维搜索》主题演讲，从业务发展到多直播技术运营保障，结合具体案例，分享饿了么在运维方面的探索和实践经验。我是饿了么的技术运营负责人，见证了饿了么业务的快速发展。记得2015年加入饿了么的时候，我们的日订单量只有30万；到2017年，我们的日订单量已超过1000万。考虑到我们在整个市场的规模和单个机房最多只能处理2000万个订单的上限，我们逐步推进了最大冗余和多活的新计划。今天的分享主要分为三个部分：多直播场景和业务形态饿了么的运维挑战饿了么的操作系统多直播场景和业务形态的探索饿了么的现状首先介绍一下饿了么的整体情况。me多活现状：我们在北京和上海有两个机房，提供生产服务。机房和ezone是两个不同的概念。一个机房可以扩展多个ezone。当前，存在一对一的关系。我们在公有云也部署了两个接入点作为全国流量请求的入口。分别接受南北的部分流量请求，接入点都部署在阿里云上。同时，他们从运维容灾的角度出发。考虑到两个云入口同时“宕机”的可能性，我们准备在IDC内部搭建一个备份接入点作为容灾方案。从2017年5月第一次排练成功到现在，我们经历了16次整体多动切换。16次倒换包括正常演练和实际故障倒换。其中最近一次切换是因为我们上海机房的公网出口出现故障，我们把它的流量全部切换到北京。实施多元主动的背景。下面我从业务特点、技术复杂度、运维、故障频发、机房容量五个方面介绍一下多活实施前的一些背景情况。结尾。一个典型的下单流程是：用户打开APP生成订单，店铺在商家端接受订单，生成运单供物流配送服务。这个流程和传统电商订单的区别在于，如果在商城生成订单，后台的商家要等到第二天才能收到，这个延迟不是问题。但对饿了么不利。送餐的时效性非常高。如果商家在10分钟内没有收到订单，用户要么投诉，要么取消订单，换成美团或百度外卖。会造成用户流失。此外，我们还有很强的地方主义色彩。比如在上海产生的订单，一般只适用于上海本地，不会需要发往其他地方。与此同时，我们的业务也出现了明显的高峰。早上高峰一般在11点；而下午的高峰会在5点到6点之间。通过整个监控曲线，我们可以一目了然地看到整个链路的请求。这是我们公司乃至整个外卖行业的业务特点。复杂技术：上图展示了流量请求从进入到底层的整个技术架构。SOA（ServiceOrientedArchitecture）系统架构本身并不复杂。事实上，大部分互联网公司的技术架构都与上次演化类似。我们真正的复杂是各种组件、基础设施和整个访问层中存在多种语言。2015年之前，我们的前端是用PHP编写的，后端是用Python编写的。经过两年的演变，我们现在已经把所有用PHP语言写的都换掉了。为了适用于多种语言，我们的组件必须针对某种语言多做一次适配。例如：如果我们要追踪（trace）整个链路，使用多种语言，那么我们就得为它开发多个SDK，并且需要花费大量的资金去维护这些SDK。可见，复杂往往不在于我们有多少个组件，而在于我们需要为每个组件提供的维护。我们目前整个SOA框架体系主要是面向Python和Java两种语言，并逐渐向Java方向转变。APIEverythinginmiddle包含了很多针对不同应用场景开发的各种API项目。至于我们的基础设施，主要包括整个存储和缓存，还有公有云和私有云。运维背靠背信息：在业务快速发展的过程中，我们的运维团队还是做更多的“开箱即用”的工作。最后统计一下，我们现在有近16000台服务器，1600个应用，1000个开发者，4个物理IDC，2个部署了防御层的云。还有一些非常小的第三方云服务平台，包括AWS、阿里巴巴石塔。在业务增长过程中，我们基于整个IDC基础设施环境，统一定制交付模型，完善采购供应链，包括：标准化全柜交付和数据清洗。对于应用使用的数据库和缓存，我们也做了很多资源的拆分和改造，比如数据库，关键路径隔离的改造，垂直拆分，分片，SQL审计，接入数据库中间件dal，redis的治理cache，迁移了自研的redis集群代理corvus，结合框架实现了存储使用的标准化和服务化。我面临的最大挑战是数据库DDL。每个公司的表设计都有自己的特点。比如阿里巴巴和百度很少每周都做DDL。但是我们每周都有近三位数的DDL变更，这与项目文化和业务交付有关。DBA团队和DAL团队为此做了几件事：表数据量红线、改进的基于Gh-OST的在线schema变更工具、Edb自发布。这大大降低了数据库DDL事故率和变更效率。在多主动转型的过程中，工具的发展速度相对落后。在运维部署服务、组件的推广管理过程中，大部分还是人工推广管理。我们还负责整个网络的稳定性，以及故障管理，包括计划演练、故障发现、应急响应、事故恢复等，以及事故的损害评估和分级。故障管理不是追究责任，而是通过记录分析每一次故障的原因，并跟进改进措施，避免故障再次发生。我们还定义了一个全网稳定计数器来记录无重大事故的累计时间，并在故障等级达到P2或更高时将其清零。历史上我们保持网络稳定的最长记录是135天，而美团则超过了180天，还有一些差距。故障频发：根据上图“故障频发”反映的数据，可以看到2015年和2016年的数据惨不忍睹。按日计算，我们经常会发生P2以上的事故，最短的是每隔一天发生1起P2以上的事故。我们必须改进，所以我们组建了一个名为NOC（通知运营中心）的团队。这是基于GoogleSRE成立的7*24应急响应小组，以及初步的原因判断、例行演练的实施、审核的组织、后续的审核来改善落地情况。NOC定义了公司的一般故障等级和损害/责任标准：P0-P5事故等级，参考标准来自业务特征的四个维度，分别是：高峰/非高峰期的严重影响，包括损害的时间段以及损坏的持续时间。全网业务订单丢失率。损失金额。舆论的影响。包括与美团、百度外卖等平台的竞争。但是，不同于外卖食材的品质，我们这里讨论的是技术故障。例如，商家无故取消客户订单，或因其他各种原因，导致客户在微博或向客服投诉的数量增加。上述不同的维度，结合高峰期和低峰期的区别，就是我们分级的标准。根据各种事故操作分类/责任规范，我们建立了相应的故障排除SOP（标准操作程序），然后我们使用报表进行统计。除了故障次数，MTTR（平均恢复时间）也是一个重要指标。通过响应SOP，我们可以分析出某个故障本身的原因，是因为发现时间长，还是响应时间长，还是排查时间长。通过标准化的落地流程，根据报告中的MTTR，我们可以分析出故障发生后，是哪个环节耗时较长。谈到“频繁故障”，我们认为所有的故障，包括组件和底层服务器的故障，最终都会反映在业务曲线上。因此，我们NOC办公室有一个大屏幕来展示重要的业务曲线。当曲线趋势异常时，我们可以及时做出反应并通知相应人员。在订单高峰期，我们更注重时效性。即发生故障后，我们做的第一件事，或者说我们的目标是快速止损，而不是花时间去定位问题。这是我们实现多活的目的，多活就是以“续命”为我们的底线工作。原来我只有一间机房。如果这个机房的设施在工作高峰期出现故障，后果不堪设想。机房容量：我们来看一下整个机房的容量。2015年之前订单很少，我们的服务器分散在机房，型号比较随意。2015年，我们有大约1,500台服务器；2016年，我们增长到6000人；2017年，我们有将近16,000人。这些不包括云上ECS的数量。有过IDC相关工作经验的同学可能都知道，对于大公司的交付，合同往往是按模块来签的。但一开始，我们并不知道业务会发展得这么快。服务器与其他公司共享模块和机架，服务器老旧且不规范。同时，网络环境也非常复杂。甚至有一段时间，即使我们有钱买服务器，机房也没有扩容的余地。为什么你需要活得更多？总结起来有四个方面：容灾、业务扩展、单间容量、其他原因。如上图右侧所示，我们通过像X/Y轴这样的曲线进行评估。随着业务规模的增长，技术投入、业务拓展、故障损失不再是平行增长的关系。这么多现场运维挑战，你饿了吗？分享一下我们当时做了哪些运维规划，主要分为五个部分：多活技术架构IDC规划SOA服务改造数据库改造容灾保障多-主动技术架构我们设置既昆山可以分上海，又可以分苏州（这个跟行政区域无关，只跟外卖的配送半径有关）。因此，我们提出了geofencing的概念，开发了GZS组件。我们在GZS（globalzoneservice）服务上将全国的省市划分为地理围栏，将全国划分为32个分片。各个shard的请求进入系统后，GZS决定将请求路由到所属机房。如图底部所示，对于一些一致性要求比较强的数据需求，我们提出了Globalzone的概念。对于属于Globalzone的数据库，写操作仅限于一个机房，读操作可以在不同zone的localslave上进行。多活技术架构的五个核心组件：APIRouter：流量入口APIRouter，是我们的第一个核心组件，提供请求代理和路由功能。GZS：管理地理围栏数据和分片分配规则。DRC：DRC（Datareplicationcenter）数据库跨机房同步工具，支持缓存同步的数据变更订阅。SOA代理：在全活和非全活之间调用。DAL：本来就是数据库中间件。为了防止数据路由到错误的机房，造成数据不一致，配合多活项目做了一些修改。整个多活技术架构的核心目标是始终保证整个订单流程在一个机房内完成。为实现这一目标，开发了5大功能组件，并调研识别了强一致性的数据需求，并进行了整体规划和改造。IDC计划于2016年底启动多活项目，确定了南北两个机房，以及流量入口，开始选择IDC模式，考察了上海多家IDC公司，最终选择了IDC机房。同时结合抗100%流量服务器预算，提交采购部采购需求。规划多活联调测试环境，模拟双ezone生产，划分vpc，同时升级业务。如上图右侧所示，以两种不同的流量为例，从不同区域通过接入层进来的流量对应北京和上海不同的机房。一般情况下，整个下单过程也会在这个区域的机房进行。进行处理，同时在必要时能够相互转移。SOA服务改造我们也对SOA服务注册中心发现做了一些改造工作。先说一下multi-active之前的情况。一个应用服务AppId上线，物理集群环境准备好，SOA注册时对应一个SOA集群。在其他大型集群中，不同的业务调用被划分到不同的通道中，这些通道在应用发布时定义在不同的应用集群上。这就是整个AppId部署的逻辑。这对于单机房来说很简单，但是在双机房场景下，需要转化为相同的AppId，只调用本地机房的SOA集群。我们在廊道和集散集群概念的基础上引入类似于单元的ezone。SOA模式改造方案，包括以下三种模式：Orig：兼容模式，默认的服务注册发现方式。前缀：撤销服务注册的方式，统一SOA服务注册。这种模式主要是针对我们很多新推出的多活应用。对于一些老牌商家，依然默认使用Orig模式。Route：这是回收SOA服务调用的最终模式，进一步实现统一SOA的服务注册发现。整个IDC、ezone、运维架构等信息对业务方透明，从而减少业务方对SOA的维护工作量。数据库改造是按照之前对整个应用部署的划分，即多活、非多活、强一致的全局zone来规划的，数据库也相应规划。我们先后进行了业务数据一致性研究、复制一致性规划、多活集群通过DRC进行双向复制改造、globalzone使用nativeReplication。具体改造分为三个部分：数据库集群改造，根据倒置期的时间点，指派专人跟进，将整个流程拆分成详细的操作方案。改造数据库中间件DAL，增加校验功能，保证SQL不会写错机房。实现了数据写入错误保护，并增加了自下而上的保护。DRC改造，改造过程两地多活实例之间的DRC复制。容灾保障容灾保障分为三个不同的等级：流量入口故障、常见DNS解析变更、网络出口故障、省市骨干线路故障、AR故障。IDC内部的故障包括变更发布失败、历史错误触发、错误配置、硬件故障、网络故障和容量问题。单人间完全不能用。它还没有完全实施，但我们现在正在做一个断开连接的练习。模拟某机房内所有Zone因不可抗力宕机，保证该机房内的所有应用都能切换到另一机房继续保证服务的可用性。当然，这并不能从根本上解决双机房同时出现故障的情况。当两个机房同时出现问题时，我们还是要依靠经验丰富的工程师和我们的自动化故障定位服务。饿了么的运营体系在饿了么运维转型的全过程中探索如何将组织能力转化为运营能力？以下是我们的五个想法：应用发布监控系统预案和钻孔能力规划单间成本分析应用发布首先让我们看一下应用发布。单机房情况下，一个AppId对应一个或多个SOA集群。同时，运维会配置灰度机群，要求关键应用灰度30分钟。那么在多活的情况下，应用如何发布呢？我们在规划上采用了两种方案：将所有区域视为一个大“集群”，按照灰度机群的发布策略。我们先在单个机房做灰度，然后扩展到所有分区，保证每个关键应用都遵循灰度大于30分钟的规则，最后扩展到所有分区。将单个区域想象成一个“集群”，有多少个区域就有多少个“集群”。首先是灰度zoneA和全zoneA，然后是灰度zoneB和全zoneB。或者可以先灰度zoneA和灰度zoneB，然后同时观察验证发布状态，然后全量部署zoneA，全量部署zoneB。大家可以根据自己的情况选择实施。监控系统饿了么目前拥有三大监控系统：全链路监控。Agent启动时读取一个文件，知道自己当前在哪个zone，然后在metric中的ezoneid加上tag，进行指标聚合。默认情况下，一个机房可以有多个zone。业务监控。在分机房部署，调用statsd到各自机房，检查时切换DataSource。基础设施监控。对于服务器和网络设备监控，无需区分ezone，通过主机链接查询。预案与演练制定常见故障预案，制定例行演练计划，定期进行演练。目前我们也在做排练系统，上线后应该会有更好的效果。容量规划关于容量规划（Capacityplanning），我们目前只收集AppId的服务器CPU使用率。结合两地现有机房归一化负荷应为：北京片区承载52%的流量；而上海机房占股48%。一般情况下，每周三都会进行一次全链路压测。通过评估，我们可以知道整个关键路径的容量。未来我们还会假设如果流量再增加15%，我们需要在现有AppId的基础上增加服务器数量。同时，在承载现有订单数的基础上，我们需要估算现有单个SOA集群所能承载的订单请求的极限。如上图所示，通过获取AppId使用率统计列表，我们可以发现，由于前期业务的爆发式增长，我们不计成本购买的服务器使用率其实是比较低的。单台机房成本分析对于现有的IDC成本核算，按照一定的折旧标准分摊到每个月，并与业务中单月整体完成的订单进行比较，最终计算出每个订单的IT成本，以及计算每个内核的成本。此外，我们还可以将其与租用云服务的成本进行对比，从而了解成本的优劣。对于一些公共池化资源，将各种池化组件服务分配给每个部门和每个AppId。这指导每个AppId使用多少台服务器，IT成本是多少，然后我们可以做进一步的成本分析。饿了么现任技术运营负责人程艳玲，从数据库到运维，再到技术+运营。目前主要负责饿了么数千个AppId的运维、IDC建设和稳定性保障。2015年加入饿了么，两年来，他经历了饿了么规模和技术的蓬勃发展，在挑战和困难面前陪伴技术运营团队成长。作为一个10多年运维的老手，希望把故事分享给大家，也期待和大家一起学习交流。【原创稿件，合作网站转载请注明原作者和出处为.com】
