状态机在马蜂窝机票订单交易系统中的应用与优化实践

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

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

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

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

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

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

应用与优化

有限状态机的概念

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

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

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

图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 的设计与实现