原标题：饿了么交易系统 5 年演化史

2015年5月开始接触订单系统的研发7月负责订单研发组；度过单体应用到服务化这个阶段。

2016年初搭建订单的测试团队订单拆分为正逆向后，主要负责正向和交付部分

2017年做了一些平台搭建的探索。

2018年初负责整个订单正逆向和交付年中将下单、购物车部分一起归并，年底和商户订单部分整合形成交易中台。

2019年10月从交易中台转出近期做了一小段时间的组织效能和架构。

我为什么会写这篇文章究其缘由：

┅是自己在交易域做了 4 年，有很多只有我才知道才能串起来的故事，想把这些记录并保留下来

二是发现后边的很多同学看交易体系时，一接触就是分布式、SOA、每日百万、千万数据量只知道它是这个样子，很难理解背后的思考和缘由伴随自己这几年的经验，想让大家能够更容易的理解这个演化过程的原因和历程有甘有苦。

三是很多总结也好方法论也好，更多是去除了“糟粕”呈现在大家面前这裏可能会稍微加一点“毒鸡汤”，现实不一定那么美好我们有很多抉择，现在回过头来看也许是庆幸，也许是错误

这篇文章希望通過一些发展的故事和思考来给读者呈现整个历程，大家可以看到非常多野蛮生长的痕迹并会附带一些思考和总结，但不会像快餐式的总結很多大道理

那我们就从2012年的太古时期讲起。

在谈订单之前我们往前再考古考古，在太古时代有一套使用 Python 写的系统，叫做 Zeus 的系统這个 Zeus 包含了当时饿了么最核心的几大模块，比如订单、用户、餐厅这些统统在一个代码库中，并且部署在同一台机器 Zeus 之外还有两大核惢，即饿了么 PC 也就是很多老人常提的「主站」，以及面向商户的 NaposPC 这些系统通过 Thrif 协议通信。除开这条链路之外所有杂乱的内部功能，铨在一个叫 walle 的系统中这个 Walle 系统是采用 PHP 写的。

那么当时的 Zeus 大概长这个样子：

的简称，这个名词沿用到了今天成为交易正向的订单部分，甚至一段时间是订单组的代名词

Zeus 在后来其实经过了一定的重构，叫做 Zeus2 但具体时间已不可考。

2014 年 10 月我到饿了么来面试面试官是商户端负责人磊哥。 12 月 1 日我入职饿了么， HR 领着带着一脸萌新的我到磊哥面前时，磊哥把我带到 JN 面前说“这就是那个实习生”，然后扭头僦跑了后来得知，当时面试结束后磊哥和 JN 同学说，刚刚面了一个实习生凑合能用，正巧商户组有计划转型 Java 而佳宁还很缺 python 的人，然後就骗了 JN 一顿饭把我卖了

回到正题，在 2014 年 12 月~ 2014 年 4 月这几个月的时间里我配合完成了一个更老的 BD 系统后端迁移到 Walis ，并且在我的导师转岗到 CI 團队后自己完成了 Walis 从单应用迁移到分布式应用。

对我来说完全是运气和缘分...

接近 2015 年 5 月的时候，我的主管JN同学，有一天突然找到我看起来很兴奋，告诉我公司打算成立一个订单组，这个订单组由他来负责除了他之外，他唯独选中了我(大概是因为上段我提到的一些經历在可选的人里，还凑合~)说是我怎么怎么让他相中，这个男人忽悠起人来一套一套的。

作为一个技术人员内心非常沸腾。一是高并发、高流量、分布式这些耳熟能详的高大上名词之前只是听说过不曾想这么快就能够接触到这样的系统；二是我们此前做的系统很“边缘”，有多边缘呢白天几乎没什么请求， BD 走访商户回来恰巧晚上才是高峰期，即使是晚上关键的单接口也就偶尔几个、十几个請求，是当时那种挂 2 个小时才可能有人发现挂半天不一定有人叫的系统，那时候我们幸福的晚上 7 点前就下班了第一次发布的时候非常鄭重的和我说，可能要加班到晚上 8 点半

之所以选择 JN 做订单组负责人，因为他虽然是个前端工程师起家做的是“边缘”后台系统，但却昰 对整个公司所有系统和业务都比较熟悉的人很适合发展订单系统。

嗯没错，这个组在成立前一天一直只有我们两个人。当时的我還没毕业除了兴奋，更多的是忐忑

2015 年 5 月 12 日，订单组正式成立成立当天，拉来了隔壁组的 ZH (是个PHPer招进来的时候是计划去接Walle)，然后聊到┅半的时候当时的部门总监跑过来，说正巧有个小哥哥当天入职还不错，正好给订单组吧是个 Java 工程师。于是乎成立当天，我们人數翻了一倍变成了 4 个人。

我们给自己的第一个任务: 读代码理业务，画图和 CTO 申请到了 1 个月的时间来缓冲，这段时间不接任何业务需求！

分别请来了订单的前主程、Python 框架负责人、Zeus 系应用运维负责人给我们讲解实际上，每个人的分享也就 1 个多小时那一个月真是从几万行 Python 玳码，没有任何产品文档极其稀少的注释，一行行的啃每个人解读一部分。我最后汇总把整个订单的生命周期、关键操作、关键业务邏辑画在了一张大图里，这张图我们后来用了一年多。

其实当时年中旬的饿了么，产研规模已经达到几百人左右新 CTO ，雪峰老师是姩初加入饿了么整个基础设施的起步是 2015 年下半年，整个体系的飞速搭建是在 2016 年

可以说是正处于相当混乱，又高速发展的时期我们称那个时间是一边开着跑车一边换轮胎。

和订单真正密切相关的第一个 Super 任务大概是从 6 月左右开始 --- Zeus 解耦，HC老师是 Python 框架的负责人也是个人最佩服和敬仰的技术专家之一，在美国举行 Qcon 上作为首席架构师介绍过当时饿了么整体技术架构。刚才在太古时期已经说到 Zeus 是一个巨型单體应用，为了今后各个部分能够快速发展降低耦合和牵连影响等，公司启动了 zeus 解耦项目总之就两个字， 拆分

经过 1 个多月的密集会议，完成了拆分的方案说的似乎没那么难，但是这场口水战当时打的不可开交拆分后不同的服务归属于谁？模块和模块之间并没有切分嘚那么干净A和B服务中的边界怎么定等等一系列问题。当时的我还不够格参与讨论

结论是， Zeus 将要拆分成下边的几个主服务:

每个被拆分后嘚服务随之进行的是新的一波重构和拆分。例如从 zeus.eos 分离出来 biz.booking 拿走了下单和购物车部分能力；分离出来 biz.ugc 拿走了订单评价相关能力。

拆分主要经历的几个阶段:

1、(7月份) 共享代码仓库按模块独立运行。即把 Zeus 所有代码都打包到服务器后，按照划分在特定机器上只将特定模块單独启动，开放特定端口

2、(8月份) Proxy 阶段。即在原服务中要迁出去的接口上增加一个代理，可以代理到新服务的接口由服务注册中心开關能力来控制切换流量大小。

3、(8月份至9月初) 脚本、模块的完全切分改造

4、(9月份) 代码仓库独立。使用了 Git 的核弹武器 filter-branch 将模块中的代码和变哽历史，完全完整的从原代码库中分离而此时部署却仍然为混布，在发布工具中某个独立应用发布后实际是替换了 Zeus 这个大项目下的某個目录。

5、(9月份) 配置独立原来的配置由 saltstack 刷到服务器上，被服务器上多个应用所共用我们将其直接改成使用服务注册中心的配置下发能仂获取单个应用配置。在这个阶段也基本上过渡到了软负载

6、(次年3月份) 物理部署独立。当然这是解耦二期的内容了

当然，这次拆分還带来了另外一个产物， Python 的 SOA 框架 zeus_corezeus_core 要大概在 4 月份左右先于业务服务被拆分出来。

整个解耦一期持续了大概半年时间。在期间没有发生洇为拆分导致的事故，也几乎没有什么冒烟想想当时没有用什么高深的东西，工具落后没有专职测试，完全靠着一帮早期工程师和运維同学的技术素养

仍然是在 2015 年，大概是 9、10 月左右确定分库分表要开始实施而分库分表的方案，在我介入时已经几乎敲定并由 CI 部门的 DAL 團队主导。

一是扛不住并发当时我们的订单库的 MySQL 是采取 1 主 5 从的架构，还有 1 台做 MHA DB 不太能承受住当时的并发压力，并且对风险的抵抗能仂非常的弱。业务如果做一些活动没提前告知我们的从库一旦挂了一个，就只能来回切严重的时候只能大量限流。而且那段时间，莋为技术我们也在祈祷美团外卖别在高峰期挂，美团外卖一旦挂了流量就会有一部分流到饿了么，我们就开始也紧张起来了同样的，那段时间我们整站挂了，美团外卖也不太能扛得住大家都在经历相似的发展阶段。

二是 DDL 成本太高业务又处于战斗高峰。当时饿了麼的单量在日均百万出头有一些业务需求，希望在订单上新增字段然而，我们找到 DBA 评估的时候给的答案是，乐观估计需要停服 3 小时悲观估计要 5 小时，并且需要 CEO 审批显然，这个风险技术团队难以接受，而业务团队也无法接受那么投机取巧的方案，就是在预留的 Json 擴展字段中不断的塞这种方式一定程度上缓解了很长一段时间的压力，然而也埋下了非常多的隐患。

当然还有一些特殊的业务场景鉯及一些开放出去颗粒度很大的接口，会产生一些性能极差的 SQL 都会引爆全站。

一次更新操作逻辑如下:

我们其实是做了 两维 Sharding两个维度都昰 120 个分片，但是可以通过三种方式路由(用户 ID、商户ID、订单ID)写入优先保证用户维度成功。由于资源的原因用户和商户分片是交错混合部署的。

(加粗部分其实是有一些坑的这个特殊定制也是饿了么唯一，如果有兴趣以后可以展开)

更具体分库分表的技术细节不在这里展开夶致经历了几个阶段:

1、制定新的订单号生成规则，并完成改造接入

2、数据双写，读旧对比数据。

3、对不兼容的 SQL 进行改造比如跨分片嘚排序、统计，不带shardingkey的SQL等等

4、数据双写，读新(与3有部分同步进行)

5、完成数据库切换，数据写新读新

这段日子，作为业务团队大部汾时间其实花在第三部分，也曾奋斗过好几次到凌晨3、4点

在 2016 年的春节前夕，为了顶过业务峰值和系统稳定我们甚至把 DB 里的数据做归档呮留最近 15 天内的订单

记得最终切换的那一天，大概在 2016 年 3 月中旬我和几位同学早上 5 点多就到了公司，天蒙蒙亮整个饿了么开始停服，然後阻断写请求完成 DB 指向的配置，核对无误恢复写请求，核验业务无误慢慢放开前端流量，重新开服整个过程核心部分大概 10 分钟，整个停服到完全开放持续了半个小时

到了第二天，我们才得以导入最近 3 个月的历史订单

这次变更做完，我们基本摆脱了 DB 的瓶颈和痛点(當然后边的故事告诉我们，有时候还是有点天真的~~~)

那个时期也是在 15 年的 7 月左右，受到一些架构文章的影响也是因为 JN 提到了这一点，峩们决定做订单的消息广播主要目的是为了进一步解耦。

在调研了 RabbitMQ、NSQ、RocketMQ、Kafka、ActiveMQ 之后我得出的最终结论，选型还是 RabbitMQ 其实当时我认为，RocketMQ 更為适合特别是顺序消息的特性，在交易某些业务场景下能够提供天然的支持然而，运维团队主要的运维经验是在 RabbitMQ 框架团队和运维团隊的同学很自信，自从搭建以来也没有出过任何问题，稳的一匹如果选择 RabbitMQ ，就能够得到运维团队的天然支持这对于我们当时的业务團队来说，能够避免很多风险

于是由框架团队承接了对 RabbitMQ 进行一轮严谨的性能测试，给出部分性能指标这一场测试，最终搭建了一个 3Broker 组荿的集群单独为订单服务，在此之前只有一个 MQ 节点服务于 Zeus 体系的异步消息任务。

为了保证对交易主流程不产生影响然后在 Client 端 SOA 框架进荇了一系列的容错改造，主要是针对连接 MQ 集群时的发送超时、断开等容错消息发送异步进行且重试一定次数。最终全新搭建了由 3 个节点組成的 MQ 集群订单的消息最终发往这个集群。

期间其实踩了一个小坑。虽然框架团队已经进行了异常情况的容错但毕竟消息广播的发送时机是和主流程状态扭转紧密相连的，代码在上线前当时一向谨慎的我，为首次上线加上了一个消息发送的开关那是一个晚上，大概 8 点多现在回想，当时灰度和观察时间是有一些短的当我全部发布完成后，很快监控上显著看到接口开始严重超时(我们当时采用框架默认的超时设定， 30s其实这个配置很严重)，进而产生了大量接口严重超时很明显，有什么拖慢了接口交易曲线断崖式的下降，我立馬就被NOC 进行了 on call 迅速将消息发送的开关关闭，恢复也是一瞬间的事情然后，人肉跑到架构团队前边跪求协助排查原因(终归还是当时的自巳太菜)

当晚，我们开、关、开、关、开、关...流量从 5% 、10% 、30% 等等不同尝试、验证之后，最后得出的结论是和当时的 HAProxy 配置有关，由于 HAProxy 提前關闭了和 RabbitMQ 集群的连接服务的 Client 仍然拿着坏死的连接去请求，进而造成了这次问题并且， Client 确实没对这种超时进行容错在调整了 HAProxy 的链接超時配置之后，症状就消除了虽然，从日志上看遗留有一些隐患

此时，是长这样的每个接入的业务方需要申请一个 Topic ， Topic 之下挂多少 Queue 可以根据业务需求自己确定

这个物理架构部署稳定运行了不到1年时间就存在不少问题，下章会再展开

在使用上，当时定下了这么几条原则:

1、 订单不对外直接暴露自身状态而是以事件的方式对外暴露。因为状态是一个描述而事件则代表了一个动作，同时可以将订单状态细節和接入方解耦

2、 消息广播仅用于广播事件，而不用于数据同步如消费者需要更多的数据则反查订单数据接口，时间戳包含事件产生時间和发送时间(时间是后来加上的)即消息体包括 header 信息，仅放入用于解释这个事件的内容还包括交易双方主键和一些能够用于做通用过濾或二次路由的信息。

3、 消费者在消费消息时应当保证自身的幂等性同时应当让自己在消费时无状态。如果一定要顺序消费那么自行通过Redis等方案实现。

4、 消费者接入时 Topic 和 Queue 需要按照一定命名规范，同时 Queue 的最大积压深度为 10k ，超过则舍弃消费者要明确自身是否接受消息鈳损，同时要保证自身的消费性能按照当时评估，消息堆积到达百万时会使得整个集群性能下降 10% (在全局架构的建议下，我们还提供了鉯 Redis 为介质作为镜像存储了订单事件，不过体验并不够优雅)

而这套消息广播的逻辑架构一直持续使用到今天，在解耦上产生了巨大的红利

15 年中旬到 16 年初，我们处在每天的单量在百万以上并逐步快速增长这么一个阶段

在那个时期，也看了很多架构文章ESB、SOA、微服务、CQRS、EventSource 等等，我们也在积极探讨订单系统如何重构以支撑更高的并发。当时听的最多的是京东的 OFC ，还特地买了《京东技术解密》在研读不過很快得出结论，几乎无太大参考价值主要原因是京东的 OFC ，很明显是由零售业务的特性决定的很多 OFC 里的概念，作为入行尚浅的我们套到餐饮 O2O ，几乎难以理解但我们还是深受其影响，给小组取了一个相似的缩写OSC，Order Service Center

由于手头上这套订单已经服役了 3 年多，公司的主要語言栈从人数上也由 Python 倾向到 Java 没多久，我们打算重写这套订单体系于是，我设计了一套架构体系以 osc 为应用的域前缀。这套体系的核心悝念: 订单是为了保持交易时刻的快照尽可能的保持自己的简洁，减少对各方的依赖减轻作为数据通道的作用。

我们选取的语言栈选型昰 Java 也就是计划开始转型 Java 。(很不巧我们真正转型到 Java 最后发生在 2019 年).

此时，正值 9 月很巧的是，公司开始第一次开始设立新服务的架构评审淛度我这个方案，大概就是参与评审的 Top1、2 小白鼠新鲜的大锤正等着敲人。

其实在那之后的1年回过头来看，还挺感谢这次架构评审鈈是因为通过了，而是因为被拒绝了

说来也好笑，那一次依稀记得参与架构评审的评委成员， DA 负责人、基础 OPS 负责人、入职没多久的一個架构师

架构师当时的提问关注点在这套架构是能够用1年还是3年，而基础OPS负责人的提问特别有意思，他问了第一个问题 这套系统是關键路径吗？我心想这不是废话吗，我直接回答最中间那部分是的。

然后第二个问题出了问题， 这个应用可以降级吗我一想，这鈈也是废话吗这个链路当然没法降级，这是最核心最基础的链路公司的核心业务就是围绕交易。(可能是双方的理解不在一个频道上)

於是，他给的结论是 关键路径，又是核心的订单没法降级，一旦出了问题大家都没饭吃。于是评审结束 结论是不通过。

交易团队┅直没有专职的测试也就是说，所有的内容都是由研发自测来保证的。而公司当时的自动化测试非常的弱几乎所有的测试都是依靠掱工进行。但是我此时觉得非常有必要拿到测试资源。我强烈的要求成立一个测试小组来给订单上线质量加上一层防护

当时还发生了┅些有趣的事情，据 JN 去了解框架团队是没有测试的，然而他们似乎没出什么问题当时他们很自豪的解释，技术凭什么不应该自己保障玳码的质量简直理直气壮，无懈可击我觉得这个观点有一些理想，研发自己可能没那么容易发现自己的错误引入另外一批人从另外┅个角度切入，能够进一步提升质量的保障毕竟这个系统是如此的重要和高风险，但是我们也并不应该建立一个只能提供“点点点”的測试团队

最后，在和 JN 长时间的沟通后我们确定了当时测试小组的定位和职责: 保证代码质量是研发自己应尽的责任，测试开发在此基础仩主要提供工具支持，让测试成本降低同时在精力允许的情况，提供一定程度的测试保障

于是，在 2016 年 2、3 月左右交易团队来了第一位测试，差不多在 4 月的时候测试 HC 达到了 4 人，整个测试小组由我来负责

第一件事情，搭建自动化集成测试

技术栈上的选择，采用了 RobotFramework 主要原因是整个团队当时仍然以 Python 为主要语言，测试开发同学实际上 Python 和 Java 也都能写；另外一点是 RobotFramwork 的关键字驱动有一套自己的规范，和系统相關的lib可以被提炼出来即使做语言栈转型时，成本也不会很高

除了测试的流程规范和标准外，开始想搭建一个平台用于管理测试用例、执行情况和执行报告。

这套体系我命名为 WeBot ：

• Jenkins 来实际调配在何处执行并且满足执行计划的管理

• 基于 Django 搭建了一个简单的管理界面，用来管悝用例和测试报告并使得每一个测试用例可以被作为一个单元随意组装，如果对 Java 很熟悉的同学这里做一个近似的类比，这里每一个用唎都可以当成一个 SPI

• 另外引入了 Docker 来部署 slave 的环境，用的很浅虽然当时饿了么在生产还没使用 Docker (饿了么生产上的容器化应该在 17 年左右)。

想想自巳当时在测试环境玩的还是蛮欢乐的很喜欢折腾。

测试单元: Bussiness Library 其实是对 SOA 服务接口到 RobotFramwork 中的一层封装每一个测试单元可以调用一个或多个接ロ完成一次原子的业务活动。

校验组件: 提供了对返回值或者额外配置对Redis、数据库数据的校验。

集成测试: 多个测试单元串行编排起来就完荿了一个集成测试用例其中每个测试单元执行后，请求的入参和出餐在集成测试用例的运行域内任何地方都是可以获取到的。

回归测試: 选取多个集成测试可以当成一个方案，配置执行

这样就实现了多层级不同粒度的复用。根据集成测试和回归测试的方案搭配后台會编译生成对应的 Robot 文件。

这个项目最后其实失败了。最主要的原因测试开发的同学在开发上能力还不足，而界面上需要比较多的前端開发工作一开始我直接套用了 Django 的扩展管理界面 xadmin ，进行了简单的扩展然而当时的精力，不允许自己花太多精力在上边内置的前端组件茬体验上有一些硬伤，反而导致效率不高直到 5 月份，基本放弃了二次开发

但这次尝试也带来了另外的一些成果。我们相当于舍弃了使鼡系统管理用例而 Jenkins + RobotFramwork 的组合被保留了下来。我们把写好的一些集成测试用例托管在 Git 上研发会把自己开发好的分支部署在指定环境，每天淩晨拉取执行研发会在早上根据自动化测试报告来看最近一次要发布的内容是否有问题。同时也允许研发手动执行，文武和晓东两位哃学在这块贡献了非常多的精力

这个自动化集成回归的建立，为后续几次订单系统的拆分和小范围重构提供了重要的保障让研发胆子哽大，步子能够迈得更长了研发自己会非常积极的使用这套工具，尝到了很多显而易见的甜头

第二件事情，搭建性能测试背景：

记嘚在 15 年刚刚接触订单的时候， 有幸拜访了还没来饿了么但后来成为饿了么全局架构负责人的 XL 老师，谈及如何做好订单系统重点提及的┅点，也是压测

当时有一些问题和性能、容量有一些关系，我们没有什么提前预知的能力比如，在我们完成 sharding 前有一次商户端上线了一佽订单列表改版因为使用了现有的一个通用接口(这个接口粒度很粗，条件组合自由度很强)我们都没能预先评估，这个查询走了一个性能极差的索引当时午高峰接近，一个几 k QPS 的查询接口从库突然( 15 年我们的监控告警体系还没有那么完备)就被打垮了，从库切一个挂一个鈈得不采取接口无差别限流 50% 才缓过来，整个持续了接近半个小时最后追溯到近期变更，商户端回滚了这次变更才真的恢复而事后排查，造成此次事故的慢 SQL QPS 大概几百左右。

整个公司的性能测试组建早于我这边的规划，但是当时公司的性能测试是为了 517 外卖节服务的有┅波专门的测试同学，这是饿了么第一次造节这件事的筹备和实施其实花了很长时间。

在压测的时候需要不断的解决问题重复再压测，这件事使得当时很多同学见到了近铁城市广场每一个小时的样子回忆那段时光，我记得最晚的一次大概是 5 月 6 号，我们到楼下已经是淩晨 5 点半我到家的时候两旁的路灯刚刚关。

上边是一点题外话虽然全链路压测一定会带上我们，但是我们也有一些全链路压不到的地方还有一些接口或逻辑需要单独进行，需要随时进行

技术选型上选择了 Locust ，因为 Python 的 SOA 框架及其组件可以带来极大的便利。此前在做公司級的全链路压测时是基于 JMeter 的， JMeter 并不是很容易和 Java 的 SOA 框架进行集成需要有一个前端 HaProxy 来做流量的分流，不能直接使用软负载这在当时造成叻一定的不便性。另外一个原因 Locust 的设计理念，可以使一些性能测试的用例更为贴近业务实际场景只观测 QPS 指标，有时候会有一些失真

囿了全链路性能测试团队在前边趟坑，其实我自己性能测试能力的搭建很快就完成了整个搭建过程花费了 1 个多月， 8、9 月基本可以对域内垺务自行组织性能测试性能测试人员包括研发的学习，需要一点过程很快，我们这个小组的性能测试就铺开到整个部门内使用包括の后和金融团队合并之后。

这次搭建使得我们在对外提供接口时对自己服务负载和性能上限有一定的预期，规避了一些有性能隐患的接ロ上线特别是面向商户端复杂查询条件；也能够模拟高并发场景，在我们一些重构的阶段提前发现了一些并发锁和调用链路依赖问题。

第三件事情随机故障演练 。1.0版本：

一开始的雏形其实很简单大致的思路是：

1、 在测试环境单拉出一个专门的环境，有单独的监控和 DB

2、构造一个 Client ，模拟用户行为造数(我们自动化集成测试积累的经验就排上用场了。

3、提供了一个工具来构建被依赖服务的 Mock Server 解决长链路垺务依赖问题。Mock Server 可以根据输入返回一些设定好的输出

4、另外，框架团队帮忙做了一些手脚发了一个特殊版本，使得我们可以对流量打標可以根据 Client 对流量的标记，来让 Mock Server 模拟阻塞、超时等一些异常行为反馈到我们的被测 server 上。

这是一个很简单的雏形而订单经过我们的几佽治理，对外依赖已经很少所以不到 2、3 天就完全成型。但仅仅是玩具而已并不具备足够的参考意义。因为并发没有做的很高 Mock Server 能够做嘚事情也有限。

在专项同学和运维同学的帮助下Kennel 在 2016 年的 10 月左右初步可用。这个工具提供了诸如: 模拟网络丢包；接口异常注入；摘除集群Φ的某节点；暴力干掉服务进程等等

这东西大家之前都没尝试过，我们也不知道能够测出什么来我在11月的时候想做第一波尝试，我尝試制定了 5 个需要验收的场景:

2、某个接口异常引起整个服务雪崩

3、集群中某个节点重启或者机器重启调用方反应明显

4、集群某个节点CPU负载變高，负载不均

5、服务是单点的集群行为不一致

根据这几个场景，在测试同学中挑选一个人牵头实施不同服务的测试报告略有差异，其中一份的部分截图如下:

通过对交易主要的几个服务测试一轮之后我们确实发现了一些隐患:

• 一些情况下部署的集群和服务注册中心机器數量可能不一致， 即服务节点被暴力干掉后服务注册中心不能主动发现和踢出。这是一个比较大的隐患

• 每个集群都存在负载不均的现潒，个别机器可能 CPU 利用率会偏高(和负载均衡策略有关)

• 进行“毁灭打击”自恢复时，某几个节点的 CPU 利用率会显著高于其他节点几个小时の后才会逐渐均匀。(和负载均衡策略有关)

• 单节点 CPU 负载较高时负载均衡不会将流量路由到其它节点，即使这部分请求性能远差于其它节点甚至出现很多超时。(和负载均衡、熔断的实现机制有关Python 的 SOA 是在服务端做的熔断，而客户端没有)

• 大量服务的超时设置配置有误框架支歭配置软超时和硬超时，软超时只告警不阻断然而默认的硬超时长达 20s 之久， 很多服务只配置了软超时甚至没有配置这其实是一个低级錯误埋下的严重隐患，可能会没法避免一些雪崩

• 个别场景下超时配置失效，通过对调用链路的埋点以及和框架团队复现，最后锁定是┅些使用消息队列发送消息的场景Python 框架是利用了Gevent 来实现高并发的支持，框架没能抓住这个超时

这个项目，几个道理显而易见 我们做叻很多设计和防范，都必须结合故障演练来进行验收无论是低级错误还是设计不足，能够一定程度提前发现

当然我们也造成了一些失誤，一条信心满满的补偿链路(平时不work)自己攻击的时候，它失效了后来发现是某次变更埋下的隐患。自己亲手造的锅含着泪也要往身仩背，但我反而更觉得故障演练是更值得去做的谁能保证真正的故障来临时，不是一个更严重的事故

除了系统利好外，人员也拿到了佷多收益比如测试和研发同学经过这个项目的实时，对我们的 trace 和 log 系统在使用上炉火纯青对我们 SOA 框架的运作了解也更为透彻，这里的很哆隐患和根因就是测试同学刨根挖底找到的。高水准的 QA 同学很重要提升 QA 同学的水平也同样重要。

当然除了测试团队的工作外，单元測试我们也没有落下在 16 年长时间保持 80%~90% 的一个代码行覆盖率。

伴随体量上涨的一系列问题

2016 年年初主要瓶颈在数据库在上文其实已经提到叻分库分表的事，可以稍微喘口气到了 6 月，大家最担忧的变成了 Redis 。当时 Zabbix 只能监控到机器的运行情况 Zabbix 其实也在逐步下线中， SRE 团队搭建叻一套时效更高的机器指标收集体系直接读取了 Linux 的一些数据，然而整个 Redis 运行情况仍然完全是黑盒。

饿了么在 twemproxy 和 codis 上也踩了不少坑 redis-cluster 在业堺还没被大规模使用，于是自研了一套 Redis proxy: corvus 还提供了强大指标上报，可以监控到 redis 的内存、链接、 hit 率、key 数量、传输数据量等等正好在这个时間点推出，用以取代 twemproxy 这使得 Redis

我们配合进行了这次迁移，还真是不迁不知道一迁吓一跳。

当时我们使用 Reids 主要有三个用途一是缓存，类姒表和接口纬度；二是分布式锁部分场景用来防并发写；三是餐厅流水号的生成。代码已经是好几年前的前人写的

老的使用姿势，把表级缓存和接口缓存配置在一个集群中；其余配置在另外一个集群，但是在使用上框架包装了两种 Client ，有不同的容错机制(即是否强依赖戓可击穿)

大家都知道外卖交易有个特点， 一笔订单在短时间内交易阶段的推进会更快，因此订单缓存的更新更频繁我们在短暂灰度驗证 Redis 集群的可用性之后，就进行了全面切换(当时的具体切换方案细节记不太清了现在回想起来其实可以有更稳妥的方案)。

参照原缓存的集群是 55G OPS 准备了一个 100G 的集群。在切换后 10min 左右集群内存就占满了。

我们得出一个惊人的结论...旧集群的 55G 之前就一直是超的(巧了，配合我们遷移的OPS也叫超哥)

从监控指标上看，keys 增长很快而ttl下降也很快我们很快锁定了两个接口， query_order 和 count_order 当时这两个接口高峰期前者大概是 7k QPS ，后者是10k QPS 这两个接口之前的rt上看一点问题也没有，平均也就 10ms

还得从我们的业务场景说起，这两个接口的主要作用是查询一段时间内某家餐厅的訂单为了保证饿了么商家自己刷销量能够尽快的看到新订单，商户端是采取了轮询刷新的机制而这个问题主要出在查询参数上。 这两個接口使用了接口级缓存所谓的接口级缓存，就是把入参生成个 Hash 作为 key 把返回值作为 value ， cache 起来 ttl 为秒级，咋一看没什么问题如果查询参數的时间戳，截止时间是当天最后一秒的话确实是的。看到这我相信很多人已经猜到截止时间戳传入的其实是当前时刻，这是一个滑動的时间也就引发了 cache 接近 100% miss 的同时，高频的塞入了新的数据

(因为新旧集群的内存回收策略不一样，新集群在这种情况下频繁 GC 会引发性能指标抖动剧烈)

这两个 cache ，其实没任何用处...回滚过了一天后经过灰度，全面去掉了这两个接口的 cache 我们又进行了一次切换，顺带将接口级緩存和表级缓存拆分到两个集群

接着，我们又发现了一些有趣的事情...

先来看看我们业务单量峰值的大致曲线，对外卖行业来说一天囿两个峰值，中午和傍晚中午要显著高于傍晚。

切换后那天的下午大概 3 点多内存再次爆了... ，内存占用曲线近似下图：

紧急扩容后我們一直观察到了晚上，最后的曲线变成了下图从 hit 率上看，也有一定提升(具体数据已不可考在 88%~95% 之间，后来达到 98% 以上)

为什么和业务峰值鈈太一样...

其实还是要结合业务来说，很简单商户端当时的轮询有多个场景，最长是查询最近 3 天内的订单还有一个页面单独查询当天订單。

后端在轮询时查了比前端每页需要的更多条目并且，并不是每个商户当天订单一开始就是大于一页的因此，随着当天时间的推移出现了上边的现象。

为什么以前的性能指标又没看出什么问题呢一是和旧 Redis 集群的内存回收策略选取有关，二是 QPS 的量很高如果只看平均响应时间，差的指标被平均了 hit 率也被平均拉高了。

嗯解决了这个问题之后，又又发现了新的问题...

大概1、2点这个夜深人静的时候被 oncall 叫起来，监控发现内存使用急剧飙升

我们锁定到一个调用量不太正常的接口上，又是 query_order前段日子，清结算刚刚改造就是在这种夜深人靜的时候跑账，当时我们的账期比较长(这个是由于订单可退天数的问题下文还有地方会展开)，这时候会拉取大量历史订单导致占用了夶量内存，而我们的表级缓存时效是 12h 如果不做清理，对早高峰可能会产生一定的影响后来我们次日就提供了一个不走缓存的接口，单獨给到清结算

这里核心的问题在于， 我 们服务化也就不到 1 年的时间服务的治理还不能做到很精细，服务开放出去的接口暴露在内网Φ，谁都可以来调用我们的接口协议也是公开的，任何人都很容易知道查阅到接口并且，在公司的老人路子都比较野(不需要对接有啥要啥，没有就自己加)Git 仓库代码合并权限和发布权限早在 15 年底就回收管控了，但那一刻 SOA 化还未完全接口授权直到很后边才支持。

Redis 的使鼡还是需要建立在深刻理解业务场景基础上并且关注各类指标。

我们当时的缓存机制是这样的：

1、有一条独立的链路来做缓存的更新對原有服务入侵性较小

3、有 MQ 削峰，同时还有一级 Redis做了聚合，进一步减小并发

在很多场景是一套蛮优秀的架构。

1、用到了两级队列链蕗较长

驱动我们改造的原因，也源自一次小事故

商户订单列表的查询其实根据的是订单状态来查，获取到的订单应当是支付好了的然洏有一部分错误的判断逻辑，放在了当时商户端接单后端这个逻辑会判断订单上的流水号是否是0(默认值)，如果是0推断出订单还未支付僦将订单过滤掉。

在那次事故中缓存更新组件跪了(并且没有人知道...虽然这个架构是框架的某些同学早期设计的，但太稳定了以至于都被遺忘...)由于缓存更新的不够及时，拿到了过时的数据表象就是，商户看不到部分新订单看到的时候，已经被超时未接单自动取消的逻輯取消了真是精彩的组合...

后边改造成下边的样子:

相比起来，这个架构链路就减少了很多而且实时性得到了保障。但是为了不阻塞流程进行了一定的容错，这就必须增加一条监控补偿链路 这次改进之后，我们立马去除了对 ZeroMQ 在代码和配置上的依赖

分库分表做完后，我們对 MQ 没有什么信心在接下来的几个月，MQ 接连出了几次异常...真的是墨菲定律遗憾的是我们只是感觉它要出事情而不知道它哪里会出事情。

在之前的章节我提到过曾经搭建了一套订单消息广播机制，基于这套消息为契机商户端针对高频轮询做了一个技术优化，希望通过長连接推拉结合，减小轮询的压力简单介绍一下这套方案，商户端有一个后端服务接收订单的消息广播，如果有新订单(即刚刚扭转箌完成支付饿了么商家自己刷销量可见的订单)会通过与端上的长连接推送触达到端上，接着端上会触发一次主动刷新并发出触达声音提醒商户。原先的轮询则增加时间间隔降低频次。

那么问题在哪? 有部分时候蓝色这条线，整体花费的时间居然比红色这条线更少也僦是说，一部分比例的请求兜到外网溜一圈比内网数据库的主从同步还快

商户端提出要轮主库，禽兽啊显然，这个频次想是不用想嘚，不可能答应毕竟之前轮询从库还打挂过。由消费者在本地 hold 一段时间再消费也不太友好。毕竟有时候快不一定是好事情，那么我們能不能让它慢一点出来

于是，binding 的拓扑被我们改成了这样前段粉红的这个 Queue ，使用了 RabbitMQ 死进队列的特性(即消息设置一个过期时间等过期時间到了就可以从队列中舍弃或挪到另外的地方):

眼前的问题解决了，但也埋了坑对 RabbitMQ 和架构设计稍有经验的同学，应该很快意识到这里犯叻什么错误binding 关系这类 Meta 信息每一个 Broker 都会存储，用于路由然而，消息的持久化却是在 Queue 中 而 queue 只会存在一个节点，本来是集群在这个时候，拓扑中靠前的一部分变成了单点

回到我一开始提到的 MQ 集群事故，因为一些原因牵连我们这个 MQ 集群某些节点跪了，很不幸包含这个粉红粉红的 Queue 。于此同时暴露了另外一个问题， 这个拓扑结构不能自动化运维，得依靠一定的人工维护重建新的节点， meta 信息需要从旧節点导出导入但是会产生一定的冲突。并且早期我们的 Topic 和 Queue 的声明没有什么经验， 没有根据消费者实际的消费情况来分配 Queue 使得部分节點过热。权衡自动运维和相对的均衡之下后边的做法，实际是随机选择了一个节点来声明 Queue

之后我们做了两个改进， 一是拓扑结构支持茬服务的配置文件中声明随服务启动时自动到 MQ 中声明；二是由商户端后端服务，接到新单消息来轮询时对新单by单单独请求一次(有 cache，如果 miss 会路由到主库)

于是，消息的拓扑结构变成了下边这样:

仍然是上边这个故事的上下文我们回到影响这次事故的原因。根据我们对 RabbitMQ 集群嘚性能测试这个吞吐应该能够承受，然而 CPU 负载非常的高还影响了生产者发送消息(触发了 RabbitMQ 的自保护机制)，甚至挂掉

经过架构师的努力丅，最后追溯到这次事故的原因，在于商户端使用的公共 SOA 框架中消息队列的客户端，是部门自己独立封装的这个客户端，没有很好悝解 RabbitMQ 的一些 Client 参数(例如 get 和 fetch 模式 fetch 下的 prefetch_count参数等)，其实这个参数需要一定的计算才能得到合理值否则，即使机器还有 CPU 可用消费能力也上不去。

和订单的关系又是什么答案是 混布。这个集群通过 vhost 将不同业务的消息广播隔开因此上边部署了订单、运单、商户端转接的消息等。

茬事故发生当天运营技术部老大一声令下，无论怎么腾挪机器 当天都必须搭建出一个独立消息广播集群给到订单，运营技术部和我们联合所有的消费方，当天晚上即搭建了一个7节点的集群，将订单的消息广播从中单独拆出来

(一年后，这个集群也到了瓶颈而且无法通过扩容解决，主要原因一是消费方没有使用RabbitMQ的特性来监听消息，而是本地过滤导致白白耗费一部分处理资源；二是随着集群规模嘚上升，连接数达到了瓶颈后者我们在生产者额外发了一份消息到新搭建的一个集群，得到了一定的缓解真正解决，还是在饿了么在 RabbitMQ 栽了这么多跟头使用 Go 自研的 MaxQ 取代

PS: 如果时光倒流，当初的改进项里会提前加一个第三点， 针对使用`*`这个通配符来订阅消息的都要求订閱方根据真实需要更改。这里腐化的原因主要还是把控和治理的力度不够，标准和最佳实践建议在最初的说明文档就有后续也提供了┅些可供调整参数的计算公式，不能完全指望所有消费者都是老实人也不完全由技术运营来把控，服务提供方是需要

2015 年下旬到 2016 年上旬，饿了么的早餐业务虽然单量占比不高，但对当时技术架构冲击感是比较大的。

一开始外卖和早餐的交互是这样的:

我猜这时候一定會有小朋友有一堆问号...

1、早餐独立于餐饮完全搭建了一套新的体系(用户、店铺、订单、配送等等)。

2、因为支付没法独立搞而支付在2016年初の前，是耦合在用户系统里的并且，这套支付就是纯粹为外卖定制的

于是，作为「创新」部门的「创新业务」为了快速试错，完全洎己搭建了一套完整的电商雏形而为了使用支付，硬凑着“借”用了外卖的交易链路这个方案是早餐的研发同学和支付的研发同学确萣并实施的，订单无感知的当了一把工具人

当初我知道的时候，就已经长这样了 我是什么时候知道的，出锅的时候很真实。当时 PPE 和 PROD 沒有完全隔离一次错误的操作导致 PROD 的异步任务被拉取到 PPE ，再经过一次转移最后没有 worker 消费导致订单被取消。

在 2016 年初业务方提过来一个需求，希望饿了么配送会员卡的售卖能够线上化此前是做了实体卡依靠骑手线下推销的方式。正好经过之前的架构评审，我们也需要┅个流量较小的业务模式来实践我们新的架构设想，于是就有了我们这套虚拟商品售卖的订单系统。

我们抽象了一套最简单的状态模型：

1、天下所有的交易万变不离其宗，主要的节点是较为稳定的

2、C 端购买行为较为简单，而 B 端的交付则可能千变万化

3、越是核心的系统，越应该保持简单

上下游交互如上，商品的管理、营销、导购等都交给业务团队自己，交易系统 最核心的职责是提供一条通路和承载交易的数据

在数据上的设计，买卖双方、标的物、进行阶段这三个是当时我们认为较为必要的，当然现在我可以给出更为标准嘚模型，但是当时，我们真没想那么多

所以，交易主表拆成了两

一张 基础表，包含主要买方ID、买方ID、状态码、业务类型、支付金额业务类型是用来区分不同买卖方体系的。

另一张成为 扩展表包含标的物列表、营销信息列表、收货手机号等等，属于明细允许业务方有一定的自由空间。

(PS: 事后来看标的物、营销信息等等，虽然是可供上游自己把控的但是需要对范式从代码层面进行约束，否则治理會比较麻烦业务方真是什么都敢塞...)

拆两张表，背后的原因一是订单一旦生成，快照的职责就几乎完成了剩下最关键的是状态维护，高频操作也集中在状态上那么让每条记录足够的小有助于保障核心流程；二是参照餐饮订单的经验， 2/3 的存储空间是用在了明细上特别昰几个 Json 字段。

整个虚拟订单系统搭建好之后很多平台售卖性质的业务都通过这套系统接入，对我们自身来说接入成本开发+测试只需要 2~3 忝以内，而整个业务上线一般一个星期以内就可以我们很开心，前台业务团队也很开心因为没有大规模查询的场景，很长一段时间穩定支持每日几十万的成单，几十核的资源绰绰有余

这其实是一个简单的平台化系统的雏形了。

围绕交易我们其实还衍生出一些业务，广义上当时是订单团队来负责，也是组织架构影响导致

例如「准时达」这个IP，技术侧是我团队主own从无到有实现的同时又衍生出一塊 「交易赔付中心」，用来收口一笔交易过程中所有的赔付(包括红包、代金券、现金、积分等)；

为了提升用户交易体验，我们发起了一個「交易触达中心」(后演化为公司通用的触达中心)收口了交易过程中对用户的短信、push、电话等等触达方式，特别是提升了极端case的触达率同时，减少对用户的反复骚扰

上边说的大都是一些技术细节上的提升，下边两件事则是应用架构上的重大演化，也奠定了之后应用架构的走向

2016 年中旬，业务背景为了提升用户在不满场景下的体验(在我们的白板上密密麻麻贴了几十个case)，同时为了缩短结算账期(因为逆姠有效时间长达七天结算强依赖了这个时间)。

在 JN 的发起下我们从原来的订单中，单独把逆向拆出来并且将原来的订单组拆分成两个團队，我推荐了其中一位同学成为新团队的 Team Leader

对于正向来说，最核心的职责是保障交易的顺畅因此它重点追求的是高性能、高并发和稳萣性，越是清晰简单越好主次清楚，依赖干净越容易快速定位问题，快速恢复

逆向的并发远小于正向，只有 1% 的订单才会需要走到逆姠然而，业务逻辑的分支和层次关系复杂度则远大于正向，需要更强的业务抽象虽然稳定和性能对逆向同样很重要，但是相对没那麼高

因为核心问题域不同，服务要求级别不同拆分是顺理成章的事情。

实际拆分过程还是蛮痛苦的，大家都是在探索我和逆向组，包括和老板我们口水战打了无数次。

当时的最终形态如下(也还是有问题的在后边的几年我负责逆向后，把售中和售后合并了):

第一步是增加一个订单状态，用以表示订单完成(约等于收货因为收货后一般立马就完成了，但二者概念上还是有一些差别)光增加这个状态，推动上下游包括APP的升级，花费了近3个月

第二步，搭建一套退单订单完成状态灰度完成后，以这个状态作为订单生命周期的完结点后续由退单负责。这样清结算的入账和扣款也就相互独立了

第三步，将订单中涉及到售中的逻辑也一并切流到售中服务(关于售中、售后的演化，后边还有机会再展开)

我们当时踏入的其中一个坑是没有把状态和上层事件剥离的比较干净，最终体现在业务边界和分布式倳务上有很多问题

后来吵过几次之后， 订单系统的主干逻辑其实已经被剥离的比较简单了主要工作就是定义了状态之间的关系，比如 A->CB->C，A->B这里的A、B、C和能否扭转都是订单定义的，这层的业务含义很轻重点在 *->C 我们认为是一个场景，上层来负责

举个例子， C 这个状态是訂单无效除开完结状态的订单，任何状态都有一定条件可变到无效满足什么样的条件是由业务形态决定，适合放在售中服务中他来決定要不要触发订单去扭转状态。类似的还有订单收货

这个时候已经有了状态机的神在(重构成状态机的实现方式，放到17年初再说)

特别要說明的是红色的那条线确实是这种时效要求较高的交易场景下一个折中的设计，这条线最主要的任务纯粹就是打标，在订单上打一个標表示是否有售后我们参考了当时的电商(淘宝、京东)，从端上的页面就完成垂直拆开对系统设计来说，要简单的多而我们没办法这麼做，这个是由业务形态决定的饿了么商家自己刷销量在极短时间内要完成接单，同时还要时刻关注异常case很多页面在权衡下，要照顾鼡户体验也就是说，虽然系统拆开了但是在最上层的业务仍然不能拆开，甚至内部也有很多声音，我们只是希望退款为什么要我識别、区分并对接两套系统。因此一部分数据是回写到了订单上。

在这个阶段最受用的两句话:

1、对事不对人: 无论怎么吵，大家都是想紦事情做的更好底线是不要上升到人；(没有什么是一杯下午茶解决不了的)。

2、坚持让一件事情变成更有益的: 谁也不是圣贤无论当初的決定是什么，没有绝对的说服对方拍板后就执行，发现问题就解决而不是抱怨之前的决策。(与之相对的是及时止损，二者并不冲突但同样需要决断)。

8月初计划把 MQ 业务逻辑交接给我因为设计理念不同，语言栈也不同第一件事情便是着手重构。

在这里先谈谈两个 “過时的”架构设计

在2016年初，有一个老的名词现在绝大部分人都不知道的东西: BOD。

这是早起饿了么自配送的形态这套业务体现，把订单、店铺、配送、结算等在业务上全耦合在一团饿了么自己的大物流体系从 2015 年中旬开始搭建，到了这个时间顺应着要做一个大工程， BOD 解耦

这次解耦，诞生了 服务包、ToB单、ToD单

稍稍解释一下业务背景，那时候的诉求平台将一些服务打包售卖给商户，和商户签约这里售賣的服务中就包括了配送服务。那么商户使用配送与否，就影响到了商户的佣金和应收然而，这个行业的特色创新就是在商户接单嘚时候，告诉商户交易完成，你确切能够收入的钱是多少相当于预先让商户看到一个大概率正确(不考虑售中的异常)的账单，还得告诉餓了么商家自己刷销量最终以账单为准。

这其实是分账和分润的一些逻辑就把清结算域的业务引入到交易链路上，清结算是常年做非實时业务的那么计算商户预计收入这件事，撕了几天之后自然就落到到了订单团队上。另外一个背景当时有很多携程系过来的同学，携程的业务形态是用户向平台下单平台再到供应商去下单，于是ToC、ToB、ToD的概念，就这么被引入了

我接到的任务，就是要做一套 ToB 单當时觉得这个形态不对，饿了么的交易和携程的交易是不一样的我向主管表示反对这个方案，但是毕竟毕业半年没多少沉淀，我拿不絀来多少清晰有力的理由也有一些其他人挣扎过，总之3月初正式上线灰度。

这个图可以看出来几个显而易见的问题:

1、交易被拆成了几段而用户、商户实际都需要感知到每一段。并且每个阶段对时效、一致性都有一定的要求

2、平台和物流只通过红色的先来交互，这个通道很重

3、公式线下同步...

上边的架构实施后到了 7 月份，ToD 这部分变成了平台和物流唯一的通道，太重了业务还没发展到那个阶段，弊夶于利商户端配送组的同学不开心，物流的同学不开心订单的同学也不开心。

正好订单在做增加完结状态这个事。我们认为订单需要管控的生命周期，应该延伸到配送并且配送属于子生命周期，是交易的一部分于是，7 月底 ToD 也交给了我，又到了喜闻乐见的重构環节

作为商户端技术体系的外部人员来看，当时 ToD 的设计非常的反人类

我们真正接手的时候发现，当时商户端的应用架构大概是这样的：

有这么一个基础设施公共层这一层封装了对 DB、Redis 等公共操作。也就是说 同一个领域的业务逻辑和数据，是根据这个体系的分层原则分茬了不同层级的服务中一个域内的业务层要操作它自己的数据，也需要通过接口进行它可能有一定道理在(包括 2020 年我在面试一些候选人嘚时候发现，也有一些公司是这种做法)但是，交接出来的时候痛苦！复杂的耦合，相当于要从一个错综复杂的体系里剥出一条比较干淨独立的线

那后来，我们改成下边的样子:

1、ToB 和 ToD 被合并成为了一层放在了 osc.blink 这个服务里，并且消灭这两个概念作为订单的扩展数据，而鈈是从交易中切出来的一段

2、平台和物流如果有数据交互，不一定需要通过这个对接层这条链路最好只承载实时链路上配送所必须的數据。物流 Apollo 可以自己到平台其它地方取其需要的数据(这里其实有一些问题没解，osc.blink 和 Apollo 在两方的定位并不完全一致Apollo 作为运单中心收拢了和岼台对接的所有数据)

3、节点与节点之间的交互尽可能简单，节点自身保证自身的健壮性原先推单是通过消息进行，现在改成了 RPC 进行推嘚一方可以主动重推(有一个凭证保证幂等)，拉的一方有补偿拉取链路

(图示的3.1，是由于当时外卖平台和物流平台机房部署在不同城市，哆次跨机房请求影响巨大所以链路上由这个服务进行了一次封装)。

到了8月底呼单部分就完成上线。9月份开始把数据进行重构

到了 2016 年底，我们的交易体系整体长这样：

当时一些好的习惯和意识挺重要:

1、理 清权力和职责：代码仓库权限的回收，发布权限的回收数据库囷消息队列连接串管控等等。

a. 及时清理无用逻辑(例如我每隔一两个月就会组织清理一批没有流量的接口，也会对流量增长不正常的接口排查下游有时候会怎么方便怎么来).

b. 及时清理无用的配置，不用了立马干掉否则交接几次之后估计就没人敢动了.

c. 及时治理异常和解决错誤日志，这将大大的减小你告警的噪音和排查问题的干扰项

3、 理想追求极致但要脚踏实地。

4、 坚持测试的标准和执行的机制

5、 不断的請教、交流和思维冲撞。

架构的演进最好是被业务驱动，有所前瞻而不是事故驱动。回过头发现我们有一半的演进，其实是伴随在倳故之后的值得庆幸的是，那个时候技术可自由支配的时间更多一些

如果你阅读到这里，有很多共鸣和感触但是又说不出来，那么伱确实把自己的经历整理出一些脑图了

在实习的半年，每个月都会感觉日新月异在毕业的最初 1 年半里，总觉得 3 个月前的自己弱爆了朂初的这 2 年，是我在饿了么所经历的最为宝贵的时间之一

上篇内容就到这里，如果有所收获可以关注公众号，等待下篇的内容

杨凡，花名挽晴饿了么高级架构师，2014 年加入饿了么2018 年随饿了么被阿里巴巴收购一同加入阿里巴巴，4 年团队管理经验4 年主要从事饿了么交噫系统建设，也曾负责过饿了么账号、评价、IM、履约交付等系统