近期因为公司订单系统大多为定时任务轮寻，执行速度依赖于定时任务执行速度，希望能够改造成实时处理，
所以我决定引入MQ同时使用Spring State Machine，来拆分业务与状态和数据之间的耦合

首先技术选型，为什么要使用spring state machine：

如果业务单一，生命周期闭环较为短，那么不太建议使用状态机，成本比较高
如果业务复杂，且有可能频繁更改，那么在项目初期使用状态机，简直太有必要了，业务与状态解耦，最终由action处理数据

关于状态机的选择，市面上状态机种类繁多，不过考虑到文档齐备，社区状态，最终选择了spring的周边产品spring state machine

核心概念

所谓状态机，其实就是状态管理，最核心的有两个部分，一是状态，二是事件，由事件驱动状态的变更，也就是状态机了

  • state：S-状态，订单状态，例如初始状态，待付款，已发货，待确认等等
  • event：E-事件，下单，付款，物流发货，确认收货等等

一个状态机的定义就由这两个主要的元素组成，状态及对对应的事件（动作）。

状态机配置相关
Transition: 节点，是组成状态机引擎的核心
source：当前状态
target：目标状态
event：触发节点从当前状态到目标状态的动作
guard：校验是否可执行该事件
action：实现该节点变更后对应的逻辑

代码书写

这部分个人有个人的习惯，我通常都是先写状态流程定义的部分。
另外，官网上的例子实在是太简单了，不能满足项目中使用，我个人把流程定义写成了一饿Builder，可以多次构建。

ps： 因为一个状态机只能维护一个状态，所以如果同时处理，只有一个状态机是不够的，同时如果状态机到达最终节点，就完结了，任务处理都会拒接