百度交易中台之订单系统架构浅析

导读：百度交易中台作为集团移动生态战略的基础设施，面向收银交易与清分结算场景，为赋能业务提供高效交易生态搭建。目前支持百度体系内多个产品线，主要包含：小程序，地图打车，百家号，招财猫，好看视频等。本文主要从业务模型与架构设计两个方面介绍订单系统的构建过程。

本期公布第四期「周一见」活动中奖名单，详情见文末~

一、订单系统应具备怎样的能力？

订单打通用户、商家、商品、库存、售后等关键业务，是驱动交易全流程运转的核心。而订单系统承上启下，作为入口，涵盖了订单流程管理、库存与营销管理、算价引擎、履约子流程、售后以及退款信息管理等。

订单系统具备的能力可以按照下面三个角度进行切入拆解：

• 用户视角：支付算价、用户下单、物流跟踪、退款、订单检索等；

• 商家视角：订单状态管理、商家拆单、售后客诉管理等；

• 平台视角：拆单、CPS 分佣、风控、反作弊等。

二、交易中台如何提供服务？

交易中台基于现有的业务进行了抽象和归类，从接入主要分成如下三个类型：

• 通用型：业务自己维护商品，库存信息等信息，只需调用订单系统进行聚合支付。订单系统会根据业务诉求提供营销、退款、免密、推广、分账、一清、对账、风控等功能支持，主要业务有：百度地图、百度医疗、小度商城、度小店等。

  
  

• 自营型：订单系统提供完整的电商能力支持，包含商品、库存、营销、退款、售后、检索、物流跟踪等功能支持，主要业务有：招财猫、夸夸豆等。

  
  

• 直连型：业务自己调用渠道进行支付，支付完成之后将订单信息到同步到订单系统,订单系统通过计算推广信息进行流量主（包含：主播、推广作者、平台等）分佣，主要业务有：当当、亚马逊。

上图中介绍了通用业务和自营业务关键环节中的对比。可以看到：

• 通用业务主要侧重于支付的环节，包含的步骤是支付、支付通知、交易状态、退款等；

• 自营业务则在支付的基础上，扩展增加了商品管理，包括收发货、订单的超时取消等；

• 直连业务是针对某些业务定制的，主要的区别在于资金流的处理环节，在此不进行赘述。

三、订单的生命周期以及流程

在常见的电商环节中，订单从产生之后，主要包括订单确认、支付、发货、成功、取消、退款等，这些状态构成了一个有限状态机。

这些状态主要通过两个动作进行串联，即：订单的正向流程及逆向流程，正向流程是指用户购买产品或者服务的支付行为管理。逆向流程则是指用户发起售后造成的退款、退货行为管理。

3.1 正向支付流程

正向支付流程，由用户发起，代表用户向商家发起一笔交易，交易的流程入下图所示：

• 入口：从上图可以看的比较明确，订单可以从多个入口产生，包括常见的移动设备、网站、扫码等；

  
  

• 订单生成：随着用户确定订单，订单系统需要协调商品、营销、库存、风控等多个下游系统进行确认；

• 支付通道选择：生成订单之后，用户会跳转到支付界面，此时，订单系统会提供常见的支付通道供用户选择进行处理，常见的支付通道微信、支付宝、度小满支付等都由订单系统进行集成；

• 支付成功：用户支付成功之后，订单系统会通知上下游系统状态变更，同时对库存、营销进行扣减

• 商家发货、确认收货：订单支付完成之后，就会进入商家处理流程，对于实体商品的购买场景，中台订单会进入物流环节。对于没有实体的商品，中台会提供没有发货流程的交易模板。

• 交易成功：交易成功是订单的其中一个终态，代表用户和商家最终完成交易。

3.2 逆向退款流程

在实际的业务场景中，逆向退款主要是指商家进行退款的流程。通常可以在电商场景中的 7 天无理由退款、退货、用户售后流程中见到。

中台经过抽象业务流程之后，梳理了一套退款退货流程，如上图所示，退款退货发起之后，会进入商家审核的环节，商家确认通过之后，会进行用户处理。如果有物流环节的话，这时候会处理商家退货发货等。

业务流程就介绍到这里，接下来主要做系统架构方面的介绍。

四、架构浅谈

技术本身的目标是为业务服务，贴合业务的技术架构本身是最经济的选择。订单系统也是一样，架构随着业务的发展进新了逐步的优化和扩展。

在业务初期，架构如下图所示：

业务初期规模较小，功能也比较单一，只需要具备简单的支付、退款能力。所有功能都集中在一个系统，这样做的好处是简单快捷，容易部署，测试、开发效率高，是适合业务初期发展的架构。订单系统初期也为百度内部的火车票、小度商城、小程序的业务提供订单管理的能力。

随着业务不断扩张，虚拟商品的购买，退款已经不能满足业务，需要扩展支持带有物流商品订单，并且在支付方式部分，需要扩展支持各类购买入口和场景，比如聚合扫码支付、小额免密支付、周期代扣。随着业务扩展，后续又引入了诸如直播带货、拍卖、闪电购、订单评价、红包抢购，资产充值等更加丰富的场景。并且在功能扩展之外，整体交易中台还必须引入符合央行的监管规范改造，为了订单安全对接反作弊入口等诸多非功能方面的扩展。

为了支持业务的多方向扩展，原来的单体架构在功能需求方面会遇到了扩展难的问题，同时在性能方面，也逐渐无法满足吞吐量，响应时间以及扩展性等要求。

对于性能方面的扩展，需要将系统从单体改造为分布式的架构，这一部分的改造方案较为成熟，采用集团内的分布式数据库、缓存、以及商业平台近年来提供的云原生部署架构可以较为快速的进行提升。唯一的难点就在于订单分布式数据库的改造，由于业务初期已经充分考虑了订单的扩展进行持久层结构设计，这部分扩展也不难。

对于业务方面的扩展则是重头戏，订单系统构建了一套指令编排架构，通过不同指令调用不同的系统，然后抽象出模板，然后通过不同模板指令支撑不同业务场景。并且通过缓存，异步，降级等方式来提升性能。

分布式技术改造方案非常成熟，不在此进行赘述。接下来主要介绍一下基于指令进行设计方案，以及基于该方案专门设计的性能升级改造。

4.1 指令编排架构

不同的产品形态、交易类型产生的流程各式各样，为了满足这种不同场景中的业务需求，订单系统通过抽象了指令编排的设计，来实现业务流程的管理，从而使系统更具扩展性。

指令可以简单理解为相对独立的操作单元，比如常见的功能点都可以拆分为指令集，比如支付指令、用户指令等。优点在于代码的改动较小，遵循开闭原则。编排的方式类似于模板方法，不同的指令类似搭积木一样的进行叠加，即可实现不同业务的流程。

实际的实现中，订单系统将业务诉求拆解成不同的指令集，并且提供不同指令操作。

通过指令的组合形成规则，通过组合不同规则抽象出具体的模板，进行实例化从而产生具体的接入模型以供不同业务接入。

通过不同模板指令，可以快速支撑不同业务场景。通过对复杂指令集的优化，还可以使订单系统的吞吐量，拓展性，稳定性都得到很大提升。

下面列举一个订单拆分业务的案例进行说明。

• 拆单指令

用户支付完订单后，需要获取订单的支付信息，包括支付流水号、支付时间等。支付完订单接着就是等商家发货，但在发货过程中，根据平台业务模式的不同，可能会涉及到订单的拆分（如果是充值、消费类业务不存在发货情况）。

订单拆分原因一般分两种：

（1）电商场景的合并支付：用户商品来自不同商家，需要进行拆单进行分账；

（2）问答、咨询类场景：用户支付时并不知道哪个平台或者答者会接单、回答。只有用户提问最终完成服务之后才能确定具体的商家，该场景也需要后续拆单。

这种业务可以抽象为拆单指令进行实现。

• 通过指令编排实现拆单

创建拆单指令可以进行拆解，拆解为两种指令：拆单类型+拆单策略。根据业务需求通过指令的组合，抽象出规则并生成二种类型的模板（购物车拆单模板、咨询问答类拆单模板）并且实例化出接入模型对外输出。

当有购物车需求的业务可以跟进接入类型选择购物车拆单模板如：度小店。

当有咨询问答或者支付后拆单需求的业务可以使用咨询问答拆单模板如：医疗，百度地图，盎司手机充值等。

4.2 架构性能优化

上一章讲解了指令编排在生产环境中承担业务场景，接下来会讲解指令编排架构遇到的问题，以及进行优化。

上图是通过指令编排架构生成的一个通用下单模板，功能没有问题，但是在较高流量的场景下，会遇到性能方面的挑战。

可以看出的问题有：

• 顺序串行执行，调用链路过长，一旦中途一个指令执行出现问题，当次请求将返回失败，稳定性无法得到保障；

• 每个指令是独立的执行单元，所以每个指令都需要单独查询数据获取所需的数据，造成对数据库的请求成倍扩张。

针对问题，我们逐个进行击破。

4.2.1 长链路串行问题

首先是调用链过长问题做了以下优化。

• 针对数据变更不频繁的数据进行缓存化，动态更新机制，使用缓存淘汰算法（LRU）。核心思想是“如果数据最近被访问过，那么将来被访问的几率也更高”。如获取用户信息，商品信息接口。

• 针对非关键路径的指令配置异步执行或者降级执行。通过异步线程池来实现指令异步化，通过指令执行时间来判断是否降级处理。

通过以上二点完成调用链过长，稳定性无法保障的问题。

4.2.2 数据库重复获取压力

针对每个指令是独立执行单元要重复获取数据的问题使用以下解决方案。

同一线程重复查询数据做到线程级别传递，使用 ThreadLocal 方式进行线程之间的数据传递。

ThreadLocal 提供了线程本地变量，它可以保证访问到的变量属于当前线程，每个线程都保存有一个变量副本，每个线程的变量都不同。ThreadLocal 相当于提供了一种线程隔离，将变量与线程相绑定。

因通过线程池把非关键路径的指令异步化后，发现异步化的指令无法使用 ThreadLocal 进行数据传递，从而引入全链路追踪组件 TransmittableThreadLocal 进行异步线程数据的传递。

TransmittableThreadLocal 继承 InheritableThreadLocal，使用方式也类似。相比 InheritableThreadLocal，添加了：

（1）copy 方法用于定制 任务提交给线程池时 的 ThreadLocal 值传递到 任务执行时 的拷贝行为，缺省传递的是引用。注意：如果跨线程传递了对象引用因为不再有线程封闭，与 InheritableThreadLocal.childValue 一样，使用者/业务逻辑要注意传递对象的线程安全。

（2）protected 的 beforeExecute/afterExecute 方法执行任务(Runnable/Callable)的前/后的生命周期回调。

4.2.3 数据库性能提升

数据库受限于物理服务器的 CPU、内存、存储、连接数等资源，在处理上会遇到性能瓶颈，以及在主从同步存在延迟情况，为了下单的达到 2 万 QPS 并且主从无延迟就需要进行性能提升的优化。

首先针对不同业务需要进行数据的隔离以及拆分。需要跟进业务把不同的业务数据进行数据隔离，垂直拆分到不同的库和机器，从而分别提升不同业务的数据库性能和容量。（如：订单，退款，售后，客诉，商品，库存等）

某些业务虽然库垂直拆分了，但是单表数据增长太快，当单表数据量太大，会极大的影响 sql 的执行性能，这时 sql 会跑的很慢。这时就需要针对单表进行水平切分来减少单表的数据量。（如：订单相关表，退款相关表，CPS 记录表）

订单表进行水平切分，首先需要确定分表字段。

消费者用户查询订单最频繁的场景，是通过用户 id 以及订单号这两种类型进行查询，所以订单主表的设计需要兼容这两种查询。

在数据模型的设计上，由于数据库分表字段只能有一个，所以这里采用计算规则将订单号和用户 id 进行关联，即，让一个用户所有的订单都存储在一张单表之中，具体手段就是通过用户 id 的一种规则作为分表字段（shardingKey），订单 id 生成规则和分表字段做关联，具体就不进行展开说明。

这样不论通过用户 id 还是订单号查询都能取到分表字段，从而定位到具体的库和表。

因将整个订单库所有表按照统一规则进行切分，分表规则一致，保证按照同一用户或者订单都能在一个库，从而可以使用数据库事务。

针对数据库查询禁止不带分表规则信息的维度的查询，避免造成轮询数据库表造成慢查询情况。

对于查询用户 id 以及订单号之外的查询场景，分为两种实现：对于高实时性的查询，会建立额外的数据库索引表进行存储，比如手机号查询、外部订单号查询等。对于低实时性要求的查询，比如商家端查询订单数据，此时借助全文检索的外部数据存储（比如 ElasticSearch 等数据存储）实现查询，我们会通过数据库 binlog 同步工具，将订单信息同步到存储之中来提供查询。

另外，一定要保证数据查询要存在索引，保证数据库可控，能从长远保证库的扩展性和容量的提升。

五、总结

本文重点在介绍如何通过架构、技术实现等手段来搭建一个可靠、完善的订单系统。实际生产中，应该抓住业务上的关键问题，在满足业务的前提下，对流程、需求做合理的减法，以降低整体架构的复杂度。另外，应该合理利用开源项目和第三方平台服务满足系统需求，在技术方案和开发成本之间做到较好的折衷。

推荐阅读 ：｜百亿级流量的百度搜索中台，是怎么做可观测性建设的？

阅读原文：｜百度交易中台之订单系统架构浅析

百度架构师：

百度官方技术公众号上线啦！

技术干货 · 行业资讯 · 线上沙龙 · 行业大会

招聘信息 · 内推信息 · 技术书籍 · 百度周边

欢迎关注～