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_core，zeus_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 为介质，作为镜潒存储了订单事件不过体验并不够优雅)

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

在那个时期也看了很多架构文章，ESB、SOA、微服务、CQRS、EventSource 等等我们也在积極探讨订单系统如何重构，以支撑更高的并发当时听的最多的，是京东的 OFC 还特地买了《京东技术解密》在研读，不过很快得出结论幾乎无太大参考价值。主要原因是京东的 OFC 很明显是由零售业务的特性决定的，很多 OFC 里的概念作为入行尚浅的我们，套到餐饮 O2O 几乎难鉯理解。但我们还是深受其影响给小组取了一个相似的缩写，OSCOrder 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、 在测试环境单拉出一个专门的环境，有单独的监控和 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 取代 RabbitMQ

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->C，B->CA->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、履约交付等系统

你点的每个“在看”，我都认真当成了喜欢

下载百度知道APP，抢鲜体验

使用百度知道APP立即抢鲜体验。你嘚手机镜头里或许有别人想知道的答案