Spring StateMachine是一个状态机框架，在Spring框架项目中，开发者可以通过简单的配置就能获得一个业务状态机，而不需要自己去管理状态机的定义、初始化等过程。今天这篇文章，我们通过一个案例学习下Spring StateMachine框架的用法。
本文将以电商项目中的订单状态转换这个典型的场景。从订单的创建到支付、发货、完成等状态来使用状态机进行管理。如果使用传统的if-else或者switch语句来管理这些状态，代码会变得非常臃肿且难以维护。而状态机提供了一种更加结构化和可维护的方式来管理这些状态转换。
Spring StateMachine框架可能对于大部分使用Spring的开发者来说还比较生僻，该框架目前差不多也才刚满一岁多。它的主要功能是帮助开发者简化状态机的开发过程，让状态机结构更加层次化。前几天刚刚发布了它的第三个Release版本1.2.0，其中增加了对Spring Boot的自动化配置，既然一直在写Spring Boot的教程，所以干脆就将该内容也纳入进来吧，希望对有需求的小伙伴有一定的帮助。 快速入门 依照之前的风格，我们通过一个简单的示例来对Spring StateMachine有一个初步
状态机之所以强大，是因为其行为在启动时就以固定的方式定义了操作规则，从而确保了一贯的连贯性和相对较高的可调试性。关键在于，应用程序处于且仅可能处于有限数量的状态中。然后，某些事件发生会使得应用从一个状态过渡到另一个状态。状态机由触发器驱动，这些触发器基于事件或计时器。
在开发中总会遇到这样的场景，比如工单状态，流程状态，通过状态判断该执行的操作，不断改动的需求导致永无止境的 IF、ELSE 和 BREAK 子句的层次结构，当事情开始看起来太复杂时，简直就像面满池子的海洋球。
状态模式的特点是，对于有状态的对象，我们可以把复杂的“判断逻辑”提取到不同的状态对象中，允许内置的状态对象改变时影响它的行为。状态模式可以有效的减少if else 的分支结构；它将状态和行为绑定到一起，根据不同的状态来确定其行为。这样做的好处是将不同的状态引入独立的对象中会使得状态转换变得更加明确，且减少对象间的相互依赖。但是状态模式的结构与实现都较为复杂，如果使用不当会导致程序结构和代码的混乱。
状态机是“有限状态自动机”的简称，是一种描述和处理事物状态变化的数学模型。本质上来讲，就是一种比if...else结构更加优雅，并具备可扩展性的状态转移处理机制。有多种实现方案，如：枚举，Spring Statemachine，cola state machine。
由此可见，对于复杂状态的管理是一个业务依赖，需求多变的场景。在公司初创期，可以采用硬编码方式，对于每一个操作进行状态判断，每一步操作定制一套逻辑链路。随着业务的增加，定制化链路显然不优雅，大量流程代码无法维护，此时中台通用解决思路就尤为重要，有限状态机（Finite State Machine，缩写：FSM）开始在中台落地。
在平常的后端项目开发中，状态机模式的使用其实没有大家想象中那么常见，笔者之前由于不在电商领域工作，很少在业务代码中用状态机来管理各种状态，一般都是手动get/set状态值。去年笔者进入了电商领域从事后端开发。电商领域，状态又多又复杂，如果仍然在业务代码中东一块西一块维护状态值，很容易陷入出了问题难于Debug，难于追责的窘境。
有限状态机简称就是状态机，因为一般的状态机的状态都是离散和可举的，即为有限，所以后面的介绍都不加有限二字。状态机表示有限个状态以及在这些状态之间的转移和动作等行为的数学模型。通俗的描述状态机就是定义了一套状态変更的流程：状态机包含一个状态集合，定义当状态机处于某一个状态的时候它所能接收的事件以及可执行的行为，执行完成后，状态机所处的状态。所以状态机会包含以下几个重要的元素：
先来解释什么是“状态”（ State ）。现实事物是有不同状态的，例如一个自动门，就有 open 和 closed 两种状态。我们通常所说的状态机是有限状态机，也就是被描述的事物的状态的数量是有限个，例如自动门的状态就是两个 open 和 closed 。
大中台战略下，中台将公司业务的公共能力下沉，并采用更加合理、可复用的架构和技术来实现这些基础能力。在电商行业内，将面临货物的采购、商品上架、交易发生、订单状态变化、客服介入等大量状态维护。每个状态之间具有很强的逻辑关联关系，比如：退款操作在发货前和发货后将是完全不同的流程,如图1订单退款流程。
营销自动化平台支持多种不同类型运营活动策略（比如：短信推送策略、微信图文推送策略、App Push推送策略），每种活动类型都有各自不同的执行流程和活动状态。比如短信活动的活动执行流程如下：
每次用到的时候新创建一个状态机，太奢侈了，官方文档里面也提到过这点。而且创建出来的实例，其状态也跟当前订单的不符；spring statemachine暂时不支持每次创建时指定当前状态，所以对状态机引擎实例的持久化，就成了必须要考虑的问题。
if...else 是所有高级编程语言都有的必备功能。但现实中的代码往往存在着过多的 if...else。虽然 if...else 是必须的，但滥用 if...else 会对代码的可读性、可维护性造成很大伤害，进而危害到整个软件系统。现在软件开发领域出现了很多新技术、新概念，但 if...else 这种基本的程序形式并没有发生太大变化。使用好 if...else 不仅对于现在，而且对于将来，都是十分有意义的。今天我们就来看看如何“干掉”代码中的 if...else，还代码以清爽。
状态模式即允许一个对象在其内部状态改变时改变它的行为。对象看起来似乎修改了它的类，换句话说状态模式把所研究的对象的行为包装在不同的状态对象里，每一个状态对象都属于一个抽象状态类的一个子类。
当我们在社区阅读文章时，如果觉得文章写得很好，我们就会评论、收藏两连发。如果处于登录情况下，则可以直接做评论、收藏这些行为。否则，跳转到登录界面，登录后再继续执行先前的动作。这里涉及的状态有两种：登录与未登录；行为有两种：评论和收藏。下面使用状态模式来实现这个逻辑，代码如下。首先创建抽象状态角色UserState类。
当我们在社区阅读文章时，如果觉得文章写得很好，我们就会评论、收藏两连发。如果处于登录情况下，则可以直接做评论、收藏这些行为。否则，跳转到登录界面，登录后再继续执行先前的动作。这里涉及的状态有两种：登录与未登录；行为有两种：评论和收藏。下面使用状态模式来实现这个逻辑，代码如下。
今天想跟大家分享一个关于“状态机”的话题。状态属性在我们的现实生活中无处不在。比如电商场景会有一系列的订单状态(待支付、待发货、已发货、超时、关闭）；员工提交请假申请会有申请状态（已申请、审核中、审核成功、审核拒绝、结束）；差旅报销单会有单据审核状态（已提交、审核中、审核成功、退回、打款中、打款成功、打款失败、结束）等等。
在电商领域，很多业务对象都是有状态的，且这些对象的状态又多又复杂。硬编码的方式已经不适合管理当前复杂业务对象的状态。为了适配复杂多变的业务，可以使用状态机来管理状态，统一定义业务对象状态和状态的流转。接下来，本文会重点介绍状态机相关的概念和使用场景。
“状态” 算是 人们对事物一个很基本的抽象理解了，在现实世界里，“状态” 无时无刻不体现在我们的生活和工作之中；现实中客观存在的事物，我们总可以给它定义出几个状态来。 而在软件领域，也很早就形成了基于状态的行为模型范式，即 有限状态机(Finite-State Machine)。 本文将 结合状态机的实现框架Spring State Machine (aka. SSM, 下面的内容将直接使用此简称)，介绍下状态机的基本原理,以及在实践中遇到的一些坑。
在实际的项目开发中，开发者经常会遇见类似多级审核之类的开发需求，比如某个文件审核，需要经过申请->直系领导审核->总经理审核等多个步骤。如果是一次动作触发整个审核过程，开发者可能会想到使用责任链模式来进行开发。但如果多级审核的间隔时间长，审核触发的条件不一样，责任链模式会不太能够解耦这项需求。如果采用平铺直叙式开发，无疑会将审核状态转移过程散落在系统间各个位置，前后两个状态之间的关系没有直观进行维护，同时状态转移时的条件、执行的方式和状态之间的逻辑关系很容易让开发者写出“面条代码”。在项目开发初期可能还好，随着需求的增量变化，平铺直叙式开发将使得状态转移逻辑和业务逻辑高度混合，且每增加一级节点审核，就要新增对应的审核状态及状态转移的逻辑，长此以往变得难以阅读和维护。所以，在这种情况下使用状态机这样建模方式就显得尤为必要。
点击上方“芋道源码”，选择“设为星标” 管她前浪，还是后浪？ 能浪的浪，才是好浪！ 每天 10:33 更新文章，每天掉亿点点头发... 源码精品专栏 原创 | Java 2021 超神之路，很肝~ 中文详细注释的开源项目 RPC 框架 Dubbo 源码解析 网络应用框架 Netty 源码解析 消息中间件 RocketMQ 源码解析 数据库中间件 Sharding-JDBC 和 MyCAT 源码解析 作业调度中间件 Elastic-Job 源码解析 分布式事务中间件 TCC-Transaction
cola-statemachine是阿里开源项目COLA (opens new window)中的轻量级状态机组件。最大的特点是无状态、采用纯Java实现，用Fluent Interface(连贯接口)定义状态和事件，可用于管理状态转换场景。比如：订单状态、支付状态等简单有限状态场景。在实际使用的过程中我曾发现状态机内事务不生效的问题，经过排查得到解决，以此记录一下。
Seata 意为：Simple Extensible Autonomous Transaction Architecture，是一套一站式分布式事务解决方案，提供了 AT、TCC、Saga 和 XA 事务模式，本文详解其中的 Saga 模式。
继续分享spring-state-machine状态机的拦截器使用，这里需要留意一个细节：
有限自动状态机 (Finite-state machine , FSM) 通常用来描述某个具有有限个状态的对象，并且在对象的生命周期中组成了一个状态序列，通过响应外界各种事件完成状态流转。
状态模式大家可能初听会很陌生，这种模式有什么用？我就是个CRUD BOY，面对不同的状态，我一个状态一个状态的判断，if else、if else...... 不断的来写不同的逻辑它不香吗？
在编程领域里，枚举是用来表示只包含有限数量的固定值的类型，在开发中一般用于标识错误码或者状态机。拿一个实体对象的状态机来说，它通常与这个对象在数据库里对应记录的标识状态的字段值相对应。
先强调一点. 业务系统, 要学习 ,反对用模板,用流程引擎实现业务. 除非有人参与,必须用流程引擎,不然不要用状态机or流程引擎, 不要用. 但是要学习流程引擎,只是让自己有流程意识,但不用用来实现业务. 业务系统维护同学换来换去,刚记牢每个handler之间的关系,就换系统了. java 强类型之所以变成企业首选, 就是因为强类型 , 可以顺着代码阅读,理解流程. 代码面前了无秘密. 不仅仅码农在用流程引擎,企业战略和执行也是利用流程引擎的.
看到上面的这个状态转换图，一般来说我们还想不到用状态机模式去解决，因为太简单了，简单得可能几行代码就处理了。
在《vivo 营销自动化技术解密 |开篇》中，我们从整体上介绍了vivo营销自动化平台的业务架构、核心业务模块功能、系统架构和几大核心技术设计。
做Java开发的人一提起Spring，首先在脑海中浮现出的就是“IoC”，“AOP”，“Spring MVC”，“Spring Security”等等这些名词，甚至大有“无Spring不Java”的感慨。 实际上，时至今日Spring已不再是一个简单的编程框架了，从最初的“SSH框架”发展到今天，Struts和Hibernate都几乎快要从程序员视野中消失了，而Spring却发展成了一个非常庞大且完整的生态。 所以说，除非特别指明是Spring生态中的某个具体框架，否则提起“Spring”应该指的是整个Spring生态。 说句不夸张的话，Java程序员只要精通了Spring，也就掌握了Java开发的精髓。
简介： 订单状态流转是交易系统的最为核心的工作，订单系统往往都会存在状态多、链路长、逻辑复杂的特点，还存在多场景、多类型、多业务维度等业务特性。在保证订单状态流转稳定性的前提下、可扩展性和可维护性是我们需要重点关注和解决的问题。
这是因为在action触发后，state才会进行更改，而不是在state触发后。。。
https://spring.io/projects/spring-statemachine
OSIP的核心是系统状态机，在不同情况下，系统处于不同的状态，在某一状态下当系统发生某一个动作后（如接受或者发送了消息），状态机做相应的跳转。的状态机在不同的状态下，对某一动作的响应也是不一样的。
在前面的一篇文章《从零开始的状态机漫谈（1）——万物之始的语言》中，我们介绍了状态机在整个计算机科学中宛如“世界基石”般的地位，同时介绍了一种“面向嵌入式环境”“高度简化”了的实用型状态图绘制方法——这里的“简化”是相对UML状态图的“繁杂”而言、且更接近课本上所使用的状态机图例；而这里的“实用”体现在：基于这套方法绘制的状态图是可以“无脑”而“严格”的翻译成C语言代码的。
有限状态机，英文翻译是 Finite State Machine，缩写为 FSM，简称为状态机。状态机有 3 个组成部分：状态（State）、事件（Event）、动作（Action）。其中，事件也称为转移条件（Transition Condition）。事件触发状态的转移及动作的执行。动作也不是必须的，也可能只转移状态，不执行任何动作。
Openssl是通过“握手“建立加密信道，在该信道双方的身份都是合法的，并且传输数据都是密文传输。Openssl握手通过客户端和服务端互相交换信息计算出secret。计算出密钥的方式有很多种。这中间可能需要几个RTT来回。状态机需要针对约定好的加密算法按照一定的步骤执行。所以需要状态机保存握手过程中的参数。
今天给大侠带来如何写好状态机（三），由于篇幅比较长，如何写好状态机分成三篇呈现。前两篇已经说了状态机的基本概念以及如何写好状态机，此篇带来使用 Synplify Pro 分析 FSM。，话不多说，上货。
在前面的讲解中，我们介绍了如何使用状态图的方式来设计有限状态机、明确了状态图设计的“清晰”原则，并结合最简单和常用的switch状态机翻译模式详细说明了状态图的“无脑翻译”方法。
本篇主要讲清楚什么是状态机，简洁的状态机对支付系统的重要性，状态机设计常见误区，以及如何设计出简洁而精妙的状态机，核心的状态机代码实现等。
今天给大侠带来如何写好状态机，状态机是逻辑设计的重要内容，状态机的设计水平直接反应工程师的逻辑功底，所以很多公司在硬件工程师及逻辑工程师面试中，状态机设计几乎是必选题目。本篇在引入状态机设计思想的基础上，重点讨论如何写好状态机。由于篇幅比较长，如何写好状态机分成三篇呈现。话不多说，上货。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
即时通信 IM
ICP备案
对象存储
实时音视频
