如何搭建支付中台系统以及订单系统架构浅析

什么是中台

中台其实最早是起源于军事领域，在二战时期的美军在各个战场上，看起来有打不完的弹药、耗不完的燃料、充足的食品补给、及时准确的情报……但其资源却在万里之遥的美国本土，这一切是如何做到的呢？
就是依靠庞大的中台体系，支持到世界各战场。前方战场上的一名士兵，平均就有12名人员支持，在战场-基地-本土形成前、中、后台的效率系统。

国内互联网最早实行中台战略的就是阿里。

由于阿里涉及的业务线非常多，在没有中台之前都是每个业务自己去做一套系统，但是每个业务系统都有相同的模块，例如订单系统、支付系统、商户系统、短信系统等。因此就导致各个业务线重复造轮子的现象，业务端不仅需要对业务模块进行优化和升级，同时也需要维护这些基础支撑服务。

用一句话概括：中台就是将所有业务的公共模块抽象出来，单独创建一个中台系统统一对这些公共模块进行维护，统一输出服务提供业务方使用，让业务方能够集中全力发展业务。

中台解决什么问题
理解了中台的概念，那么就需要思考对于互联网公司，中台系统的搭建能够解决什么问题呢？

可以解决你的996问题
中台是独立于业务系统而又服务于业务系统的存在，业务系统的前台和后台是关联存在的，但是中台的定位就是出于整个公司层面，要服务于多条业务线。
因此通过建设中台系统，能够极大减少业务系统的工作量，提高业务端的工作效率，业务系统部门就不需要再为了这些基础服务而进行996了。

提高公司产品灵活性和市场竞争力
通过中台系统，业务只需要关系业务流程即可，轻装上阵，将重心配合市场方向去优化业务系统，对于市场上出现的新的业务模式和特殊需求能够更快的响应，帮助公司快速占领市场。

节约成本，结构清晰
对于中台最直观的感受就是提高工作效率和减少人力成本，不仅仅减少业务开发部门，同时也减少商务部门、法务部门等相关职能部门，所有的外部基础服务统一中台管理，对于整个产品架构的梳理会更加清晰，在产品设计方面也会更加快速，部门分工也更加合理。

支付中台如何落地
支付中台，首先咱们应该最关心的是中台这个关键词，因为实际每个业务都已经有支付能力了，但是由于每个业务对于支付的单独开发，导致资源的浪费，让业务将过多的精力用在基础支撑服务的维护和开发上，而无法集中精力去针对市场优化业务，不利于业务的沉淀和持续发展。
我认为当企业的业务线数量大，企业的主要业务线稳定情况下应该需要建立中台系统。
而建立企业的中台系统则需要首先调研企业的每个业务的场景和特点，然后对每个业务进行拆解，得到每个业务的组成模块，再分析出每个业务组成模块的一个合集，这样就能确定中台系统的定位和构成。

业务拆分思路
在设计之初需要确定业务，该业务的核心场景；
从核心场景往外剥离，确定哪些是基础服务；
确定基础服务与业务系统的分界；
确定好每个基础服务的分界后，需要对基础服务进行建模，以保证整个中台体系的兼容性和扩展性。

支付中台建模思路
基于业务，拆分为面向支付业务和面向资金核算两套体系。
基于场景，例如依据支付流程等进行拆分。
基于技术实现，例如出于对系统的性能等考虑拆分。

支付中台整体架构

通过上图，可以看出支付系统可以拆分为：收银台、交易核心、支付核心、渠道网关、账务系统、会计系统、清算系统、合规系统等。
收银台：主要应用于业务的提交结算场景，可以根据不同的业务配置不同的收银台模板。
交易核心：业务发起支付时，支付系统与业务方的前置模块，主要用于对业务的校验、接单、查询请求等处理。
支付核心：对于业务发起的交易进行支付处理，生成支付订单，可以根据不同的交易类型匹配不同的支付工具，支付核心根据渠道返回的支付结果，请求账务系统、清结算系统、数据中心、交易系统等逻辑处理。
渠道网关：主要是对接渠道，处理渠道报文，渠道接口请求，支付路由处理等。
账务系统：支付系统的账务处理中心，账务的冻结、解冻、出金、入金，根据不同的交易类型对账户进行记账，并将账务流水通知到会计系统，会计系统进行复式记账。
会计系统：会计系统可以作为公司的业财中台，主要是根据账务系统流水将业务数据转化为财务数据，如果公司有用友、金蝶等财务系统，可以将生成的会计分类同步到财务系统中。
清算系统：针对不同的业务类型，进行清分结算。
合规系统：对接反洗钱系统、反诈骗系统，保证支付安全合规。

支付链路

由业务方发起交易，通过收银台或者API发起，进入到交易系统，交易系统请求支付系统，支付系统接收到支付请求向渠道网关发起，渠道网关请求银行或支付公司；支付系统接收到结果后异步通知数据中心、清结算系统和合规系统。

异常处理机制
1）如何保证数据统一性？
支付系统最重要的就是数据的统一性，因为涉及到真实的资金情况，因此对于订单统一性的要求是最高的，否则会导致资损的情况产生。
我们可以针对每个业务设置一个业务代码，通过业务代码+订单号的方式，在每笔订单生成一个业务跟踪号。通过这个业务跟踪号能够将交易订单、支付订单、渠道订单、资金流水进行关联和约束，防止订单数据差异以及对整个订单生命周期的追溯。
每个系统的订单可以定义规则，例如：日期+系统代码+序号。

2）如何保证业务支付的稳定性和扩展性？

首先需要深入了解每个业务对于基础服务的应用场景，根据业务的应用场景包装出不同的交易产品（交易类型、例如充值场景、提现场景、担保场景等）。在支付核心系统中，通过支付能力的组合形成支付工具，根据支付工具在组合成不同的交易产品，例如通过鉴权+代扣的支付能力，可以组合成支付工具快捷支付，快捷支付可以与交易场景的充值对应。这样就能实现插件化开发，能够根据业务的需要完成不同的组合场景，提供支付系统的扩展性。

3）如何处理部分支付的异常流程？

例如用户的组合支付（红包、优惠券、支付宝支付）红包和优惠券扣款成功、支付宝支付失败，我们建立了一个异常管理组件，这种组合支付都需要报送到异常管理组件，通过异常处理组件的规则，对该异常情况发起反向退款流程。异常处理组件会向支付系统发起红包退款、优惠券退款，保证整体订单的状态一致性。

4）代付拆单，部分成功的情况

对于代付交易，如果拆单后，出现2笔子单成功，1笔子单失败，出现这种异常会将该异常子单发送到异常处理组件，异常处理组件发送到调度中心，可以重发；如果无法重发，可以人工支付后更新状态。

架构浅谈

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

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

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

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

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

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

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

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

4.1 指令编排架构

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

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

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

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

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

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

• 拆单指令

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

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

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

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

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

• 通过指令编排实现拆单

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

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

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