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

点击上方“马蜂窝技术”，关注订阅更多优质内容

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

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

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

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

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

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

应用与优化

 有限状态机的概念

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

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

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

图1：FSM工作原理

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

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

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

 状态机设计

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