来源 | 阿里巴巴中间件（ID：Aliware_2018）
封图 | 东方IC
个人简介:
2014年12月加入饿了么，当时参与后台系统的研发(Walis+Javis=>Walle)，紧张面向客服和BD。
2015年5月开始打仗订单系统的研发，7月卖力订单研发组；度过单体运用到做事化这个阶段。
2016年初搭建订单的测试团队，订单拆分为正逆向后，紧张卖力正向和交付部分。
2017年做了一些平台搭建的探索。
2018年初卖力全体订单正逆向和交付，年中将下单、购物车部分一起归并，年底和商户订单部分整合，形成交易中台。
2019年10月从交易中台转出，近期做了一小段韶光的组织效能和架构。
我为什么会写这篇文章，究其缘由：
一是自己在交易域做了 4 年，有很多只有我才知道，才能串起来的故事，想把这些记录并保留下来。
二是创造后边的很多同学看交易体系时，一打仗便是分布式、SOA、逐日百万、千万数据量，只知道它是这个样子，很难明得背后的思考和缘由。伴随自己这几年的履历，想让大家能够更随意马虎的理解这个蜕变过程的缘故原由和进程，有甘有苦。
三是很多总结也好，方法论也好，更多是去除了“糟粕”呈现在大家面前，这里可能会轻微加一点“毒鸡汤”，现实不一定那么美好，我们有很多决议，现在回过分来看，大概是光彩，大概是缺点。
这篇文章希望通过一些发展的故事和思考来给读者呈现全体进程，大家可以看到非常多野蛮成长的痕迹，并会附带一些思考和总结，但不会像快餐式的总结很多大道理。
那我们就从2012年的邃古期间讲起。
邃古
在谈订单之前，我们往前再考古考古，在邃古时期，有一套利用 Python 写的系统，叫做 Zeus 的系统，这个 Zeus 包含了当时饿了么最核心的几大模块，比如订单、用户、餐厅，这些统统在一个代码库中，并且支配在同一台机器， Zeus 之外还有两大核心，即饿了么 PC ，也便是很多老人常提的「主站」，以及面向商户的 NaposPC 。这些系统通过 Thrif 协议通信。除开这条链路之外，所有凌乱的内部功能，全在一个叫 walle 的系统中，这个 Walle 系统是采取 PHP 写的。
那么当时的 Zeus ，大概长这个样子：
据不严格讲求，从 Git 的提交历史看，订单部分的第一个 commit 是余立鑫同学于 2012 年 9 月 1 日提交的，内容是\"大众 add eos service for zeus. currently only defind a simple get api. \公众，这个 EOS 指的便是订单系统，即 ElemeOrderService 的简称，这个名词沿用到了本日，成为交易正向的订单部分，乃至一段韶光是订单组的代名词。
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 年。
可以说是正处于相称混乱，又高速发展的期间。我们称那个韶光是一边开着跑车一边换轮胎。
Zeus 解耦
和订单真正密切干系的第一个 Super 任务，大概是从 6 月旁边开始 --- Zeus 解耦，HC老师是 Python 框架的卖力人，也是个人最佩服和敬仰的技能专家之一，在美国举行 Qcon 上，作为首席架构师先容过当时饿了么整体技能架构。刚才在邃古期间已经说到， Zeus 是一个巨型单体运用，为了今后各个部分能够快速发展，降落耦合和牵连影响等，公司启动了 zeus 解耦项目，总之就两个字，拆分。
经由 1 个多月的密集会议，完成了拆分的方案。说的彷佛没那么难，但是这场口水战当时打的不可开交，拆分后不同的做事归属于谁？模块和模块之间并没有切分的那么干净，A和B做事中的边界怎么定等等一系列问题。当时的我还不足格参与谈论。
结论是， Zeus 将要拆分成下边的几个主理事:
zeus.eos => 订单做事
zeus.eus => 用户做事
zeus.ers => 商家做事
zeus.eps => 营销做事(新产物)
zeus.sms => 短信服务
...
第一阶段
每个被拆分后的做事，随之进行的是新的一波重构和拆分。例如从 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 ，都会引爆全站。
Shardin 后物理构造如下:
一次更新操作逻辑如下:
我们实在是做了两维 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 年初，我们处在每天的单量在百万以上并逐步快速增长这么一个阶段。
OSC
在那个期间，也看了很多架构文章，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 ：
采取 RobotFramwork 来作为测试用例实行的根本
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 能够做的事情也有限。
2.0版本：
JN 调集了一些同学，参照 Netflix 的 Choas Monkey 为原型，造了一个轮子，我们称之为 Kennel 。
掌握中央设计图如下:
在专项同学和运维同学的帮助下，Kennel 在 2016 年的 10 月旁边初步可用。这个工具供应了诸如: 仿照网络丢包；接口非常注入；摘除集群中的某节点；暴力干掉做事进程等等。
这东西大家之前都没考试测验过，我们也不知道能够测出什么来，我在11月的时候想做第一波考试测验，我考试测验制订了 5 个须要验收的场景:
1、超长分布式事务
2、某个接口非常引起全体做事雪崩
3、集群中某个节点重启或者机器重启，调用方反应明显
4、集群某个节点CPU负载变高，负载不均
5、做事是单点的，集群行为不一致
根据这几个场景，在测试同学中挑选一个人牵头履行。不同做事的测试报告略有差异，个中一份的部分截图如下:
通过对交易紧张的几个做事测试一轮之后，我们确实创造了一些隐患:
一些情形下支配的集群和做事注册中央机器数量可能不一致，即做事节点被暴力干掉后，做事注册中央不能主动创造和踢出。这是一个比较大的隐患。
每个集群都存在负载不均的征象，个别机器可能 CPU 利用率会偏高。(和负载均衡策略有关)
进行“毁灭打击”自规复时，某几个节点的 CPU 利用率会显著高于其他节点，几个小时之后才会逐渐均匀。(和负载均衡策略有关)
单节点 CPU 负载较高时，负载均衡不会将流量路由到其它节点，纵然这部分要求性能远差于其它节点，乃至涌现很多超时。(和负载均衡、熔断的实现机制有关，Python 的 SOA 是在做事端做的熔断，而客户端没有)
大量做事的超时设置配置有误，框架支持配置软超时和硬超时，软超时只告警不阻断，然而默认的硬超时长达 20s 之久，很多做事只配置了软超时乃至没有配置，这实在是一个低级缺点埋下的严重隐患，可能会没法避免一些雪崩。
个别场景下超时配置失落效，通过对调用链路的埋点，以及和框架团队复现，末了锁定是一些利用行列步队发送的场景，Python 框架是利用了Gevent 来实现高并发的支持，框架没能捉住这个超时。
...
这个项目，几个道理显而易见，我们做了很多设计和戒备，都必须结合故障演习训练来进行验收，无论是低级缺点还是设计不敷，能够一定程度提前创造。
当然我们也造成了一些失落误，一条信心满满的补偿链路(平时不work)，自己攻击的时候，它失落效了，后来创造是某次变更埋下的隐患。自己亲手造的锅，含着泪也要往身上背，但我反而更以为故障演习训练是更值得去做的，谁能担保真正的故障来临时，不是一个更严重的事件。
除了系统利好外，职员也拿到了很多收益，比如测试和研发同学经由这个项目的实时，对我们的 trace 和 log 系统在利用上出神入化，对我们 SOA 框架的运作理解也更为透彻，这里的很多隐患和根因，便是测试同学刨根挖底找到的。高水准的 QA 同学很主要，提升 QA 同学的水平也同样主要。
当然，除了测试团队的事情外，单元测试我们也没有落下，在 16 年永劫光保持 80%~90% 的一个代码行覆盖率。
伴随体量上涨的一系列问题Redis利用的改进利用姿势的管理：
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、有一条独立的链路来做缓存的更新，对原有做事入侵性较小
2、组件可复用性较高
3、有 MQ 削峰，同时还有一级 Redis，做了聚合，进一步减小并发
在很多场景，是一套蛮精良的架构。
缺陷:
1、用到了两级行列步队，链路较长
2、实时性较差
驱动我们改造的缘故原由，也源自一次小事件。
商户订单列表的查询实在根据的是订单状态来查，获取到的订单应该是支付好了的。然而有一部分缺点的判断逻辑，放在了当时商户端接单后端，这个逻辑会判断订单上的流水号是否是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->C，A->B，这里的A、B、C和能否旋转都是订单定义的，这层的业务含义很轻，重点在 ->C 我们认为是一个场景，上层来卖力。
举个例子， C 这个状态是订单无效，除开完结状态的订单，任何状态都有一定条件可变到无效，知足什么样的条件是由业务形态决定，适宜放在售中做事中，他来决定要不要触发订单去旋转状态。类似的还有订单收货。
这个时候已经有了状态机的神在(重构成状态机的实现办法，放到17年初再说)
特殊要解释的是赤色的那条线，确实是这种时效哀求较高的交易场景下一个折中的设计，这条线最紧张的任务，纯粹便是打标，在订单上打一个标表示是否有售后。我们参考了当时的电商(淘宝、京东)，从端上的页面就完成垂直拆开，对系统设计来说，要大略的多，而我们没办法这么做，这个是由业务形态决定的，商家在极短韶光内要完成接单，同时还要时候关注非常case，很多页面在权衡下，要照顾用户体验。也便是说，虽然系统拆开了，但是在最上层的业务仍旧不能拆开，乃至，内部也有很多声音，我们只是希望退款，为什么要我识别、区分并对接两套系统。因此，一部分数据是回写到了订单上。
在这个阶段，最受用的两句话:
1、对事不对人: 无论怎么吵，大家都是想把事情做的更好，底线是不要上升到人；(没有什么是一杯下午茶办理不了的)。
2、坚持让一件事情变成更有益的: 谁也不是圣贤，无论当初的决定是什么，没有绝对的说服对方，拍板后就实行，创造问题就办理，而不是抱怨之前的决策。(与之相对的是，及时止损，二者并不冲突，但同样须要决议确定)。
物流对接
8月初操持把 MQ 业务逻辑交卸给我，由于设计理念不同，措辞栈也不同，第一件事情便是动手重构。
在这里先谈谈两个“过期的”架构设计。
ToC & ToB & ToD：
在2016年初，有一个老的名词，现在绝大部分人都不知道的东西: BOD。
这是早起饿了么自配送的形态，这套业务表示，把订单、店铺、配送、结算等在业务上全耦合在一团。饿了么自己的大物流体系从 2015 年中旬开始搭建，到了这个韶光，顺应着要做一个大工程， BOD 解耦。
这次解耦，出身了做事包、ToB单、ToD单。
稍稍阐明一下业务背景，那时候的诉求，平台将一些做事打包售卖给商户，和商户签约，这里售卖的做事中就包括了配送做事。那么，商户利用配送与否，就影响到了商户的佣金和应收，然而，这个行业的特色创新，便是在商户接单的时候，见告商户，交易完成，你确切能够收入的钱是多少，相称于预先让商户看到一个大概率精确(不考虑售中的非常)的账单，还得见告商家，终极以账单为准。
这实在是分账和分润的一些逻辑，就把清结算域的业务引入到交易链路上，清结算是常年做非实时业务的，那么打算商户估量收入这件事，撕了几天之后，自然就落到到了订单团队上。其余一个背景，当时有很多携程系过来的同学，携程的业务形态是用户向平台下单，平台再到供应商去下单，于是，ToC、ToB、ToD的观点，就这么被引入了。
我接到的任务，便是要做一套 ToB 单。当时以为这个形态不对，饿了么的交易和携程的交易是不一样的。我向主管表示反对这个方案，但是，毕竟毕业半年没多少沉淀，我拿不出来多少清晰有力的情由，也有一些其他人挣扎过，总之，3月初正式上线灰度。
这个图可以看出来几个显而易见的问题:
1、交易被拆成了几段，而用户、商户实际都须要感知到每一段。并且每个阶段对时效、同等性都有一定的哀求。
2、平台和物流只通过赤色的先来交互，这个通道很重
3、公式线下同步...
ToD
上边的架构履行后，到了 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、理清权力和职责：代码仓库权限的回收，发布权限的回收，数据库和行列步队连接串管控等等。
2、保持洁癖：
a. 及时清理无用逻辑(例如，我每隔一两个月就会组织清理一批没有流量的接口，也会对流量增长不正常的接口排查，下贱有时候会怎么方便怎么来).
b. 及时清理无用的配置，不用了立马干掉，否则交卸几次之后估计就没人敢动了.
c. 及时管理非常和解决缺点日志，这将大大的减小你告警的噪音和排查问题的滋扰项。
3、空想追求极致但要脚踏实地。
4、坚持测试的标准和实行的机制。
a. 坚持自动化培植
b. 坚持性能测试
c. 坚持故障演习训练
5、不断的请教、互换和思维冲撞。
6、Keep Simple, Keep Easy.
7、对事不对人。
架构的演进，最好是被业务驱动，有所前瞻，而不是事件驱动。回过分创造，我们有一半的演进，实在是伴随在事件之后的。值得光彩的是，那个时候技能可自由支配的韶光更多一些。
如果你阅读到这里，有很多共鸣和感触，但是又说不出来，那么你确实把自己的经历整理出一些脑图了。
在演习的半年，每个月都会觉得日月牙异，在毕业的最初 1 年半里，总以为 3 个月前的自己弱爆了，最初的这 2 年，是我在饿了么所经历的最为宝贵的韶光之一。
上篇内容就到这里，如果有所收成，等待下篇的内容。
作者信息：
杨凡，花名挽晴，饿了么高等架构师，2014 年加入饿了么，2018 年随饿了么被阿里巴巴收购一同加入阿里巴巴，4 年团队管理履历，4 年紧张从事饿了么交易系统培植，也曾卖力过饿了么账号、评价、IM、如约交付等系统。
☞讯飞智能语音先锋者：等到人机交互与人类互换一样自然时，真正的智能时期就来了！
☞中国GitHub开拓者数量年增长37%，为环球最快
☞从Nginx到Pandownload，程序员如何避免面向监狱编程？
☞只会高中数学运算就能创造算法？Google开源的AutoML-Zero有多厉害
☞Spring Cloud云架构下的微做事架构：部门微做事（Dept）
☞从Spring Cloud到Service Mesh，微做事架构管理体系如何演进？
