Spring StateMachine 状态机引擎在项目中的应用--之一

4,583 阅读5分钟

接了个大活,要把公司内部好几条业务线的订单系统统一抽取出来,做成一个订单平台,支撑目前多条业务线的订单体系,同时也要求可以灵活扩展,快速支持之后的新业务。

谈到订单,基本上是大部分公司业务系统中没办法绕过的一环,而订单最关键的是什么?个人认为是其生命周期,其中订单的状态变更 更是需要仔细设计、考虑的点。如果对于单一稳定的业务,不太建议使用状态机来实现,引入了不少复杂度。但是如果业务经常变化,业务模式又多种多样,那么前期引入状态机引擎就太值得了,好的设计可以避免后期很多工作量产生。

关于状态机引擎的选型,其实目前市面上有不少框架,github上按照statemachine关键字搜索可以出来好多结果。考虑到资料完备情况、与项目的集成容易程度、框架是否尚在维护等条件,这里选择spring statemachine。其实在segmengfault中有一篇文章在推荐squirrel,只是目前spring statemachine已经又进一步完善,足以满足我的需要,而且在引擎实例持久化方面更是提供了比较完备的解决方案,所以还是继续选择spring家族的产品。这篇比较的文章参见:https://segmentfault.com/a/1190000009906317

看spring的产品,首先看其quickstart项目,然后根据reference做字典式学习,

  • 官网:http://projects.spring.io/spring-statemachine
  • 对应的reference:https://docs.spring.io/spring-statemachine/docs/1.2.8.RELEASE/reference/htmlsingle
  • 以及对应的源码 & samples:https://github.com/spring-projects/spring-statemachine

另外,目前网上基本上所有的spring statemachine教程都是脱胎于官网的简单教程及@翟永超 的一篇博文(http://blog.didispace.com/spring-statemachine/),而且无一例外都是基于spring boot的。对我目前的项目来说确实并不是太适用,所以以下内容是基于普通spring + spring statemachine进行实现的,并未引入spring boot,介意的可以节省点时间,不用继续看下去了,生命苦短,没必要浪费哈!

状态机定义-相关概念

先从状态机的定义入手,StateMachine,其中:

  • StateMachine:状态机模型
  • state:S-状态,一般定义为一个枚举类,如创建、待风控审核、待支付等状态
  • event:E-事件,同样定义成一个枚举类,如订单创建、订单审核、支付等,代表一个动作。
    一个状态机的定义就由这两个主要的元素组成,状态及对对应的事件(动作)。
状态机-相关概念

  • Transition: 节点,是组成状态机引擎的核心
  • source:节点的当前状态
  • target:节点的目标状态
  • event:触发节点从当前状态到目标状态的动作
  • guard:起校验功能,一般用于校验是否可以执行后续action
  • action:用于实现当前节点对应的业务逻辑处理

举个简单的例子:

   builder.configureTransitions()  -- 配置节点
            .withExternal()   //表示source target两种状态不同
            .source(CREATE)  //当前节点状态
            .target(WYD_INITIAL_JUMP)  //目标节点状态,这里是设置了个中间状态
            .event(BizOrderStatusChangeEventEnum.EVT_CREATE)  //导致当前变化的动作/事件
            .action(orderCreateAction, errorHandlerAction) //执行当前状态变更导致的业务逻辑处理,以及出异常时的处理

补充说明:

  • withExternal 是当source和target不同时的写法,如上例子
  • withInternal 当source和target相同时的串联写法,比如付款失败时,付款前及付款后都是待付款状态
  • withChoice 当执行一个动作,可能导致多种结果时,可以选择使用choice+guard来跳转

目前我主要使用的就是这三种,当然如果有更复杂的情况,还有withLocalwithJunction等各种写法,但是:当你对一项技术并不是那么了解时,先尽可能的用简单的实现来处理你的业务,出现问题的可能性最小,后续可以再慢慢扩展。

注意:

  • 上述代码event之后并没有设置guard,代表默认会执行对应action。
  • 这里的orderCreateAction及errorHandlerAction都是使用spring注入进来的业务bean。

稍微复杂的节点配置

接上面的withExternal,下面是使用choice做了一个分支选择,代码如下:

            .and()  // 使用and串联
            .withChoice() // 使用choice来做选择
            .source(WYD_INITIAL_JUMP) // 当前状态
            .first(WAIT_REAL_NAME_AUTH, needNameAuthGurad(), needNameAuthAction)  // 第一个分支
            .last(WAIT_BORROW, waitBorrowAction) // 第二个分支

说明:

  • 多个节点之间使用and()串联
  • 注意,withChoice没有对应的event,所以依赖上一个节点的event,只要source是WYDINITIALJUMP,就会自动执行当前choice transition
  • withChoice没有对应的target,只有几个选择分支
  • first/then/last 类似于 if--else if--else ,then可以不设置,但是last一定要有,否则会报错
  • needNameAuthGurad() 用于判断是否走当前分支,返回true时选择当前分支,返回false走下面分支
  • last中其实是省略了一个guard的实现,默认为true,意味着如果不走first分支,就会走last分支。
  • withChoice其实是个PseudoState,也就是伪状态或瞬时状态,会马上跳转到下面的分支流程中。

如果是复杂一点的流程,比如有子状态,那么就有一个region的概念,region-区域,表示有一系列状态,这些状态有相同的父状态。

好啦,基本上项目中用到的核心概念就先到这里,下一节会讲下状态机引擎的持久化处理。