Spring Statemachine

前言 有限状态机（英语：finite-state machine，缩写：FSM），简称状态机，是表示有限个状态以及在这些状态之间的转移 和动作等行为的数学模型。应用FSM模型可以帮助对象生命周期的状态的顺序以及导致状态变化的事件进行管理。将状态和 事件控制从不同的业务方法的分支中抽离出来。FSM的应用范围很广，对于有复杂状态流，扩展性要求比较高的场景都可以 使用该模型。后续围绕一个简单订单流程进行展开深入解剖状态机引擎在生产开发中使用。 技术选型 关于状态机引擎的选型，其实目前市面上有不少框架，github上按照statemachine关键字搜索可以出来好多结果。 考虑到资料完备情况、与项目的集成容易程度、框架是否尚在维护等条件，这里选择spring statemachine 看spring的产品，首先看其quickstart项目，然后根据reference做字典式学习， 官网： http://projects.spring.io/spring-statemachine 对应的reference： https://docs.spring.io/spring-statemachine/docs/2.2.0.RELEASE/reference 以及对应的源码&samples： https://github.com/spring-projects/spring-statemachine

3 月，跳不动了？>>> 状态模式在生活场景中也是比较常见的。比如我们平时网购的订单状态变化，还有平时坐电梯，电梯状态的变化。 在软件开发过程中，对于某一项的操作，可能存在不同的情况。通常处理多情况问题最直接的办法就是使用if...else或者switch...case条件语句进行判断。这种做法对于复杂状态的判断天然存在弊端：判断条件语句过于臃肿，可读性较差，不具备扩展性，维度难度也很大。如果转换一下思维，将这些不同状态独立起来用各种不同的类进行表示，系统处理哪种情况，直接使用相应的状态类进行处理，消除条件判断语句，代码也更加具有层次感，且具备良好的扩展能力。 状态模式（State Pattern）也成为状态机模式（State Machine Pattern），是允许对象在内部状态发生改变时改变它的行为，对象看起来好像修改了它的类。状态模式中类的行为是由状态决定的，不同的状态下有不同的行为。其意图是让一个对象在其内部改变的时候，其行为也随之改变。状态模式的核心就是状态与行为绑定，不同的状态对应不同的行为。 一、状态模式的应用场景 状态模式适用于以下几种场景： 行为随状态改变而改变场景； 一个操作中含有庞大的多分支机构，并且这些分支取决于对象的状态。 状态模式主要包含三种角色： 环境类角色（Context）：定义客户端需要的接囗，内部维护一个当前状态实例，并负责具体状态的切换；

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 目前为止，我们都是从状态流程的开始阶段创建一个状态机，然后一路走下去。但在实际业务中，状态机可能需要在某个环节停留，等待其他业务的触发，然后再继续下面的流程。比如订单，可能在支付环节需要等待一个剁手的用户隔天再下单，所以这里面涉及到一个创建的状态机该何去何从的问题。在spring statemachine中，给出来的办法就是保存起来，到需要的时候取出来用。 1、持久化到本地内存 严格来说，你完全可以自己保存状态机，比如我就自己用map保存下来了。 public class MachineMap { public static Map<String,StateMachine<OrderStates, OrderEvents>> orderMap = new HashMap<String,StateMachine<OrderStates, OrderEvents>>(); public static Map<String,StateMachine<FormStates, FormEvents>> formMap = new HashMap<String,StateMachine<FormStates, FormEvents>>(); } 这个代码一看就明白，我用唯一id作为key（order就是orderId

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 1、伪持久化和中间段的状态机 我们设想一个业务场景，就比如订单吧，我们一般的设计都会把订单状态存到订单表里面，其他的业务信息也都有表保存，而状态机的主要作用其实是规范整个订单业务流程的状态和事件，所以状态机要不要保存真的不重要，我们只需要从订单表里面把状态取出来，知道当前是什么状态，然后伴随着业务继续流浪到下一个状态节点就好了（流浪远方，流~浪~~）。 我们先实现一个StateMachinePersist，因为我不想真的持久化，所以就敷衍一下，持久化是什么，啥也不干。 import org.springframework.statemachine.StateMachineContext; import org.springframework.statemachine.StateMachinePersist; import org.springframework.statemachine.support.DefaultStateMachineContext; import org.springframework.stereotype.Component; @Component public class OrderStateMachinePersist implements StateMachinePersist

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 1、讲讲复杂流程的需求 除了上面文章里面提到的一根筋状态机流程，实际的企业应用中状态机的流程会更加复杂，而我们最常用到的就是choice。它类似于java的if语句，作为条件判断的分支而存在，让我们先看一张图： 这张图表现的是一个表单（form）的整个状态流程： 创建初始的空白表单（ BLANK_FORM） 填写(WRITE)表单，成为填充完表单（FULL_FORM） 检查(CHEKC)表单 如果是表单名（formName）不为null，表单成为待提交表单（CONFIRM_FROM） 提交（SUBMIT）表单，成为成功提交表单（SUCCESS_FORM） 检查（CHECK）表单 如果表单名为null，表单成为待处理表单（DEAL_FORM）,修改formName 处理(DEAL)表单 如果表单名还是null或者里面有个“坏”字，表单状态变成废单（FAILED_FORM） 如果表单名称没问题，表单状态变成填充完表单状态（FULL_FORM）,重新走流程 大家不要在意这个例子的幼稚，毕竟它还是能用简单的方式体现出流程的复杂性（这话多么的辩证统一）。它有判断分支（还有两个），还有流程的循环，还有分支判断后的直接失败和分支判断后的后续环节，后面我们会在代码中告诉大家这里面需要注意的东西。 2、代码实现

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 参考文档链接 Using Actions (使用操作) 从用户角度来看，操作是最有用的组件之一，可以与状态机进行交互和协作。动作可以在状态机的不同位置及其状态生命周期中执行，例如进入或退出状态或转换期间。 @Override public void configure(StateMachineStateConfigurer<States, Events> states) throws Exception { states .withStates() .initial(States.SI) .state(States.S1, action1(), action2()) .state(States.S2, action1(), action2()) .state(States.S3, action1(), action3()); } 上面 action1 和 action2 beans分别附加到状态的入口和出口。 @Bean public Action<States, Events> action1() { return new Action<States, Events>() { @Override public void execute(StateContext<States, Events> context)

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 官网： https://projects.spring.io/spring-statemachine/ 官网这里列出了很多特性，说的就是易于使用的状态机，帮助开发者简化状态机的开发过程，让状态机结构更加层次化。 状态机 有限状态机(FSM），简称状态机，是表示有限个状态以及在这些状态之间的转移和动作等行为的数学模型。 状态存储关于过去的信息，就是说：它反映从系统开始到现在时刻的输入变化。转移指示状态变更，并且用必须满足来确使转移发生的条件来描述它。动作是在给定时刻要进行的活动的描述。 写一个demo 在pom.xml中加入依赖： 定义订单状态 订单事件： 然后写一个配置类： @EnableStateMachine 注解用来启用Spring StateMachine状态机功能 configure(StateMachineStateConfigurer<States, Events> states) 方法用来初始化当前状态机拥有哪些状态 configure(StateMachineTransitionConfigurer<States, Events> transitions) 方法用来初始化当前状态机有哪些状态迁移动作，其中命名中我们很容易理解每一个迁移动作，都有来源状态 source ，目标状态 target

本文首发于个人网站： Spring Boot 2.x实战之StateMachine Spring StateMachine是一个状态机框架，在Spring框架项目中，开发者可以通过简单的配置就能获得一个业务状态机，而不需要自己去管理状态机的定义、初始化等过程。今天这篇文章，我们通过一个案例学习下Spring StateMachine框架的用法。 案例介绍 假设在一个业务系统中，有这样一个对象，它有三个状态：草稿、待发布、发布完成，针对这三个状态的业务动作也比较简单，分别是：上线、发布、回滚。该业务状态机如下图所示。 实战 接下来，基于上面的业务状态机进行Spring StateMachine的演示。 创建一个基础的Spring Boot工程，在主pom文件中加入Spring StateMachine的依赖： <?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0

本文首发于个人网站： Spring Boot 2.x实战之StateMachine Spring StateMachine是一个状态机框架，在Spring框架项目中，开发者可以通过简单的配置就能获得一个业务状态机，而不需要自己去管理状态机的定义、初始化等过程。今天这篇文章，我们通过一个案例学习下Spring StateMachine框架的用法。 案例介绍 假设在一个业务系统中，有这样一个对象，它有三个状态：草稿、待发布、发布完成，针对这三个状态的业务动作也比较简单，分别是：上线、发布、回滚。该业务状态机如下图所示。 实战 接下来，基于上面的业务状态机进行Spring StateMachine的演示。 创建一个基础的Spring Boot工程，在主pom文件中加入Spring StateMachine的依赖： <?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0