不知不觉已经写到了最后一部分，回顾经历的这段架构演进历程，内心还是非常感慨。在商业竞争中，技术团队和其他团队一样，作为组织的一部分，应该是荣辱与共的。但是，就行业而言，饿了么创造的社会价值也是显而易见的，而且，饿了么塑造了这个行业最初的模样，对社会创造的价值影响是长远的。
这个阶段，技术体系承担了日均千万级的单量，通过建设多数据中心的技术体系，提供了数据中心节点跨地域水平展开的能力，从根本上解决了扩展性的问题。为业务发展提供足够的系统容量保障。同时，架构演变到了Cloud-Ready的状态，也为我们技术体系演进提供了更多可能性。
这个阶段我们面临的是前所未有的挑战，架构也因此迭代到了全新阶段
1、数据中心容量到达上限，如何避免成为业务发展的瓶颈2、两次大规模组织融合，技术体系如何融合3、全面上云后技术体系如何演进
2017年5月，建成了多数据中心的技术体系。后面很多看起来轻而易举的事情——午高峰线上故障容灾、全面上云、全站底层容器及调度系统的升级等等——没有这次架构演进将会很艰难。
高可用：多个数据中心节点解决了单点问题。
性能和扩展性：通过部署在不同地域的节点，解决了两个问题。
水平扩展能力：理论上可以在任何的地域拉起数据中心节点，解决业务快速发展带来的容量压力，从而解决性能瓶颈。具备多数据中心能力的架构，可以看作广义的分布式体系。
用户有地域分布的特征业务对可用性和弹性扩展能力有很高的要求
数据必须集中处理业务没有按地域分布的特征要求强一致、不能接受系统环境的不确定性、系统不具备弹性的架构体系架构非常简单、业务量很小，分布式节点和冗余没有带来太多收益
主备：通常的同城双中心，在一个地理位置上相近的区域（比如云上的一个region内），建立起两个数据中心（比如云上的availabilityzone），组成一个虚拟的数据中心，流量按照一定策略负载均衡到两个数据中心。无状态的服务，或者只读的请求，通过负载均衡策略，可以同时分发到两个数据中心处理，这个场景下，但是涉及到写请求只能在一个数据中心处理。存储服务的主节点故障会触发主备切换，写操作由另一个数据中心的节点承担。容灾为主，扩展性稍差，两个数据中心的时延要求严格，所以不能太远（通常同城），极端情况下，region故障，或者region容量达到上限，会比较被动，优点在于改造起来简单。
对等：跨区域部署的，基于地理位置的“分布式”数据中心。数据中心之间没有主次，可互为容灾对象，理论上可以水平扩展到更多节点。通常数据中心会部署在不同区域（云上的不同region），容灾能力和扩展能力都更强，缺点在于改造成本和对中间件等基础设施的要求高。
混合：更适合多数据中心建设从主备演进到对等模式后的形态
为什么不采取同城双中心？如果仅仅是为了容灾，那可能也足够了，但是，加上扩展的需求就有问题。我们的数据中心，消耗资源最多的并不是承担业务逻辑的SOA服务类应用，算力消耗的大户实际上是基础设施中间件——消息队列、分布式缓存、监控体系、各种类型的数据库等等。同城双中心主备的架构，写操作只能在一个机房，比如数据库等只能是主/备，写操作是没有办法充分利用多数据中心的优势水平扩展的，如遇到单机房容量瓶颈，比较被动。
多数据中心建设架构选型还是要依据自己的业务特点，综合考虑到系统的现状、能承担的冗余成本、以及业务规划，选择适合的架构。
多数据中心可以水平扩展的前提是，各个数据中心之间需要解耦，从用户端发起请求开始，一笔交易内的调用链封闭在当前数据中心完成，尽量减少跨数据中心的RPC请求。与此同时，还要求数据中心之间互为容灾的角色。依赖两个组件解决这个问题：Datareplicationservice和Gateway。
上海数据中心上线切流成功的那一天，我们心里面还是没底，担心数据同步出错。系统挂了可以恢复，各数据中心节点间数据发生不一致的话，数据订正的成本很高。多数据中心架构实施后的几年里面，发生过一次DRC（我们的数据复制服务）变更引入的bug，导致同步出错，好在影响的数据库实例范围可控，但是仍然花了一个通宵订正数据。如果是大规模出问题，后果不堪设想，技术团队可以下课了。
和领域服务解耦之后，通过支持mock，开发阶段前端不需要等待后端交付就可以完成初步调试。用户端上接口契约发生变化，如果不涉及到领域数据的变化，后端领域服务不需要变更，调整webapi层就可以；反过来，后端的重构，只要端上接口契约不变，WebAPI这一层配置更改即可。
和APIgateway不同的是，这一层需要处理body。有些解决方案支持以AOP的方式自动生成RESTfulAPI，以java为例在领域服务代码中，通过annotation把领域服务变成同时支持WebAPI的方式，虽然便利，实际上把领域服务和面向端的RESTfulAPI耦合在一起了，而且想要支持多个服务聚合也比较困难，所以我们没有采取这一方式。各业务线的前端团队，通过配置策略就可以交付这一层的需求。而这一层作为中间件，运维则由大前端团队完成。
大前端团队则演变成一个全栈的开发团队，Java/Go/Node.js/Javascript是他们的主要技术栈。
这个组件的历史，要追溯到2016年的第一次517大促，在517之后，我们构建了大促体系，这个网关就是产物之一，我们当时需要在网关层通过cache-control植入缓存策略，同时需要一些灵活的、细粒度限流策略，包括支持plugin来扩展网关的功能，更有意义的是，我们将网关前移到数据中心之外——云上了，这一层是大促流量冲击的第一层（除了云厂商提供的流量清洗和软负载以外），因此需要有足够强的水平扩展能力。
多数据中心环境下，很多设计上本来就存在的缺陷会更容易暴露出来。举个例子，假如一些领域逻辑没有收口，比如订单，多个系统冗余了订单数据，这个时候，在订单状态变更过程中，发生了切流，各个订单数据的副本由于在不同的数据库中，同步延时是不一致的，会造成下游系统和交易系统的订单状态冲突，下游的履约逻辑无法继续推进。另一个例子，就是缓存，如果把缓存当持久化存储，认为缓存不会丢，不考虑大量击穿缓存对数据源的冲击，那么在切流的时候，也会造成大麻烦。还有，如果缓存设置太长的TTL，或者没有TTL，那么流量切回（FailBack）的时候，就会访问到不新鲜的数据。再比如Session，如果采取的是SessionAffinity的机制，那么切流后会导致大量用户登出。
这就是为什么需要Anti-Fragile的设计，要求我们的应用的设计尽量遵循Disposable、Stateless和ShareNothing的原则。
早期我们是基于HAProxy来做负载均衡代理，访问数据库、队列这些后端资源，这套架构依赖运维工程师频繁介入维护，在系统规模比较小的时候，是够用的。随着业务的发展，我们集群变得越来越大，应用服务日渐增多，上下游节点的扩缩容变得频繁，与此同时，快速迭代和变更带来系统抖动也越来越多，对系统的弹性要求也更高了，尤其是全面容器化后，stateless的节点发生故障随时拉起重建，需要相应的注册和发现机制，再加上多套环境，这个架构体系已经力不从心。为了应对这系列新问题，我们的解决方案是内部称之为namingservice的体系。负责rediscluster代理corvus的那支中间件团队，他们贡献的一个组件Samaritan（简称sam），起到了至关重要的作用。这个体系也成为为我们架构演进的开端。
这套体系需要sidecar，正好我们手上有sam，所以就改一改用上了。它保障了我们后来多数据中心架构得以顺利实施，快速上线。现在回过头来看，勉强算是mesh的雏形，namingservice体系，跟现在类似istio强大而复杂的控制面和数据面相比不可同日而语。不过，基于这套架构体系，演化到ServiceMesh，也顺理成章。
还有一类应用是scheduledjob，包含两部分，一个是job引擎，一个是service。我们的job引擎本身是一个工作流引擎（eworkflow），eworkflow负责按照配置的规则触发对service的调用，service负责业务逻辑的实现，避免job单点的同时，充分利用service集群可以水平扩展的运算能力。
一个常见的应用场景是批量处理数据，我们的多数据中心架构下，每个数据中心有全量的数据(failover的考量)，所以Job所调用的服务需要支持数据的过滤，只处理归属当前数据中心的数据；另一类场景就是消费队列消息，调用service进行处理，这类场景在对消息的顺序没有要求的情况下，可以利用集群的吞吐能力增强消费能力。
DAL层在多数据中心建设中，主要是纠偏的作用，非当前数据中心的写入请求会被拦截，确保同一个时刻一条数据只会在一个数据中心写入，避免数据冲突。数据持久化前，打上的数据分片标签也是由DAL层植入，数据所属的分片是不变的，但是分片归属（可写入）的数据中心是可以动态变化的。DAL的开发团队，还负责了另一个核心的系统——GlobalZoneServce(GZS)，这个系统负责流量路由规则的下发和订阅管理，以及failover流量切换的控制中心，网关和DAL所执行的容灾操作均来自于GZS的指令。
有一次午高峰，从监控面板上看很多核心业务指标掉了一半，手机上报警推送声音此起彼伏，但是线下运营团队、线上舆情、客服投诉都没有任何反馈，我们正在评估是否需要启动failover流程的时候，负责监控系统的同学说，监控系统有几台机器挂了——看来监控系统也需要监控——好在有。
1、将其包装在返回值里面，不作为异常；
2、包装为异常抛出（当然生成stacktrace，会损失一点点性能）；这类“业务异常”每时每刻都在发生，如果非常多就会使所谓的“系统异常”——比如timeout、NPE、serviceunavailable这类需要引起重视的异常被淹没。内部也发生过激烈的讨论，险些引发“圣战”。不管采取上面哪种方式，这个时候都需要采取措施降噪，投入对告警的治理。
前面提到第一次517大促，全链路压测团队建立起来了，并在一系列大促及日常容量保障，多数据中心建设中起到至关重要的作用。在每个发布窗口，通常有数以百计的发布变更，系统容量是动态变化的，如何确保整体容量保持在健康水位？多数据中心架构体系下，如何保障发生failover的时候，剩余的数据中心能够承担切换过来的流量？新建数据中心能否达到容量预期？系统关键路径的瓶颈在哪？大促到来的时候，会场和营销流量是否会冲击到午、晚高峰的常规业务？没有全链路压测，这些风险都无法识别。
涉及到全链路压测的时候，很多人都认为，为了不影响生产，可以在测试环境完成。以我们的经验，这样测试出来的结果，参考价值不大。因为随着业务达到一定体量，系统到一定复杂度以后，调用链路很长，频繁的需求迭代，导致涉及到的上下游服务容量是动态变化的，每次全链路压测的瓶颈都会发生变化。这些都没有办法在测试环境等比例缩小模拟出来。
测试数据和生产的隔离，测试数据标签的全链路传递识别，避免测试数据在生产环境透出，避免测试数据进入大数据的离线计算中完善的监控体系，压测过程中发现系统瓶颈。如果影响到线上，及时发现，停止压测具备弹性的系统，压测过程中一旦出现故障，压测停止后，系统能迅速自愈自动化压测平台，是全链路压测能够周期性执行的基础全链路压测的常态化，定期压测，能及时发现系统瓶颈隐患最重要的就是一个自动化测试团队，这个团队除了要了解业务，构建起全链路测试的testcase，设计测试方案，还要熟悉中间件，了解系统部署的拓扑结构，识别链路瓶颈，具备较强的开发能力，搭建全链路自动化压测体系。
在线上执行的是loadtest，目的是评估容量是否达到预期，而不是为了压出系统极限的stresstest。有必要选择在业务低谷时段压测。
一个外部渠道的下单曲线出现抖动，短时无法恢复，虽然在全局上看该渠道单量占比无足轻重的业务，却启动了全站failover流程，结果，故障扩散到了所有数据中心，变成了一个耗时很长才恢复的全局事故。在切流的过程中是有损的，启动全站failover本身就是高风险的过程，不得不启动流程止损的时候，往往发生在业务高峰，那么，承接流量导入的数据中心，在原有流量的基础上，除了会叠加来自于故障数据中心常规流量的冲击，还有来自于系统逐步恢复过程中用户重试、系统重试的冲击，从监控曲线上，很多应用的QPS曲线会出现类似秒杀场景的瞬时尖刺，这对任何系统而言都存在很大的不确定性。因此，应该是在出现重大故障的时候采取的最后手段，是为了防止出现灾难性的后果，因此，在启动failover流程前，需要两害相权取其轻，如果当前的风险远远小于切流带来的风险，那就不能盲目启动，所以，决策需要有相应的SOP和合理的评估标准作为依据，更重要的是坚持这些标准后面的原则和初衷，否则很容易被各种因素干扰，系统发生抖动的时候决定不启动failover流程有时候要承担更大的压力。下图为failover切流过程中的业务曲线.
在多数据中心的架构下，定期做流量切换还有一个作用就是验证各数据中心的容量，确保能承接failover切换过来的流量叠加。
百度外卖的融合，从一开始把零售和物流研发从上海交到原百度外卖在北京研发团队主导负责到后面的调整融合，我们也经历了不少曲折。
1、同城零售体系和外卖之间相对而言，在业务上是两个相对独立的领域，从业务形态和发展阶段来看，两个业务都有不少差异，零售需要更多探索和试错的空间，系统需要更多的自主和灵活性。
2、物流技术体系交到北京原百度外卖研发团队负责主导之后，有一个组织结构调整就是技术团队分成专送和众包两条业务线，众包交由原百度外卖北京的研发团队负责，专送则继续由上海的团队负责。后来，花了不少功夫来解决众包稳定性的问题，交付效率也受到了掣肘，这个过程中，众包系统经历了两次重写。
物流组织结构调整后，技术团队分成了专送和众包两个部门。这里说明一下背景，即时配送运力主要分四类：一类是专送，由饿了么平台主导的线下配送团队；第二类是众包，是个人经过审核后，在平台上注册成为骑手，第三类是三方配送公司提供运力，通过开放平台对接；第四类是商家自配送，商户自己解决配送问题。融合过程中，众包的开发团队选择了在百度云上重新搭建一套众包体系。
结果是，增加了一系列冗余的系统和数据。百度外卖云上系统和饿了么融合之初是两套体系，而且数据中心也分布在不同的地域及不同的云厂商。众包运力离不开对上下游的依赖，为此，要在百度云上搭建起众包系统，不得不冗余很多上游运单中心的数据，甚至一些主数据也冗余维护了一套。到了后期，相当于出现了两个物流系统，其中有很多冗余重复的部分。
这个不合理的系统架构和技术团队组织结构按照专送和众包切分有着很大的关系。众包是运力的一种，而不是独立的物流体系，只是配送任务的承接方，因为它和其他运力一样共享上游的运单系统、分流系统、还有包括地理围栏在内的众多主数据系统。因为专送和众包两个部门的划分方式，使得本来是两个运力形态演变成了两个物流系统。除了系统冗余以外，团队膨胀的速度，也超过了物流业务量整体增长的速度，仅仅因为单量在各运力形态的占比发生了变化：占比变多的某一个运力线，需求、数据量等等相对增多；而其他的运力形态业务占比降低，则相对会更少一些，但是物流整体的业务量的变化是远小于某一个运力线的占比变化幅度的。
而这类运力形态之间的占比关系不是一尘不变的，会动态发生变化。不能因为这个因素，频繁的扩张或者收缩团队。合理的拆分是按照运单、分流调度、运力等等领域切分，每个团队的业务都会涉及到专送、众包、第三方等所有运力形态，各领域收口自己的系统和数据，减少了数据和系统的冗余，同时，也不会因为单量比例在各运力之间发生变化，导致有些团队需求激增，人员膨胀，另一些团队人员冗余的局面。按照这一原则，调整组织架构，系统架构也随之调整，按领域划分，合并同类项。
组织结构和系统架构互为促进互为掣肘，技术团队组织结构的调整，伴随着技术体系和整体架构向前演进或倒退。
随着各系统的交互越来越频繁，为了降低日渐增加的复杂度和冗余成本，百度云上的外卖系统最终完成了技术融合。
辗转腾讯、百度、阿里多个云厂商，当时我们都是云上最大的（外部）业务方，还不包括少部分系统在上面的其他云厂商。5年多里面，跟随着国内云厂商的成长，我们也从部分依赖云，到逐步采用云上体系构建所有系统。对于上云企业而言，表面上云的优势在于规模带来的平均硬件成本、维护成本的降低，但是，这不意味着云上搭建系统付出的费用，一定就比自建付出的硬件成本外加工程师的人员成本要低。成本里面影响的因素很复杂，比如某些具体云上产品的规模、成熟度、硬件成本等等。
业务系统从一开始就在云上构建，优势在于：
2、云上IaaS、PaaS后面负责运营的工程师、架构师，集中了在各大小技术公司中，被各种线上事故反复毒打过的一批人。小到MySQL、Redis这类单个应用系统层面微观的基础设施，大到Kubernetes和Istio这类数据中心层面宏观的基础设施。业务方不需要再用事故来付高昂的学费锻炼出这样的团队，或者高昂的费用来招聘这类经验丰富的工程师，来搭建和维护自己的基础设施。当然，不是说云上的基础设施不会挂，挂还是要挂的（这里不是针对某一个云厂商），只是大概率他们有能力发现和恢复起来比我们自己维护的快。3、伴随着技术的更迭和发展，系统实际上是越来越复杂的，云带来的便利，屏蔽了底层系统的复杂度，云的体系架构本身也在积极进化，业务系统能够随着云体系的进化，及时升级自己的底层架构体系。
但是不意味着业务系统上云一劳永逸，从传统的架构体系，到cloudready，再到cloudnative，业务系统还有很多事情要做，其中重要的几件事：
1、Disposable和stateless的系统，可重入和幂等的设计。基于容器化体系构建的数据中心，接纳不确定性，注重快速恢复，要求应用基于failgracefully&rapidly,startrapidly这类反脆弱的原则设计。从单机操作系统演变到云上操作系统，系统向分层越来越多，越来越复杂的趋势演变，复杂也带来了更多脆弱性，基础设施局部的系统抖动（transientfault)不可避免，对业务系统的自愈能力也提出了要求。
2、可替换的基础设施和快速搭建的业务系统。基于标准化的基础设施（IaaS或者PaaS）构建自己的系统。标准化的基础设施意味着，无论在自己的数据中心还是公有云上，业务系统都不需要改造可以快速搭建、拉起完整的链路。这里的“标准”，指的是业界大多数厂商采用的事实标准（比如Kubernetes在容器调度领域的地位，它开放的CRI/CNI/CSI接口），或者待形成的标准（比如在servicemesh里面力争成为标准的SMI，虽然对面有istio这个庞然大物）——这需要技术团队的评估和判断。这也是依赖接口（标准）而不是实现（产品）的设计原则体现。客观上也达到一个效果——notlockedin。3、当业务达到一定体量，系统架构上，在数据中心维度可水平扩展是一个必然的发展阶段，只有这样，才能充分利用云厂商分布在全国甚至全球的数据中心节点，发挥容量弹性优势，并享有随之而来的容灾能力。
其实我们做了很多中间件治理产品，缓存、代理、消息队列、soa服务等等。但是，遗憾的是，有些工具的使用视角是中间件开发团队，另一方面，这些控制台是一个个孤岛，没有关联起来，形成一个平台。关于这个平台的设想，是从一个应用的owner为视角展开应用治理，比如一个服务类应用开发工程师，进入这个系统，可以看到这个服务的健康状况总览，监控数据，依赖的上下游服务和中间件元数据，查看并实时变更这个服务的一些配置信息——比如限流阈值、熔断状态、降级开关、黑白名单、多数据中心的容量管理等等，进一步，可以申请资源，实施灰度上线策略，蓝绿发布，在一个平台内解决，而不是切换多个系统完成。
这个产品之下，依赖的是各个中间件提供的相互协作的接口来完成。围绕着一个应用，能看到这个应用在全局内的全景信息，应用owner通过自助完成从资源申请、系统上线、运营治理、健康监控、下线回收，整个应用生命周期的管理。
随着系统的复杂性和稳定性要求的提高，同一个领域服务，在不同场景内，会被不同的上游系统依赖，而这些场景的的重要性、安全性、SLA要求、请求的流量特征都是完全不同的，出于隔离的需要，越来越多的业务开发团队开始采取单应用多集群的方式部署，以应对来自不同场景的调用方。随着业务上这类诉求的增加，建设多泳道的议题被提出来，我们曾经规划过三个泳道：
1、金丝雀：部署在这个泳道内的集群，承担的是系统全量上线前，或者全面启动灰度前的流量，通常，一个产品，想让自己的员工先“吃狗粮”，也可以先部署到这个泳道。这个诉求最强烈，现在已经通过“Pre-ProductEnvironment”的建设，部分落地。容易被忽视的是，这个泳道也是生产环境，需要避免被滥用而引发事故。出于成本和复杂度的考虑，数据存储很难做到彻底隔离。
2、在线服务：承担着核心的在线流量，例如用户端、商户端、开放平台、骑手履约这些关键路径上的应用场景，都在这个泳道内处理。3、离线系统：一些公司内运营人员使用的管理台、离线的scheduledjob所依赖的服务在这个泳道内部署独立集群。那么一些运营操作、离线job对线上系统的影响可以一定程度上隔离。这个泳道现在并没有从在线服务中分离出来。
先来看看物流运单履约的一个初步规划讨论稿，这张粗颗粒度的图只是为了完整说明尝试平台化建设的初衷举的一个例子，忽略了很多细节，不完全反映现状。
上云以后，我们开始尝试在Kubernetes体系下，实现我们灵活扩展和充分隔离的诉求。利用pod，把稳定的核心领域逻辑和可变的业务逻辑通过主容器和辅助容器部署在一起，但是又保持独立性，随需而变的业务逻辑能够和相对稳定的领域逻辑分开独立发布、变更（需要对kubernetes做一些扩展）。除了用sidecar来解耦以外，还有另一个思路，就是平台定义SPI，接入方基于FaaS实现自己的逻辑。
上云之前，自建的数据中心里是基于swarm调度。sidecar（sam）和业务系统部署在一个container里面，这个毕竟还是违背容器单进程模型的。
前面的内部架构图上我们可以看到，内部服务实例上运行着包括SOA框架在内的很多sdk和引擎，上云之后，基于kubernetes，通过把sidecar容器注入到业务容器所在pod里面，可以将这些逻辑从SDK迁移到sidecar（sam）里面（类似Mecha的机制，比如微软的dapr），进一步丰富servicemeshdataplane的能力，多技术栈和框架SDK升级困难的难题也能够得以解决。
多数据中心的路由策略，数据中心（可用区）封闭策略，跨数据中心访问代理，包括多泳道建设，dataplane都可以充当核心的角色。Istio很强大，但是大型系统成功案例不够丰富，再加上和CNCF渐行渐远，可以先观察，也可以选择适合自己的轻量级mesh方案，比如基于SMI：微软的OSM，containous（traefik背后的公司）的maesh等等，都提供了另一种思路。
以上就是饿了么技术体系随着业务成长，从日均百万到千万单量的迭代轨迹。
后续全面上云这一个“规划”是顺理成章的事情，因为这个时候的架构已经cloudready。“UncleBob:Architectureisaboutintent,notframeworks”——从我们架构的演化历程来看，为解决一个个现实的问题提出的解决方案，不是为追逐“流行”而构建，更不是源自权威的指令。架构的规划在这里面的作用，更多的是在发现问题和解决问题的过程中，借鉴业界的实践经验来推进整体迭代，约束设计原则。
在计算机工程领域，大多数情况下，遇到的问题都是有前人的经验可以借鉴的，指导原则也是现成的。我们的架构演进，包括多数据中心建设，如果没有左耳朵耗子还有毕玄这些前辈的指导，也不可能那么顺利。
还有一个关键的因素就是团队，技术心态是不是开放包容的，技术栈构成是不是多样性的，工程师文化是不是这个团队文化的一部分，也一样影响着架构的现状和未来演进。自始至终，真正引导我们解决问题，潜移默化的推进我们架构演进的，一直是一线工程师，有幸在这个团队和大家并肩作战。
补充说明：本文所描述的是截至2019年前后的架构体系。进入2020年前后，伴随着组织结构调整，中间件替换，业务系统入集团中台的需要等等，很多核心系统已经重写或者在重写中，架构及其演进方向也已经发生了变化。