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

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

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

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

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

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

状态机在机票交易系统中的应用与优化

有限状态机的概念

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

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

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

图1：FSM工做原理

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

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

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

状态机设计

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

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

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

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

框架选型

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

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

2. StateMachine 轻量，实例建立开销小；

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

4. 支持使用注解定义状态转移，使用方便；

5. 从设计上不支持单例复用，只能随用随 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 的状态机定义，而不须要使用方再去定义一次，操做更简单，维护起来也更容易。

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

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

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

（马蜂窝技术原创内容，转载务必注明出处保存文末二维码图片，谢谢配合。）

关注马蜂窝技术，找到更多你想要的内容