在上一篇文章《饿了么技术往事（上）》中，我介绍了饿了么最晚期 All in One 阶段的架构，以及第二阶段业务零碎拆分与团队经营的一些思考，以及我对于架构师职责的感触，接下来我会具体介绍饿了么全面服务化的架构演进历程。
一、中间件
业务线的工程师深陷到疾速的迭代和业务复杂性当中，业务的快速增长、外卖行业午晚顶峰业务特点带来的并发挑战，畛域拆分后所需的服务体系框架撑持，责任天然落到了中间件团队。
过后中间件团队次要负责的三件事就是公布零碎、SOA 框架、对立的数据拜访层。
1. 公布零碎
外卖业务周末的单量通常比工作日要高，然而工作日事故率要高于周末，为什么？变更是万恶之源，周末很少公布。所以，公布零碎接手管控，勾销手动公布的模式，解决公布回滚的问题，通过公布自动化提高效率的同时，回收服务器的权限，升高平安和稳定性的隐患。当然公布零碎的作用远不止于此，后续这个体系及其团队充当起了基础架构演进的外围角色。这个是后话了。
2. SOA 框架
SOA 框架是撑持业务服务的骨架。和少数相似框架一样，为应答简单的服务体系，服务注册和发现，常见的基于 Design for failure 的设计，熔断、限流、舱壁、多集群隔离这些性能都一样。然而，较非凡的中央在于——咱们有两套 SOA 框架，Java 版和 Python 版。后面提到，咱们有两个次要的技术栈 —— Java 和 Python，使得咱们但凡须要 SDK 的中央，都须要反对两种语言，毫无疑问会对减少中间件团队累赘。在过后的确是个难题，这个当初当然也有解，前面会提到。
领会和教训——是否应该对立技术栈？
对于是否应该对立技术栈，没有一个规范的答案。每个公司的技术栈和技术体系，有其造成的背景，如同架构一样，不放在上下文外面探讨合理性，往往没有后果，烟囱型也好、L 型也好，只有是适宜本人的技术和架构就好。
Python 技术栈过后曾经撑持了很多外围零碎，颠覆现有零碎，换技术栈的工夫老本不可漠视。而过后市场竞争十分强烈，对于饿了么这样的守业公司，数据、工夫和人是最贵重的。而且，有一支能力十分强的 Python 技术团队，从外面抽调局部工程师，撑持 Python 技术栈的中间件建设，也不会带来额定的人力老本。保护两个技术栈，中间件团队的累赘会减少，然而，换取的是工夫和优良的工程师，还是划算。这些 Python 工程师外面，负责业务零碎的很多人起初也成长为独挡一面的角色，跟上了业务快速增长的步调（后续会有相干的内容分享）。而负责中间件的 Python 工程师，他们的一些创造性实际，也为咱们后续架构演进奠定了根底。
好的技术体系和架构，起决定性的不是技术栈，最终还是优良的工程师。
3. 数据拜访层
因为多技术栈的存在，DAL 层抉择了中心化的计划，而没有采取 SDK。对立的数据拜访层为后续分库分表、限流爱护、多数据中心上线后的数据纠偏打下了根底。为了保证系统有足够强的吞吐能力，DAL 层采取了异步 IO 的计划来解决出入流量，中间件的最高境界是大家会遗记它的存在，DAL 层波及到底层和数据库的交互，尤为敏感，而这个中间件简直做到了，没有呈现过重大事故，也很少有开发吐槽这一层的问题。起初，这个始终持重的团队在饿了么多数据中心建设当中，负责了外围的流量调度及容灾切换管控体系。大家都习惯了叫 DAL，很多人不晓得这个零碎叫 Athena。
基于 DAL 的上线，DBA 和 DA 这个期间就忙着给各个团队做分库分表的事件：
按业务性能畛域切分——拆库
依照拜访频率、动动态属性等等规定——垂直分表
基于 Hash Partition（须要留神的是防止热点和 Rebalance 带来的老本）—— 程度 Sharding
总之就是抉择适合的 Partition 策略，升高数据库单个实例的负载。存储起初能支撑住千万级单量，除了上游队列的削峰、缓存的缓冲、数据库读写拆散以外，也得益于适当的 Data Partition 策略。
二、大前端
其余团队还在拼命追赶业务、填坑补课的时候，大前端团队满足业务需要的同时，还为开源社区奉献出了十分优良的产品 Element。就在大家认为这支团队会持续在前端畛域上一骑绝尘上来的时候，令人没有想到的是，这个团队几年后会暴发出微小的后劲，成为整个架构体系降级中一个无足轻重的角色。为什么叫大前端，因为他们和传统的前端团队做的事件不太一样，前面会讲到。
领会和教训——找到优良的工程师如许不容易
招聘优良的工程师，继续招聘优良的工程师，这是一句正确的废话。然而有多难，带过团队的应该都深有体会，特地是你的公司还没有自带光环的状况下。优良的工程师会吸引来更多更优良的工程师，反之亦然，面试这个过程是双向的，尤其是优良的工程师。有业务压力的时候，主管很容易扛不住，降低要求。过后大前端团队校招淘汰率还是挺惊人的，换来的是这个团队的工程师很高的技术素养和基本功，为前面成为一个真正的全栈团队打下了的根底。
Leader 的集体能力，决定了他（她）是这个团队的地基还是天花板。
三、大数据
基于 Hadoop、Spark、HBase 的经典大数据架构这个时候也搭建起来了，因为是自建的数据中心，所以这些产品都须要有一个业余的团队来运维，因而大数据也有了本人的运维和中间件团队。在这个阶段，在线和离线数据同步、数据治理下面还不欠缺，因为产品化还在路上，很多工具缺失，导致很多团队都要本人间接去从数仓取数，不得不维持经营团队撑持定制化的手工取数需要。各个团队喊得最多的就是大数据的人不够，想要本人做。外围还是业务倒退太快。前面随着大数据团队逐步壮大，更多强援退出，各个产品相继成熟才得以缓解。
四、风控平安
这是一个不得不说，然而也不能说太多的团队，所以这部分只能务实一些，任何一个到了肯定规模的企业，风控平安团队是“真”底线。其余技术团队在面对这个同样是负责技术的团队背后，有时候的确也挺一言难尽的，这个时候高层的反对至关重要。尤其是从 0 开始建设这个团队，对内的扫盲和对外风控，一样艰巨。
如果说一个技术公司，零碎毁了，有什么还能留下来，就还能重建，那必定是数据（当初可能还要加一个算法模型）。有什么缺失了，随时都可能垮掉，那必定是风控平安。
饿了么的这支风控平安团队，对内、对外、对线上、对线下、对其余……都面临很多挑战和抵触，堪称业务专家的羊毛党和无孔不入的黑客，的确令人叹为观止。而咱们的风控也经验了从开始的粗粒度束缚、到依赖业务规定针对各种补贴、账期等场景兜底、再到依赖算法模型实时风控被动拦挡的阶段。
如果大家身边有做风控平安的同学，请珍惜，哪怕他们有时候看到零碎到处是窟窿的时候，脾气火暴。因为他们终日面对这么多黑暗面，还能对这个世界报以心愿。开个玩笑，从人道的角度登程，这个团队须要定期的心理按摩。
这个阶段，咱们初尝了算法的威力。一开始只有搜寻，然而还没有举荐召回零碎，过后给举荐零碎的物理机是咱们能拿得出手的最好的物理机，其余业务零碎调配的大都是虚机。零碎上线当前，成果、转化率都还不错。之后不久这一待遇被另一个团队承包——负责配送履约的智能调度团队，大数据、机器学习、算法模型须要充分发挥效用，须要长时间紧贴业务、深刻理解业务，在智能调度畛域咱们也做过不少艰巨的尝试、吃过不小苦头，直到咱们有了本人的算法专家团队。
这个阶段咱们还经验了第一次外卖行业的大促——517 大促，让大家真切感受到了这个市场的微小后劲，同时零碎的一系列短板也暴露无遗，除了积攒了大促的教训以外，更大的播种是让咱们看到架构还有很大的降级空间。还播种了一支全链路压测团队，他们在今后架构降级以及零碎品质、容量等稳定性保障过程中，表演了要害角色。
在饿了么技术往事系列文章的开篇，我提到了饿了么的技术体系经验了以下四个阶段：
外围零碎 All in one 的晚期架构；
以零碎畛域化拆分、业务零碎和中间件等基础设施拆散为根底的全面服务化的架构；
随着自动化平台、容器调度体系成熟，治理从传统运维向 DevOps 转变的基础设施体系；
多数据中心体系根底上的 Cloud Ready 架构成型。
当初咱们前两个阶段根本实现了，开始了相对而言最艰巨的阶段了……
第三阶段：软弱的零碎，苦逼的运维
这个阶段，咱们的业务曾经倒退到肯定规模，零碎的长时间抖动或者解体，很容易上热搜，尤其是饭点时段。产生事变时候，冲在第一线的除了各业务线的工程师，还有运维团队，他们往往是最先响应，排障冲在第一线的团队。这个阶段说是靠他们生扛顶住了稳定性的压力也不为过：日常基础设施部署、事变产生时的应急响应、事变产生后的基础设施优化和改良措施落地，他们都承当了很多。
事变的教训，也让咱们学会了遵循一系列业界积攒下来的设计准则，为架构演进到下一阶段打下基础。
业务畛域拆分、基础设施和业务零碎别离建设后，给业务疾速倒退解绑了。然而包含稳定性在内的一系列挑战仍然须要面对：
基础设施部署的标准化
零碎的生命周期怎么治理？
每次故障都是低廉的学费，故障能够防止吗？
复杂性带来的挑战：团队外面简直没有人面临过这个体量的业务、这个复杂度的零碎。疾速交付的同时，如何保证系统的稳固和强壮？
咱们的零碎架构接下来如何演进？
- DevOps
因为云上资源的灵活性，咱们在云上搭建了两个测试环境：alpha 作为开发环境，用于软件工程师日常开发调试；beta 作为集成测试环境，用于测试工程师实现零碎交付上线前的集成、回归测试。费了九牛二虎之力才达成所有团队的共识，推动 beta 环境的零碎和数据的完整性建设。在这外面施展重要作用的，除了各个业务的开发、测试、运维团队，还有一个就是之前提到的负责公布零碎的团队，这个团队不仅仅提供了一个简略的公布零碎，基于继续集成和继续部署实现的开发、测试、生产环境类似化，是咱们的零碎架构持续演进的开始。
技术团队职责细分后，运维团队提供了保姆式的服务，这把双刃剑的另一面，就是开发团队很容易造成惰性，对本人的零碎管生不论养，对系统的容量、治理关怀不够，因为有运维团队。这就带来很多问题，代码不是运维工程师写的，然而有些团队零碎甚至是运维工程师部署的。因为开发团队最贴近业务需要，需要变更可能带来将来的潜在容量危险，他们比拟有发言权；而容量水位的现状反过来是运维团队更理解。因为这个时候，很多基础设施运维还没齐全自动化，所以难以统一化、标准化，每个运维工程师都有本人的运维格调，日常排障上，有时候须要开发和运维一起能力实现。
此外，只生不养的思维形式，主观上也容易造成算力老本变成糊涂账。这个时候，开发、部署、零碎经营（治理）角色的不对立带来的问题就会凸显。
利用 Owner 要成为货真价实的 Owner，须要有利用的全景视角，对利用生命周期的把控能力。这个阶段，开始推动从虚拟化到容器化的转型，公布零碎从一个简略的 CI、CD 的体系，延长到了算力和调度的畛域。基于一系列运维自动化工具的建设和全面容器化调度的施行，从而带来标准化的运维，能力把开发工程师（利用的 Owner）推到利用残缺的生命周期经营的地位上，胜任 DevOps 的角色。这个时候，事实上底层的算力平台，曾经具备云上 PaaS 的雏形了。
在这个过程中，也做了不少尝试，比方，为了进步 alpha/beta 这两个测试环境的基础设施交付效率，有过一段时间基于 slack 的 ChatOps 实际，工程师都比拟欢送；还有过 Infrastructure as Code 和 GitOps 的实际，很惋惜过后各方面条件和机会都不够成熟，没有继续推广。
领会和教训——DevOps
alpha 和 beta 环境：
工程师在开发机上自测是不是就能够了，“在我机器上是好的”这句话预计开发工程师都说过或者听过，在开发阶段提供 alpha 环境，目标就是为了开发、测试、生产环境的尽量靠近，防止因为开发、测试、生产三个阶段因为环境差别微小带来的问题。解决不了“在我机器上是好的”这个问题，没有方法大规模顺利上云。工程师本人的电脑，某种程度上是一台“mommy server”，下面运行着须要的所有环境，而且每个工程师的祖传环境还不一样，这类环境在生产上是不可复制的。
Build & Release：
怎么做到高质量疾速交付，保证系统的稳固？
在疾速迭代的同时，做到疾速试错、疾速纠错、疾速回退。须要公布零碎做到每个编译的版本、每次公布的版本，像代码一样，可回溯可跟踪。关键在于 build 和 release 是 immutable 的
首先，build 和 release 有惟一的 ID，才可追溯，可回滚；
其次，是配置拆散，把和环境（dev/test/product）相干的 config 从代码中剥离开来，否则零碎很难迁徙，更不用说大规模上云。第一反馈可能是，把和环境相干的 config 写在 xml 或者 yaml 文件就能够了，然而，这些文件也是代码。
相似的，将这些随环境变动的 config 写在公布流水线的脚本外面，都不是彻底拆散的形式。因为公布环境会发生变化，可能未来有更多的测试环境、更多的数据中心、每个数据中心外面可能还有多泳道。
因而，要做到“build once, deploy many times/every where”，config 要存储在环境的上下文中，比方开发、测试、生产环境各自有一个配置核心，线上零碎拉起的时候，先从配置核心拉取配置信息。要掂量环境相干的 config 和代码是否曾经拆散，看看能不能开源就晓得了（抛开价值和代码品质不谈）。
OPS
接触过传统的运维工程师都晓得，这是一群责任心极强的人（删库跑路，铲平数据中心的事件是不可能干进去的，尽管有能力……），他们保护着零碎的底线，第一次 517 大促事变的时候，咱们靠运维工程师救了大家一命。
然而，即便有操作的 SOP，只有是人，执行反复工作的次数足够多，总会犯错。而每个资深的运维工程师，都有本人祖传的脚本，一夫当关万夫莫开，然而休假就麻烦了，特地是在高铁上信号不好的时候……最佳实际→ SOP → 脚本 → 自动化工具产品，沿着这个门路迭代仿佛不可避免。
传统的运维工程师角色的演进方向，一个是为云上的 IaaS/PaaS 服务，对操作系统和底层硬件有着丰盛教训的，还是运维工程师，他们当中开发能力强的，转型 SRE，对运维产品了解深的，能够抉择 Technical Product Manager 的角色，为云上运维相干平台产品提供解决方案，或者凭借丰盛的云上零碎落地施行教训，为各上云企业提供实施方案。
另一个方向，因为合规和其余起因，还有局部没有上云的企业，仍然须要基础设施运维工程师。随着云逐步变成和水电煤一样的社会基础设施，运维工程师只写操作系统脚本、施行部署的时代曾经渐行渐远了。
架构的历次演进，和几次事变或者险些酿成事变的“冒烟”事件，有着很大的关系：
交易系统解体的“饿死了”事变，咱们开始拆散要害门路和非关键门路，建设了非关键门路的降级能力。故障应急响应惯例三板斧：重启、回滚、降级，至此齐备。
第一次 517 大促入口解体的事变，是咱们外围零碎上云的开始。
F5 的 CPU 被打满，让咱们意识到网关作为入口难以扩大的微小危险，从而基于从新构建的大网关体系，取代了 F5 这一层硬件负载平衡。大网关体系是咱们多数据中心架构最外围的零碎之一。
基于 VIP 的 keepalived+HaProxy 负载平衡体系下，各种 failover 和上下游频繁扩缩容过程中，相干的稳定性冒烟或者事变频发，促成了充当 data plane 的 sidecar 上线，这是咱们构建类 Service Mesh 架构体系最重要的组件。
外围交换机 bug 引发的数据中心故障，对咱们下决心建设多数据中心体系有着很大的影响
对于这些事变和架构的故事，随着架构的演进，前面会一一开展。
那个时候，咱们经常自嘲是“事变驱动”型开发（Disaster Driven Development）。很多工程师除了本人的工位，在公司外面最有“感情”的就是整面墙都是监控大屏的 NOC 作战室，大小事变、各种大促流动值守，熬夜全链路压测，外面经常挤满相熟的脸孔。
领会和教训——
（1）事变复盘
事变复盘和定期的故障验尸总结会是一个很好的机制。很容易被疏忽的是，除了找到事变产生的 root cause，还须要从中发现存在的隐患，而不是 case by case 的解决问题，复盘的目标是阻止相似的事件再次发生，必要的时候，能够引入业务、产品、技术独特解决。
另一个陷阱是，故障复盘变成追责的过程，那么参加复盘的各方就很容易陷入相互指摘、洗脱责任的怪圈，反而遗记了复盘的基本目标，也容易节约大量工夫，引起不必要的内耗。只有是参加复盘的人，都是有责任在身上的，为未来的故障负责，如果相似事变再次发生，或者没有在复盘中发现应该发现的隐患，参加的人都难辞其咎。
复盘后果要防止惩办为目标 —— 除非违反了规章制度（底线，不排除有些是恶法，但不在探讨范畴内）。否则甩锅、不作为的气氛会日渐滋生，自省有担当和有作为的集体或者团队，很容易成为吃亏的一方。事变复盘的过程，是理解各个团队甚至组织文化的一个视角。
（2）弹性设计
物流、交易经验事变后，各自采取的措施再次印证了，反软弱的设计是咱们的利用倒退到明天的外围设计思路之一。
传统思路是基于一个上下文可控的现实零碎环境下做出的设计，尽量避免所有意外的产生。而反软弱的设计，恰好假如黑天鹅事件肯定产生，是墨菲定律的信徒，开句玩笑话，云厂商如果承诺你“咱们肯定会挂”，你肯定要珍惜，你面对的是一个坦诚相待的乙方，值得托付。这不是推责给云厂商，这是由云上基础设施的特色决定的，大多数场景下，云上提供的服务是基于大规模标准化服务器（Off-the-shelf hardware）构建的虚拟化、容器化基础设施（Immutable Servers），而不是超高规格的个性化定制独占设施(Snowflake Servers)——无奈规模化，老本也会大规模回升，因而，会更重视疾速恢复能力，程度扩大能力，整体的健壮性，而不是具体某一个单机 SLA。
所以云上零碎更强调算力的形象，CPU 核数、内存、网络带宽，把数据中心看作一个超级计算机，和 CPU 具备纠错机制一样，云上基础设施不是不会产生谬误，只是联合它的“操作系统”（比方 Kubernetes），提供的是纠错能力（比方容器的故障转移 —— 故障容器销毁，新容器拉起，实质上也是冗余），而云上业务零碎须要适配这类纠错机制实现本人的自愈 —— 面向云编程 —— 承受短时间的抖动（Transient Fault）会不断产生的这一个事实。
物流通过弥补机制加强本人的健壮性，交易引入 chaos engineering，都是基于这个上下文。要求利用是 stateless 或者 disposable 的，目标是为了 crash 后可能迅速拉起，疾速自愈——所以，尽量分布式缓存，尽量少本地缓存，利用拉起时初始化的工作尽量少，交给独立的服务干这些事。业界的很多模式实际：bulkhead, circuit breaker, compensation transaction, retry 都是指向晋升零碎的弹性（resilience），足够强壮的零碎可能在经验零碎抖动后，迅速自愈。
故障和意外一样，难以避免。咱们能做的是缩小人祸，敬畏生产环境，因为一次故障影响的可能是骑手一天的生计、商户一天的营收、用户的一日三餐。同时，进步零碎的健壮性和自愈的能力，在故障产生的时候，尽可能的防止演变成更大的劫难，及时止损。
2. 黑天鹅
这个阶段，咱们经验了一个大事变，起因就是外围交换机挂了，可能有人问，不都重叠的吗，不都有主备吗，不都主动切换的吗，说得都对，然而都挂了。因为交换机的一个 bug，主备切换后，备机也很快被网络风暴打挂，没经验过咱们也不置信。这次又“饿死了”，咱们只能坐等供应商的工程师抱着设施打车到机房更换，这个时候，一群人挤在应急响应指挥室（NOC 作战室）里一点方法都没有。
在第一次 517 大促之后，咱们就开始第一次容灾尝试了，过后采取的是最快最简略粗犷的计划，用最短的工夫，在云上搭建一个了灾备环境并跑通了业务链路。但这是一个冷备的环境，冷备最大的危险，就是日常没有流量，真正 failover 切换的时候，有比拟大的不确定性。这次事变再加上另一个因素，咱们下决心将技术体系推动到下一个阶段。
领会和教训——上云
2016 年第一次 517 大促，10 点开抢的霎时，咱们零碎崩掉了，要不是过后一个很稳的运维工程师，淡定操作限流，可能不少人在饿了么的职业生涯过后就完结了。因为对过后的基于 Nginx 和局部自研插件的网关层比拟自信，不置信网关层会顶不住，所以全链路压测的时候基本没有压这一层，预先复盘的时候发现是操作系统一个参数配置的问题，如果压测肯定能重现。
因为业务的成果很好，大促就成为常态，事实上第一次大促，咱们是在本人的 IDC 外面用惯例业务零碎来扛的，所以影响到了非大促的失常交易。前面专门针对大促高并发大流量的场景设计了一套零碎，也是隔离、排队、CDN、限流这些惯例的套路，没什么特地的。然而，对咱们影响更深远的在于，这套体系齐全是在云上搭建的，2016 年之前尽管云上有零碎，然而生产环境流量很少，顶多是短信触达这类零碎在下面，更多是用于搭建测试环境。在过后看来，云上弱小的流量荡涤、资源 scale out 能力，很适宜大促的场景，前面，这套体系经验了屡次大促，没有波澜。
在云上搭建大促体系以及灾备节点的经验，让咱们后续在云上搭建全站的网关，并进一步构建整个数据中心，有了十分大的信念。下一篇我将持续介绍饿了么架构演变到了 Cloud-Ready 的状态，技术体系演进为业务倒退提供了更多可能性。
作者介绍：黄晓路（脉坤），2015 年 10 月退出饿了么，负责全局架构的工作。
原文链接
本文为阿里云原创内容，未经容许不得转载。