状态机的技术选型看这篇就够了,最后一个直叫好!!!

状态机,技术,选型,最后,一个,叫好 · 浏览次数 : 3619

小编点评

**性能差状态机** *状态机实现方案比较复杂。* * Java枚举版的状态机主要问题是扩展粒度不够基本都是线性扩展,封装在一个类中,太复杂的状态流转这个类也会变得臃肿不堪,维护性变低。 **cola-component-statemachine** *开源状态机实现比较简单,易读性强。* *内部DSL可以减少代码复杂性。 **其他** *建议可以根据实际需求进行调整。* *可以考虑使用性能测试工具来测试状态机的性能。*

正文

前言

今天跟大家分享一个关于“状态机”的话题。状态属性在我们的现实生活中无处不在。比如电商场景会有一系列的订单状态(待支付、待发货、已发货、超时、关闭);员工提交请假申请会有申请状态(已申请、审核中、审核成功、审核拒绝、结束);差旅报销单会有单据审核状态(已提交、审核中、审核成功、退回、打款中、打款成功、打款失败、结束)等等。上述场景有一个共同问题:根据不同触发条件执行不同处理动作最后落地不同的状态。示例代码如下:

Integer status=0;
    if(condition1){
        status=1;
    }else if(condition2){
        status=2;
    }else if(condition3){
        status=3;
    }else if(condition4){
        status=4;
    }
复制代码

那我们最容易能想到的自然是if-else方案。那if-else方案会有什么问题呢?

主要有以下几点:

  • 复杂的业务流程,if.else代码几乎无法维护
  • 随着业务的发展,业务过程也需要变更及扩展,但if.else代码段已经无法支持
  • 没有可读性,变更风险特别大,可能会牵一发而动全身,线上事故层出不穷
  • 其他业务逻辑可能也会跟if-else代码块耦合在一起,带来更多的问题

状态机的出现就是用来解决上述问题的。在复杂多状态流转情况下,通过状态机的引入,我们希望相关代码可读性、扩展性能比if-else方案更好!

关于状态机

▲什么是状态机

状态机是有限状态自动机的简称。有限状态机(英语:finite-state machine,缩写:FSM)又称有限状态自动机(英语:finite-state automaton,缩写:FSA),简称状态机,是表示有限个状态以及在这些状态之间的转移和动作等行为的数学计算模型。

关于有限的解释:也就是被描述的事物的状态的数量是有限的,例如开关的状态只有“开”和“关”两个;灯的状态只有“亮”和“灭”等等。

▲特点

一个状态机可以具有有限个特定的状态,它通常根据输入,从一个状态转移到另一个状态,不过也可能存在瞬时状态,而一旦任务完成,状态机就会立刻离开瞬时状态。每个状态根据不同的前置条件,会从当前状态流转至下一个状态。

▲作用

使用状态机来表达状态的流转,会使语义会更加清晰,会增强代码的可读性和可维护性。

▲适用场景

面对复杂的状态流转(一般是超过三个及以上的状态流转),那么还是比较建议用状态机来实现的。

各个状态机方案

▲枚举状态机

Java中的枚举是一个定义了一系列常量的特殊类(隐式继承自class java.lang.Enum)。枚举类型因为自身的线程安全性保障和高可读性特性,是简单状态机的首选。

关于线程安全说明
我们随便自定义一个枚举:

public enum OpinionsEnum {
    PASS,NOT_PASS
}
复制代码

试着反编译上述代码:

public final class OpinionsEnum extends java.lang.Enum<OpinionsEnum> {
  public static final OpinionsEnum PASS;
  public static final OpinionsEnum NOT_PASS;
  public static OpinionsEnum[] values();
  public static OpinionsEnum valueOf(java.lang.String);
  static {};
}
复制代码

通过反编译后的代码我们看到:OpinionsEnum它继承了java.lang.Enum类;class前的final标识告诉我们此枚举类不能被继承。

我们接着看它的两个属性:PASS、NOT_PASS。它们无一例外都经过了staic 的修饰,而我们知道staic修饰的属性会在类被加载之后就完成初始化,而这个过程是线程安全的。

示例代码:

public enum State {
    SUBMIT_APPLY {
        @Override
        State transition(String checkcondition) {
            System.out.println("员工提交请假申请单,同步流转到部门经理审批 参数 = " + checkcondition);
            return Department_MANAGER_AUDIT;
        }
    },
    Department_MANAGER_AUDIT {
        @Override
        State transition(String checkcondition) {
            System.out.println("部门经理审批完成,同步跳转到HR进行审批 参数 = " + checkcondition);
            return HR;
        }
    },
    HR {
        @Override
        State transition(String checkcondition) {
            System.out.println("HR完成审批,流转到结束组件, 参数 = " + checkcondition);
            return FINAL;
        }
    },
    FINAL {
        @Override
        State transition(String checkcondition) {
            System.out.println("流程结束, 参数 = " + checkcondition);
            return this;
        }
    };

    abstract State transition(String checkcondition);
}
复制代码
public class StatefulObjectDemo {
    private  State state;

    public StatefulObjectDemo() {
        state = State.SUBMIT_APPLY;
    }

    public void performRequest(String checkCondition) {
        state = state.transition(checkCondition);
    }

    public static void main(String[] args) {
      StatefulObjectDemo theObject = new StatefulObjectDemo();
        theObject.performRequest("arg1");
        theObject.performRequest("arg2");
        theObject.performRequest("arg3");
        theObject.performRequest("arg4");

    }
}
复制代码

输出:

员工提交请假申请单,同步流转到部门经理审批 参数 = arg1
部门经理审批完成,同步跳转到HR进行审批 参数 = arg2
HR完成审批,流转到结束组件, 参数 = arg3
流程结束, 参数 = arg4
复制代码

Java枚举有一个比较有趣的特性即它允许为实例编写方法,从而为每个实例赋予其行为。实现也很简单,定义一个抽象的方法即可,这样每个实例必须强制重写该方法。(见示例的transition方法)

▲状态模式实现的状态机

是什么

状态模式是编程领域特有的名词,是 23 种设计模式之一,属于行为模式的一种。

它允许一个对象在其内部状态改变时改变它的行为。对象看起来似乎修改了它的类。

作用状态模式的设计意图主要是为了解决两个主要问题:

  1. 当一个对象的内部状态改变时,它应该改变它的行为。

  2. 应独立定义特定于状态的行为。也就是说,添加新状态不应影响现有状态的行为。

类图:

类图

定义一个State接口,它可以有N个实现类,每个实现类需重写接口State定义的handle方法。它还有一个Context上下文类,内部持有一个State对象引用,外部状态发生改变(构造器内传入不同实现类),最终实现类自身行为动作也接着改变(实现类调用其自身的handle方法)。

Context示意图参考

用状态模式实现的代码示例:

public interface SwitchState {

    void handle();
}

public class TurnOffAction implements SwitchState{
    @Override
    public void handle() {
        System.out.println("关灯");
    }
}

public class TurnOnAction implements SwitchState{

    @Override
    public void handle() {
        System.out.println("开灯");
    }
}

public class Context {

    private SwitchState state;

    public Context(SwitchState state){
        this.state=state;
    }

    public void doAction(){
        state.handle();
    }
}
复制代码

输出

public class StatePatternDemo {

    @DisplayName("状态模式测试用例-开灯")
    @Test
    public void turnOn() {
        Context context = new Context(new TurnOnAction());
        context.doAction();
    }

输出:开灯

    @DisplayName("状态模式测试用例-关灯")
    @Test
    public void turnOff() {
        Context context = new Context(new TurnOffAction());
        context.doAction();
    }
}

输出:关灯
复制代码

大家看下这段示例代码:Context类有一个有参构造方法,参数类型是State,所以实例化对象的时候你可以传入State的不同的实现类。最终context.doAction()调用的是不同实现类的doAction方法。

▲开源实现

目前开源的状态机实现方案有spring-statemachine、squirrel-foundation、sateless4j等。其中spring-statemachine、squirrel-foundation在github上star和fock数稳居前二。

不过这些状态机普通使用下来普遍存在两个问题:

问题一:太复杂

因为基本囊括了UML State Machine上列举的所有功能,功能是强大了,但也搞得体积过于庞大、臃肿、很重。很多功能实际生产场景中根本用不到。

支持的高阶功能有:状态的嵌套(substate),状态的并行(parallel,fork,join)、子状态机等等。大家可以对照一下这些功能你是否用的到。

问题二:性能差

这些状态机都是有状态的(Stateful)的,有状态意味着多线程并发情况下如果是单个实例就容易出现线程安全问题。在如今的普遍分布式多线程环境中,你就不得不每次一个请求就创建一个状态机实例。但问题来了一旦碰到某些状态机它的构建过程很复杂,如果当下QPS又很高话,往往会造成系统的性能瓶颈。
在这里我给大家推荐一款阿里开源的状态机:cola-statemachine。github地址:github.com/alibaba/COL…
作者(张建飞:阿里高级技术专家)讲到面对复杂的状态流转,当时他们团队也想搞个状态机来减负,经过深思熟虑、不断类比之后他们考虑自研。希望能设计出一款功能相对简单、性能良好的开源状态机;最后命名为cola-component-statemachine(实现了内部DSL语法;目前最新版本:4.3.1)

示例代码:

//构建一个状态机(生产场景下,生产场景可以直接初始化一个Bean)
StateMachineBuilder<StateMachineTest.ApplyStates, StateMachineTest.ApplyEvents, Context> builder = StateMachineBuilderFactory.create();
      //外部流转(两个不同状态的流转)
      builder.externalTransition()
        .from(StateMachineTest.ApplyStates.APPLY_SUB)//原来状态
        .to(StateMachineTest.ApplyStates.AUDIT_ING)//目标状态
        .on(StateMachineTest.ApplyEvents.SUBMITING)//基于此事件触发
        .when(checkCondition1())//前置过滤条件
        .perform(doAction());//满足条件,最终触发的动作
复制代码

上述代码先构建了一个状态机实例:from和to分别定义了源状态和目标状态,on定义了一个事件(状态机基于事件触发)当状态机匹配到指定的事件后,会进行条件过滤,如果满足指定条件,就会执行perform定义的动作函数,最终状态会从from内的源状态变成to定义的目标状态。

我们一起来看看客户端是怎么触发自定义的状态机的:

复制代码
StateMachine<StateMachineTest.ApplyStates, StateMachineTest.ApplyEvents, Context> stateMachine = builder.build("ChoiceConditionMachine");
//fireEvent发送一个事件;对应上面示例代码的ApplyEvents.SUBMITING.
StateMachineTest.ApplyStates target1 = stateMachine.fireEvent(StateMachineTest.ApplyStates.APPLY_SUB, StateMachineTest.ApplyEvents.SUBMITING, new Context("pass"));
输出:
from:APPLY_SUB to:AUDIT_ING on:SUBMITING condition:pass
复制代码

我把上述三款状态机的示例代码都放在了github上,有兴趣的小伙伴可以自行查阅。

github地址:

github.com/TaoZhuGongB…

总结

好了,此篇文章即将进入尾声,让我们一起来做个总结。

为什么引入状态机?

前言部分我也提到了在面对复杂的状态流转场景下if-else方案主要容易引起可读性、可扩展、易出错等问题,所以引入状态机主要为了降低这些风险。

状态机的实现方案对比:

状态机实现方案我举例了Java枚举、状态模式、开源状态机等几个实现方案。状态模式的问题是它需要定义接口、和实现类还附带一个Context上下文类,编码层面比较复杂。Java枚举版的状态机主要问题是扩展粒度不够基本都是线性扩展,封装在一个类中,太复杂的状态流转这个类也会变得臃肿不堪,维护性变低。
所以也推荐了一款比较理想的开源状态机实现--cola-component-statemachine。它使用相当简单,因为实现了内部DSL,所以可读性很强,当然扩展性也比较不错。

公众号:

里面不仅汇集了硬核的干货技术、还汇集了像左耳朵耗子、张朝阳总结的高效学习方法论、职场升迁窍门、软技能。希望能辅助你达到你想梦想之地!

公众号内回复关键字电子书”下载pdf格式的电子书籍(并发编程、JVM、MYSQL、JAVAEE、Linux、Spring、分布式等,你想要的都有!)、“开发手册”获取阿里开发手册2本、"面试"获取面试PDF资料。

与状态机的技术选型看这篇就够了,最后一个直叫好!!!相似的内容:

状态机的技术选型看这篇就够了,最后一个直叫好!!!

今天跟大家分享一个关于“状态机”的话题。给你讲清楚什么是状态机、为什么需要状态机、适用场景、有哪些具体的实现方案以及各个方案对比(附带github源码地址)

秋招还没Offer怎么办?

如果你是双非院线、没有实习经历、没有出众的技术(算法没刷一千道,也没做过 Spring Cloud 项目)、现在还没有面试(或只有少量的面试)、并且目前还没有 Offer,那么恭喜你,你和目前大部分同学的状态是一样的。 相信我,你并不孤单。 有人会说:“瞎扯,你去看牛客,别人都在为选阿里还是字节而发

一种通用的业务监控触发方案设计

业务监控是指通过技术手段监控业务代码执行的最终结果或者状态是否符合预期,实现业务监控主要分成两步:一、在业务系统中选择节点发送消息触发业务监控;二、系统在接收到mq消息或者定时任务调度时,根据消息中或者任务中的业务数据查询业务执行的结果或状态并与业务预期的结果相对比。目前供销系统的方案如下:

[DP] DP优化总结

写在前面 $ DP $,是每个信息学竞赛选手所必会的算法,而 $ DP $ 中状态的转移又显得尤为关键。本文主要从状态的设计和转移入手,利用各种方法对朴素 $ DP $ 的时间复杂度和空间复杂度进行优化与处理,以达到满足题目要求的目的; 参考文献: 动态规划算法的优化技巧 毛子青 c++ DP总结

状态机的介绍和使用

状态机是有限状态自动机的简称,是现实事物运行规则抽象而成的一个数学模型。状态机,也就是 State Machine ,不是指一台实际机器,而是指一个数学模型。说白了,一般就是指一张状态转换图。

有限状态机在国际计费中的应用探索

今天的话题,我们从一个案例开始谈起。国际计费系统会定期自动生成账单,然后每个账单会按照预设的规则自动进入结算流程,账单从生成之后到结算完成,这期间需要销售支持、结算岗、客户(商家或服务商)、财务、资金等多个不同岗位角色的人员共同参与处理,每个角色处理的环节和操作内容不同,账单的状态也持续发生着改变。

Generator(生成器),入门初基,Coroutine(原生协程),登峰造极,Python3.10并发异步编程async底层实现

普遍意义上讲,生成器是一种特殊的迭代器,它可以在执行过程中暂停并在恢复执行时保留它的状态。而协程,则可以让一个函数在执行过程中暂停并在恢复执行时保留它的状态,在Python3.10中,原生协程的实现手段,就是生成器,或者说的更具体一些:协程就是一种特殊的生成器,而生成器,就是协程的入门心法。 协程底

MapReduce和Spark读取HBase快照表

1.概述 随着大数据技术的不断发展,处理海量数据的需求变得愈发迫切。MapReduce作为一种分布式计算模型,为处理大规模数据提供了有效的解决方案。在这篇博客中,我们将探讨如何使用MapReduce框架读取快照表(Snapshot Table)的数据。快照表是一种记录某一时刻系统状态的表格,通过Ma

Iframe在Vue中的状态保持技术

Iframe是一个历史悠久的HTML元素,根据MDN WEB DOCS官方介绍,Iframe定义为HTML内联框架元素,表示嵌套的Browsing Context,它能够将另一个HTML页面嵌入到当前页面中。Iframe可以廉价实现跨应用级的页面共享,并且具有使用简单、高兼容性、内容隔离等优点,因此以Iframe为核心形成了前端平台架构领域第1代技术。

Flutter状态管理新的实践

声明式UI其实并不是近几年的新技术,但是近几年声明式UI框架非常的火热。单说移动端,跨平台方案有:RN、Flutter。iOS原生有:SwiftUI。android原生有:compose。可以看到声明式UI是以后的前端发展趋势。而状态管理是声明式UI框架的重要组成部分。