如何设计交易中台服务

　　通过电商平台进行购物通常会经过下单、支付、发货、收货等多个流程，我们往往使用【链路】的方式来表达该流程，如下图所示。在画交易链路图时需要注意：圆圈表示的是一个【状态】，圆圈之间的连线表示的是一个【事件】或【动作】；【状态】是在【事件】的驱动之下进行更新和变化的；【状态】具有持续性，而【事件】则是瞬时的。
　　像这样的一个交易链路是非常非常理想化的。现实中，随着用户量增大，交易中各种异常情况的出现，我们需要在该交易链路中引入各种 ＂负向的行为＂。所以，真实的交易链路应该是如下图所示的情况这样： 交易链路应该是网状结构，而非线性结构！
　　面对这样的一个交易链路，应该如何进行实现呢？相比应该难不倒大家，哪怕多写几个 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 是整个交易中台设计的亮点，体现了插件化和可插拔的设计思想。