饿了么交易系统应用架构演进

内容来源：2017 年 12 月 2 日，饿了么研发总监石佳宁在“IAS2017互联网架构峰会”进行《饿了么交易系统应用架构演进》演讲分享。IT 大咖说（微信id：itdakashuo）做为独家视频合做方，经主办方和讲者审阅受权发布。

阅读字数：3176 | 8分钟阅读

嘉宾演讲视频及PPT回顾： suo.im/5qrxMT

摘要

业务系统的演进主要取决于业务场景，业务场景的定义和认知是随着公司发展而造成的，基本上有着必定体量的大公司技术架构都相对稳定，业务架构则主要是对业务发展产生影响，好的业务架构可以保证业务更好的发展。本次嘉宾将会为你们分享饿了么业务架构的演进之路。

当前形态

在讲当前形态前首先要介绍下几个基本概念。目前咱们的全部业务系统都是严格按照领域作划分和组成的，开发人员须要知道领域、链路和服务这几个概念间的关系和定义，一旦可以明确这些概念定义就可以容易明白业务和系统之间的关系以及系统和系统之间在职责上联系。

交易领域

在饿了么内部交易领域是相对大的范畴，是整个公司最重要的生命链路，所覆盖的内容也并不是是集中式的，而是分散在各个系统的职责上。好比客服系统看似和交易无关，但其实有交易职责的，由于它最终会影响到交易的结果。

所以咱们定义从用户下单开始一直到订单完成为止，直接影响到最后订单结果的内容都承载着交易的职责。

交易链路

交易链路是完成一笔交易所须要的最短路径，这其中的任意节点都是不可缺失的，一旦缺乏某一节点交易就没法达成。一个大的领域每每会有不少条业务链路，通常会有一条是最关键的，其他几条则是业务高点。

交易系统

交易系统相对就比较好理解了，全部的服务以必定的业务为边界具体组成的明确部分就是交易系统。

上图展现了参与交易的主要系统，能够看到除开订单和支付系统以外，还有不少影响交易结果但不承载完整交易职责的系统也在其中，整个交互关系很是复杂。正由于一个交易领域做为交易系统的复杂要求，因此交易系统自己的职责是很容易混乱的。

业务特性和基本划分

为了更清晰的肯定交易职责，咱们以交易订单为基础拆分出了正向链路和逆向链路两个部分。

上图是正向链路结构图，能够清晰的看到从用户下单、支付成功、系统确认到最后接单完成的整个过程实际上是很是简单的一个链路。

实际应用中也会将这个链路作的很是简单，由于定义正向链路所承载的主要职责是让一笔交易在技术和数据层面无缺无损的走到最后。

这套服务的系统要求是在系统自己IO、数据的可靠以及稳定性上，一些复杂的业务逻辑不会放到正向链路中。正向链路要保证的是在大流量高并发状况下可以处理的很好并完成天天千万级别调用。

上图所示的是逆向链路，它多出来了仲裁和交易取消申请等环节，逆向链路实际上是以全部异常场景处理为核心职责的。它的定义与正向链路恰好相反，正向链路重的是系统自己的可靠和性能，逆向链路重的是全部复杂场景的处理。

咱们在全部正常业务的处理过程当中，尤为是新增的业务上必定会考虑逆向链路的支持。

服务架构

这套服务架构大概分为三层，最底层为通用服务，这一层在交易领域内的职能和服务能力是应该被大范围复用的。

中间为核心服务层，是全部逻辑的承载，这一层分为交易支撑和交易保障两部分，这样的划分和前面提到的链路实际上是类似的，交易支撑承载的是流程职责，而一些业务场景会被单独剥离出来放在交易保障中。

最上层是对接的业务系统，几乎因此涉及到的交易系统都会对接底层的服务。

以这套架构为核心就会发现有大一部分是可以存下来或者是能够复用的。

系统架构

咱们的整个交易服务是比较垂直的，它的核心是流程，由于交易其实就是流程不停递归的过程。

整个系统架构的组件并不复杂，主要是Redis和MySQL。经过MySQL进行解耦，以防与其余系统有过多的交互。

当时的问题

在讨论问题以前，首先分享给你们咱们团队内部一直在说的一句话。

▶架构层面的一切努力都是为了知足业务的扩展性须要

作业务架构实际上是比较务虚的一件事，不像作组件或者中间件的架构那样有着明确的目标。业务需求的时刻改变使得业务架构的方案存在多种可能，结构人员须要在这些方案中选择出对的那个，那么怎么才算是对的方案呢？

咱们内部的评价标准是看这个架构可以使用多久，将来的两到三个月是否会消退掉。

遇到的难题

这里将咱们在整个架构演进过程当中遇到的问题先列举出来。

- 原系统职责庞大，维护和迭代成本很高，须要拆分。可是不知道怎么拆，也很难对怎么拆达成一致。

- 业务愈来愈复杂，接口和字段越加越多

- 新业务对老业务会形成冲击，兼容永远是考验功力的

- 系统稳定性要求高，不论是新业务上线、老业务迭代、技术改造等，都不容许宕机哪怕一秒。

案例-订单与物流交互服务

订单与物流的交互服务能够说是一个通用的案例，订单服务承载外卖的交易，配送的运营由运单服务负责。

饿了么的交易和物流是两个大的系统，由两个团队分别负责。为了在这两大致系间创建方便的对接，咱们设想了一个订单运单交互服务，让订单交易和物流之间的数据交互都经过它作中转。最终咱们实现了这样的一个服务，而且把必定的职能从订单服务和运单服务拆分出来。

在实现的过程当中咱们遇到了新的问题，首先这个交互服务出于性能和数据便携的考虑缓存了一部分的订单或运单的数据直接从接口输出。这样的话交易链路上就多了一个掌握数据的节点，一旦整个链路出现数据不一致或者其余问题，排查起来会至关困难。同时其余各个服务的接入方没法判断接口或逻辑的提供方，须要花费大量的时间沟通。

后来咱们发现实现这套服务后整个开发效率反而更低了，最后咱们仍是将交互复的职责还回订单服务和运单服务。

这让咱们意识到若是一个领域或系统的职责是清晰并独立的，那么就应该让它直接被其余各个系统使用。另外对于系统的拆分和领域的识别要有共识，这个共识不只仅是交互的双方。

案例-新业务的形态支持

在购买饿了么会员时生成的实际上是一个虚拟订单，当咱们开始接收到相似这样的业务需求的时候是有一点纠结的，由于原有的外卖订单流程有部分是支持该业务的，只不过须要在此基础上作一些兼容，因此当时咱们所面临着在创建一套新的系统和在原有系统上作兼容之间作出选择。

最后咱们选择新增虚拟订单服务，由业务形态以及当前逻辑的可复用程度决定，尽可能服用，拆分（解耦）永远比合并（内聚）容易

总体建议

基于以上所提到的案例，这里作一个总体的建议。

- 必定要有一张完整全面的架构图，以系统的维度标注出核心主链路，确保其始终清晰。

- 花时间去了解业务和它的发展，为将来作准备而不是直接作将来。

- 架构债务比代码债务更难还，评审checklist以及债务总结必不可少。

将来的发展

业务系统的发展每每紧随业务复杂度，可是这里有一个悖论，即若是业务都不知道如何发展，那么业务系统就更别谈发展了。

对此咱们有一些思考和实践，主要是在效率和效能方面。效率其实很好理解，就是如何改进架构使得更快的知足业务前进。效能则是在原先系统业务的能力上进行扩展。这二者并不是互相违背而是统一协调的，一个好的设计效率提升的同时效能也会随之提升。

基于这样的思考，咱们在内部作了一个尝试，把咱们对交易的理解付诸到一套系统上。交易无外乎几个形态，物品的交换、信息的交换和能力的交换，每每O2O或电商涉及到的都是相似能力的交换。

上图就是这套系统的整个架构。最上层是导购前台服务，负责与用户的直接交互，是全部数据的入口。中间的交易中台服务核心是合同的管理以及流程和能力的服务。最低层是全部的基础支撑服务，店铺、商品、帐户这些资源都是基础服务是交易数据的一部分，基于它们就会产生交易能力而后提供给前台业务。