大中台战略下，中台将公司业务的公共能力下沉，并采用更加合理、可复用的架构和技术来实现这些基础能力。在电商行业内，将面临货物的采购、商品上架、交易发生、订单状态变化、客服介入等大量状态维护。每个状态之间具有很强的逻辑关联关系，比如：退款操作在发货前和发货后将是完全不同的流程,如图1订单退款流程。
图1 退款流程图
由此可见，对于复杂状态的管理是一个业务依赖，需求多变的场景。在公司初创期，可以采用硬编码方式，对于每一个操作进行状态判断，每一步操作定制一套逻辑链路。随着业务的增加，定制化链路显然不优雅，大量流程代码无法维护，此时中台通用解决思路就尤为重要，有限状态机（Finite State Machine，缩写：FSM）开始在中台落地。
1 有限状态机
有限状态机（以下简称FSM）又称有限状态自动机，简称状态机。维基百科定义是表示有限个状态以及在这些状态之间的转移和动作等行为的数学模型。
这个模型和业务中台遇到的问题十分吻合。图1是状态转移图，可以用来表示状态机，此外可以使用状态转移表来表示。如图2所示：
图2 状态转移表
可以看出，FSM是通过抽象为动作和状态，管理有限个状态转移的模型。动作是在给定时刻要进行的活动的描述，我们总结动作类型有如下：
进入动作：在进入状态时进行
退出动作：在退出状态时进行
输入动作：依赖于当前状态和输入条件进行
转移动作：在进行特定转移时进行
在FSM框架下，将流水线的状态流转流程进行了抽象和结构化，将复杂的状态转移图，分割成相邻状态的最小单元。这样相当于搭建了乐高积木，在这套机制上可以组合成复杂的状态转移图。
2 Spring StateMachine
Spring Statemachine框架主要是帮助开发者简化状态机的开发过程，让状态机结构更加层次化，我们来看下Spring SM怎么实现。首先最小的乐高模型如图3所示 ：
图3 SM最小单元
假如有状态 STATE1, STATE2和事件EVENT1, EVENT2。事件驱动状态流转。下面来分析下Spring SM的主要代码。
2.1 依赖pom
<dependency>
<groupId>org.springframework.statemachine</groupId>
<artifactId>spring-statemachine-core</artifactId>
<version>2.1.3.RELEASE</version>
</dependency>
2.2 创建状态机
通过注解来注册状态机的三要素：source、target、event
2.3 注解监听器
通过监听器感知事件发生，并相应的处理相关逻辑
2.4 运行状态机
3 交易中台
在交易场景，定义了自己的状态机框架，抽象了符合交易场景的状态角色：
初始状态、目标状态：状态关系
角色：不同角色有不同的操作权限，比如卖家、买家、系统、客服
操作：对应事件
handler：事件操作相应的action实现
因此一个事件我们可以定义为：在角色A，在初始状态S1下，执行OP1操作，将使用handler来处理，执行成功将状态设置为目标状态S2。
3.1 个性化FSM抽象
鉴于交易的个性化需要，扩展了状态表的条件，同时使用handler和Java反射，来对逻辑代码进一步结构化。到这一步后，我们可以将数据模板存储到数据库中。如图4：
图4 交易中台FSM状态表
通过改造，核心代码FSM执行引擎只有不到100行。通过注册业务handler，可以灵活的扩充业务能力。同时数据状态的维护是通过状态表，而不依赖手动编写代码，这对于代码质量的保证、工程回归测试都节省了大量的时间。也为中台实现配置化做好了铺垫。
3.2 中台赋能业务
中台沉淀了基础能力，如何实现？中台如何赋能业务的，业务是否满意呢？
看下面一个例子，基于交易，C2C、自营是两个具有极大区别的业务，他们有完全不同的两套业务流程。C2C平台需要对买卖两端进行担保，而自营更多的是给予买家保证权益。简化版流程如图5：
图5 简化版交易流程
通过中台FSM能力，我们只要能将状态图绘制出来，那么相应的状态流转表配置也已经产生。handler 只需要关注当前操作的业务逻辑，极大的解耦了状态和业务。
可以毫不夸张的说，一个新业务过来，中台能在2天时间内单人完成状态机配置开发上线。这就是中台的效率。
4 总结
FSM解决复杂业务状态流转的问题，并以交易业务进行举例。但是FSM的应用场景远多于交易。比如客服工单，商品状态等。但不是所有的流程都需要使用FSM，需要做好业务流程的折中，就像中台战略更适用于10-100 阶段的公司一样。
同时FSM只是一个框架，还需要搭建一整套基于它的外围业务逻辑。在状态流转过程中，业务逻辑才是我们的肌肉。框架就像骨骼约束着我们，从而让技术成长更加健康，这也许就是中台的魅力。
