在设计交易系统时，稳定性、可扩展性、可维护性都是我们需要关注的重点。本文将对如何通过状态机在交易系统中的应用解决上述问题做出一些探讨。

关于马蜂窝机票订单交易系统

交易系统往往存在订单维度多、状态多、交易链路长、流程复杂等特点。以马蜂窝大交通业务中的机票交易为例，用户提交的一个订单除了机票信息之外可能还包含很多信息，比如保险或者其他附加产品。其中保险又分为很多类型，如航意险、航延险、组合险等。

从用户的维度看，一个订单是由购买的主产品机票和附加产品共同构成，支付的时候是作为一个整体去支付，而如果想要退票、退保也是可以部分操作的;从供应商的维度看，一个订单中的每个产品背后都有独立的供应商，机票有机票的供应商，保险有保险的供应商，每个供应商的订单都需要分开出票、独立结算。

用户的购买支付流程、供应商的出票出保流程，构成一个有机的整体穿插在机票交易系统中，密不可分。

状态机在机票交易系统中的

应用与优化

有限状态机的概念

有限状态机(以下简称状态机)是一种用于对事物或者对象行为进行建模的工具。

状态机将复杂的逻辑简化为有限个稳定状态，构建在这些状态之间的转移和动作等行为的数学模型，在稳定状态中判断事件。

对状态机输入一个事件，状态机会根据当前状态和触发的事件唯一确定一个状态迁移。

图1：FSM工作原理

业务系统的本质就是描述真实的世界，因此几乎所有的业务系统中都会有状态机的影子。订单交易流程更是天然适合状态机模型的应用。

以用户支付流程为例，如果不使用状态机，在接收到支付成功回调时则需要执行一系列动作：查询支付流水号、记录支付时间、修改主订单状态为已支付、通知供应商去出票、记录通知出票时间、修改机票子订单状态为出票中…… 逻辑非常繁琐，而且代码耦合严重。

为了使交易系统的订单状态按照设计流程正确向下流转，比如当前用户已支付，不允许再支付;当前订单已经关单，不能再通知出票等等，我们通过应用状态机的方式来优化机票交易系统，将所有的状态、事件、动作都抽离出来，对复杂的状态迁移逻辑进行统一管理，来取代冗长的 if else 判断，使机票交易系统中的复杂问题得以解耦，变得直观、方便操作，使系统更加易于维护和管理。

状态机设计

在数据库设计层面，我们将整个订单整体作为一个主订单，把供应商的订单作为子订单。假设一个用户同时购买了机票和保险，因为机票、保险对应的是不同的供应商，也就是 1 个主订单 order 对应 2 个子订单 sub_order。其中主订单 order 记录用户的信息(UID、联系方式、订单总价格等)，子订单 sub_order 记录产品类型、供应商订单号、结算价格等。

同时，我们把正向出票、逆向退票改签分开，抽成不同的子系统。这样每个子系统都是完全独立的，有利于系统的维护和拓展。

对于机票正向子系统而言，有两套状态机：主订单状态机负责管理 order 的状态，包括创单成功、支付成功、交易成功、订单关闭等;子订单状态机负责管理 sub_order 的状态，维护预订成功到出票的流程。同样，对于逆向退票和改签子系统，也会有各自的状态机。

图2：机票主订单状态机状态转移示例

框架选型

目前业界常用的状态机引擎框架主要有 Spring Statemachine、Stateless4j、Squirrel-Foundation 等。经过结合实际业务进行横向对比后，最终我们决定使用 Squirrel-Foundation，主要是因为：

代码量适中，扩展和维护相对而言比较容易;

StateMachine 轻量，实例创建开销小;

切入点丰富，支持状态进入、状态完成、异常等节点的监听，使转换过程留有足够的切入点;

支持使用注解定义状态转移，使用方便;

从设计上不支持单例复用，只能随用随 New，因此状态机的本身的生命流管理很清晰，不会因为状态机单例复用的问题造成麻烦。

MSM 的设计与实现

结合大交通业务逻辑，我们在 Squirrel-Foundation 的基础之上进行了 Action 概念的抽取和二次封装，将状态迁移、异步消息糅合到一起，封装成为 MSM 框架 (MFW State Machine)，用来实现业务订单状态定义、事件定义和状态机定义，并用注解的形式来描述状态迁移。

我们认为一次状态迁移必然会伴随着异步消息，因此把一个流程中必须要成功的数据库操作放到一个事务中，把允许失败重试并且对实时度要求不高的操作放到异步消息消费的流程中。

以机票订单支付成功为例，机票订单支付成功时，会涉及修改订单状态为已支付、更新支付流水号等，这些是在一个事务中;而通知供应商出票，则是放在异步消息消费中处理。异步消息的实现使用的是 RocketMQ，主要考虑到 RocketMQ 支持二阶段提交，消息可靠性有保证，支持重试，支持多个 Consumer 组。

以下具体说明：

1. 对每个状态迁移需要执行的动作，都会抽取出一个Action 类，并且继承 AbstractAction，支持多个不同的状态迁移执行相同的动作。这里主要取决于 public List matchConditions() 的实现，因此只需要 matchConditions 返回多个初始状态-事件的匹配条件键值对就可以了。每个 Action 都有一个对应的继承 MFWContext 类的上下文类，用于在 process saveDB 等方法中的通信。

2. 注册所有的 Action，添加每个状态迁移执行完成或者执行失败的监听。

3. 由于依赖 RocketMQ 异步消息，所以需要一个 Spring Bean 去继承 BaseMessageSender，这个类会生成异步消息提供者。如果要使用二阶段提交，则需要一个类继承 BaseMsgTransactionListener，这里可以参考机票的 OrderChangeMessageSender 和 OrderChangeMsgTransactionListener。

4. 最后，实现一个事件触发器类。在这个类里面包含一个 Apply 方法，传入订单 PO 对象、事件、对应的上下文，每次执行都实例化出一个状态机实例，并初始化当前状态，并调用 Fire 方法。

5. 实例化一个状态机对象，设置当前状态为数据库对应的状态，调用 Fire 方法之后，最终会执行到 OrderStateMachine 类里面用注解描述的 callMethod 方法。我们配置的是 callMethod = "action"，它就会反射执行当前类的 Action 方法。

Action 方法我们的实现是通过 super.action(from, to, event, context)，就会执行 MFWStateMachine 的 Action 方法，先去根据当前状态和事件获取对应的Action，这里使用到了「工厂模式」，然后执行 Process 方法。如果成功，会执行在 MFWStateMachine 类初始化的 TransitionCompleteListener，执行该 Action的 afterProcess 方法来修改数据库记录以及发送消息;如果失败，会执行TransitionExceptionListener，执行该 Action 的onException 方法来进行相应处理。

综上，MSM 可以根据 Action 类的声明和配置，来动态生成出 Squirrel-Foundation 的状态机定义，而不需要由使用方再去定义一次，使 MSM 的使用更方便。

图3: UML

趟过的坑

1. 事务不生效

最初我们使用 Spring 注解方式进行事务管理，即在 Action 类的数据库操作方法上加 @Transactional 注解，却发现在实践中不起作用。经过排查后发现， Spring 的事务注解是靠 AOP 切面实现的。在对象内部的方法中调用该对象其他使用 AOP 注解的方法，被调用方法的 AOP 注解会失效。因为同一个类的内部代码调用中，不会走代理类。后来我们通过手动开启事务的方式来解决此问题。

2. 匹配 Action

最初我们匹配 Action 有两种方式：精准匹配及非精准匹配。精准匹配是指只有当某个状态迁移的初始状态和触发的事件一致时，才能匹配到 Action;非精准匹配是指只要触发的事件一致，就可以匹配到 Action。后来我们发现非精准匹配在某些情形下会出现问题，于是统一改成了多条件精准匹配。即在执行状态机触发时执行的 Action 方法时，去精准匹配 Action，多个状态迁移执行的方法可以匹配到同一个 Action，这样能够复用 Action 代码而不会出问题。

3. 异步消息一致性

有一些情况是绝不能出现的，比如修改数据库没成功即发出了消息;或是修改数据库成功了，而发送消息失败;或是在提交数据库事务之前，消息已经发送成功了。解决这个问题我们用到了 RocketMQ 的事务消息功能，它支持二阶段提交，会先发送一条预处理消息，然后回调执行本地事务，最终提交或者回滚，帮助保证修改数据库的信息和发送异步消息的一致。

4. 同一条订单数据并发执行不同事件

在某些情况下，同一条订单数据可能会在同一时间(毫秒级)同时触发不同的事件。如机票主订单在待支付状态下，可以接收支付中心的回调，触发支付成功事件;也可以由用户点击取消订单，或者超时未支付定时任务来触发关单事件。如果不做任何控制的话，一个订单将可能出现既支付成功又会被取消。

我们用数据库乐观锁来规避这个问题：在执行修改数据库的事务时，update 订单的语句带有原状态的条件判断，通过判断更新行数是否为 1，来决定是否抛出异常，即生成这样的 SQL 语句：update order where order_id = ‘1234' and order_status = ‘待支付'。

这样的话，如果两个事件同时触发同时执行，谁先把事务提交成功，谁就能执行成功;事务提交较晚的事件会因为更新行数为 0 而执行失败，最终回滚事务，就仿佛无事发生过一样。

使用悲观锁也可以解决这个问题，这种方式是谁先争抢到锁谁就可以成功执行。但考虑到可能会有脚本对数据库批量修改，悲观锁存在死锁的潜在问题，我们最终还是采用了乐观锁的方式。

总结

MSM 状态机的定义和声明在 Squirrel-Foundation 的基础之上，抽取出 Action 概念，并对 Action 类配置起始状态、目标状态、触发的事件、上下文定义等，使 MSM 可以根据 Action 类的声明和配置，来动态生成出 Squirrel-Foundation 的状态机定义，而不需要使用方再去定义一次，操作更简单，维护起来也更容易。

通过使用状态机，机票订单交易系统的流程复杂性问题迎刃而解，系统在稳定性、可扩展性、可维护性等方面也得到了显著的改善和提升。

状态机的使用场景不仅仅局限于订单交易系统，其他一些涉及到状态变更的复杂流程的系统也同样适用。希望通过本文的介绍，能使有状态机了解和使用需求的读者朋友有所收获。

本文作者：董天，马蜂窝大交通研发团队机票交易系统研发工程师。

【本文是51CTO专栏作者马蜂窝技术的原创文章，作者微信公众号马蜂窝技术(ID：mfwtech)】