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

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

关于状态机引擎的选型，其实目前市面上有不少框架，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-区域，表示有一系列状态，这些状态有相同的父状态。

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