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

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

**1、**订单系统应具有怎样的能力？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.1 正向支付流程

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

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

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

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

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

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

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

3.2 逆向退款流程

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

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

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

4、架构浅谈

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

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

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

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

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

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

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

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

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同步工具，将订单信息同步到存储之中来提供查询。

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

5、总结

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

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

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

百度架构师：

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

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

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