状态机+Gateway 升级支付代理服务(一)

背景

目前的业务背景是需要与某平台(类似于大众点评网)进行对接,售卖我们的保险产品,而之前由于业务紧急, 开发小伙伴为了赶进度，基本都是业务代码一把梭(懂得都懂)， 因此导致后期的业务扩展和对接都非常的麻烦。 之前逻辑如下:

原有支付架构

目前的架构逻辑,用户在B平台的APP上订餐,定完餐后弹出广告或者推荐链接, 如果用户点击链接则可以跳转到A保险系统的定制化出单页面进行对应保险产品的出单(目前为用餐保险 类似于美团外卖的放心吃)。如果用户选择购买，则A系统需要与B点餐平台的支付网关进行交互，用户在B系统支付完成后, 则与A保险系统交互进行保险出单的后续操作。具体的支付逻辑后面会介绍

此类架构的不足是

• A系统所有C端对外交互都依赖于业务定制化服务，因此会导致该服务越来越臃肿，业务耦合也越来越严重。
• A系统的业务集成系统不仅与第三方支付交互,同时也与核心系统进行交互, 职责不单一，业务耦合严重，不利于扩展。如果新对接第三方系统或者第三方系统对应的接口升级，则可能牵扯到多系统的升级修改。
• 后端服务调用使用Feign , 成倍的序列化反序列化操作，消耗资源。

概念以及思路

升级思路

• 新增支付代理服务,使用Gateway中间件做代理(比如 Spring Cloud Gateway,Apache Shenyu)。
• 引入订单的概念并且使用有限状态机来管理和更新订单状态。这里使用的是COLA 框架中的状态机组件,完全解耦第三方支付功能, 针对内部核心系统，只有订单的信息需要维护。不需要在乎对外第三方支付的集成和维护。

有限状态机

有限状态机（Finite State Machine，FSM）是一种抽象的计算机模型，用于描述对象、系统或程序在不同状态之间的转换以响应外部输入或事件。FSM 是一种数学概念，广泛用于计算机科学、工程、自动化、电子和通信领域。下面是有关有限状态机的详细解释：

1. 状态（State）：状态是系统或对象可以处于的特定情况或模式。状态通常用来描述系统的特定配置或条件。例如，一个电梯系统可能有状态，如 "停止"、"上升" 和 "下降"。
2. 状态转换（State Transition）：状态转换描述了系统从一个状态切换到另一个状态的过程。这些状态转换可以由外部事件、输入或条件触发。例如，当用户按下电梯按钮时，电梯从 "停止" 状态切换到 "上升" 或 "下降" 状态。
3. 事件（Event）：事件是导致状态转换的外部触发器。事件可以是用户的输入、传感器数据、时钟信号等。在电梯系统中，事件可以是用户按下楼层按钮。
4. 动作（Action）：动作是与状态转换相关联的操作或行为。当状态机从一个状态切换到另一个状态时，可以执行特定的动作。这些动作可以包括向用户显示信息、控制输出设备、记录数据等。
5. 初始状态（Initial State）：初始状态是状态机的起始状态，在系统启动或重置时进入。从初始状态开始，状态机可以根据事件触发状态转换。
6. 终止状态（Final State）：终止状态是状态机的结束状态，表示状态机已完成其任务。一旦状态机达到终止状态，它将不再进行状态转换。

state machine

有限状态机分为以下两种主要类型：

• 确定性有限状态机（Deterministic Finite State Machine，DFA）：在任何给定时间，DFA 从当前状态只有一个可能的状态转换。每个输入事件都精确地确定下一个状态。
• 非确定性有限状态机（Non-deterministic Finite State Machine，NFA）：NFA 具有多个可能的状态转换，取决于输入事件和当前状态。这使得NFA在某些情况下更灵活，但也更复杂。

状态语义模型:

state machine model

应用领域：

• 编译器和解释器：用于分析和处理程序代码。
• 自动控制系统：用于控制机器、机械和工业自动化。
• 通信协议：用于实现通信协议的协商和状态管理。
• 游戏开发：用于管理游戏对象和角色的行为。
• 电子电路设计：用于描述硬件电路的行为。
• 数据处理和处理工作流程：用于描述数据处理过程的状态。
• 任何需要在不同状态间管理行为的领域。

总之，有限状态机是一种强大的概念，用于建模和控制系统的行为，特别适用于需要在状态之间切换以处理不同事件和条件的应用程序和系统。有限状态机可以帮助工程师和开发人员更好地理解和设计复杂系统的逻辑和行为。

订单状态流转

下图中 图形表示 状态 ， 箭头表示 事件

支付状态流转

payment state

---

退款状态流转

refund state

升级后的架构图

升级后支付架构

• 引入支付代理服务(暂时使用Spring Cloud Gateway 集成) ,将支付逻辑单独解耦出来,使用状态机维护到DB中。
• 前端可以直接与支付代理服务进行交互,减少后端服务之间的调用，降低资源利用率。
• 提高扩展性, 无论对接什么第三方支付(AliPay,WxPay等)， A保险系统中,只需要维护订单信息即可，其他服务不需要在乎使用的是用什么支付，对于其他服务只有订单的支付和退款功能接口。

总结

目前只是暂时给出了升级的方案和思路，之后会更新对应的实践部分，包括状态机的使用，Spring Cloud Gateway的简单集成demo.