如何设计交易中台服务

通过电商平台进行购物通常会经过下单、支付、发货、收货等多个流程，我们往往使用【链路】的方式来表达该流程，如下图所示。在画交易链路图时需要注意：圆圈表示的是一个【状态】，圆圈之间的连线表示的是一个【事件】或【动作】；【状态】是在【事件】的驱动之下进行更新和变化的；【状态】具有持续性，而【事件】则是瞬时的。

像这样的一个交易链路是非常非常理想化的。现实中，随着用户量增大，交易中各种异常情况的出现，我们需要在该交易链路中引入各种 “负向的行为”。所以，真实的交易链路应该是如下图所示的情况这样： 交易链路应该是网状结构，而非线性结构！

面对这样的一个交易链路，应该如何进行实现呢？相比应该难不倒大家，哪怕多写几个 if-else 和 switch 语句也是可以落地实现的。

我们今天的问题是：假设你是一个交易中台的技术负责人，有几十条业务线会接入交易中台系统；最关键的点是这几十条业务线都有自己专门的交易链路（比如：有的业务线是做 C2C交易的，有的业务线是做 B2B 交易的，还有的业务线是做 C2B2C 交易的），这几十条交易链路都有自己的流转规则，如下图所示。

你作为交易中台的技术负责人，针对交易链路这一块，应该如何设计交易中台呢？既要方便业务线快速接入，也要方便后续交易中台的代码维护。

=============================================

解析：

交易链路图其本质是一个状态转换图，状态转换图表达的是一个【有限状态机】，即我们常说的【FSM】。我们基于 FSM 的思想来设计交易中台，整体架构如下图。

每条业务线都有自己的状态流转规则，而且状态流转规则会随着业务发展不断进行更新；要更轻松维护这几十个 FSM ，需要统一对其进行结构化存储，降低状态变更和代码维护的复杂度，并由【交易中台】作为 “FSM 执行机” 来执行交易流程。

为实现业务线快速接入，可通过 “配置化” 的方式实现接入；FSM 实现结构化存储之后，实现业务线配置化接入则是顺理成章的事情了！ 下面我们集中讨论如何实现 FSM 的结构化存储。

我们对交易链路进行抽象，可以剥离出一个最小的链路单元： 【一个当前状态】和【一个动作】和【一个更新后的状态】；那么所有的链路单元组合在一起，就是复杂的网状结构的交易链路了 ；我们用以下图来表示每一个交易链路单元。

在这个二维表格中，纵向第一列的每一个单元格表示【交易状态】，横向第二行的每一个单元格表示【动作】，中间单元格表示每一个对应的动作触发状态的变化。

我们将每一个最小的链路单元作为一条记录，可以很容易实现 FSM 的结构化表示，如下图二维关系表所示：

我们对每一个字段逐个进行分析：

1.【id】id 是一个自增型的主键，唯一表示一条记录；每一条数据记录就是一个最小的交易链路单元；

2.【fsm_type】fsm_type 用以区分不同的业务线，每一条业务线都有其自己独立的 FSM 编号；

3.【op_type】op_type 表示 动作或事件，该动作触发了交易状态的变化；

4.【role】role 用于描述触发动作的角色，例如：“同意退款” 这个动作只能由 “卖家” 这个角色来完成，“买家” 是没有权限触发的； 因此 role 这个字段可以更方便实现用户的权限控制；

5.【source_status】和 【target_status】source_status 是变更之前的 “交易状态”，target_status 是变更之后的 “交易状态”；综述以上几个字段，就是： role 角色的用户触发了 op_type 动作，将交易状态 source_status 变更为 target_status；

6.【handler】handler 这是整个交易中台设计的亮点，体现了插件化和可插拔的设计思想；在交易状态变更时需要执行的业务逻辑由 handler 进行执行，配置了什么样的 handler，就执行怎样的逻辑；很明显，在具体落地时，通常由【反射机制】实现字符串到实现类的映射。

对这 7 个字段完全理解之后，对交易链路中台的设计在一瞬间应该会有豁然开朗的感觉。任何一条业务线，在接入交易中台时，只需在该二维表格填写记录，表达出交易链路规则即可。

接下来就是交易中台的 FSM 执行机如何基于 FSM 的结构化存储来完成交易链路逻辑了；彻底理解整个交易中台的设计思想后，这一部分逻辑就非常简单了；这里将接口设计列出，具体实现大家自行实现，具体细节我们在后面的技术短文中继续进行分析。

//FSM 执行机引擎接口

public interface FsmEngine {

//初始化状态机配置

void init();

//执行状态机

void perform(FsmContext context);

//获取执行机运行后的状态

FsmNodeResult getPerformResult(FsmContext context);

}

//状态机在状态变化时执行的 handler 接口

public interface FsmAction {

//操作权限校验

void check(FsmContext context);

//执行状态机 handler

void execute(FsmContext context, FsmNodeResult fsmNodeResult);

}

最后，总结文中关键：

1.交易链路图其本质是一个状态转换图，表达的是一个FSM ， 即有限状态机；

2.对 FSM 进行结构化存储，降低交易状态变更和代码维护的复杂度，方便业务线配置化接入；

3.将每一个最小的链路单元作为一条记录，可以很容易实现 FSM 的结构化表示；

4.对 FSM 进行结构化存储时，涉及关键字段：【id】【fsm_type】【op_type】【role】【source_status】【target_status】【handler】，handler 是整个交易中台设计的亮点，体现了插件化和可插拔的设计思想。