在平常的后端项目开发中,状态机模式的使用其实没有大家想象中那么常见,笔者之前由于不在电商领域工作,很少在业务代码中用状态机来管理各种状态,一般都是手动get/set状态值。去年笔者进入了电商领域从事后端开发。电商领域,状态又多又复杂,如果仍然在业务代码中东一块西一块维护状态值,很容易陷入出了问题难于Debug,难于追责的窘境。
碰巧有个新启动的项目需要进行订单状态的管理,我着手将Spring StateMachine接入了进来,管理购物订单状态,不得不说,Spring StateMachine全家桶的文档写的是不错,并且Spring StateMachine也是有官方背书的。但是,它实在是太”重“了,想要简单修改一个订单的状态,需要十分复杂的代码来实现。具体就不在这里展开了,不然我感觉可以吐槽一整天。
说到底Spring StateMachine上手难度非常大,如果没有用来做重型状态机的需求,十分不推荐普通的小项目进行接入。
最最重要的是,由于Spring StateMachine状态机实例不是无状态的,无法做到线程安全,所以代码要么需要使用锁同步,要么需要用Threadlocal,非常的痛苦和难用。 例如下面的Spring StateMachine代码就用了重量级锁保证线程安全,在高并发的互联网应用中,这种代码留的隐患非常大。
private synchronized boolean sendEvent(Message message, OrderEntity orderEntity) {
boolean result = false;
try {
stateMachine.start();
// 尝试恢复状态机状态
persister.restore(stateMachine, orderEntity);
// 执行事件
result = stateMachine.sendEvent(message);
// 持久化状态机状态
persister.persist(stateMachine, (OrderEntity) message.getHeaders().get("purchaseOrder"));
} catch (Exception e) {
log.error("sendEvent error", e);
} finally {
stateMachine.stop();
}
return result;
}
吃了一次亏后,我再一次在网上翻阅各种Java状态机的实现,有大的开源项目,也有小而美的个人实现。结果在COLA架构中发现了COLA还写了一套状态机实现。COLA的作者给我们提供了一个无状态的,轻量化的状态机,接入十分简单。并且由于无状态的特点,可以做到线程安全,支持电商的高并发场景。
COLA是什么?如果你还没听说过COLA,不妨看一看我之前的文章,传送门如下:
如何保证同事的代码不会腐烂?一文带你了解 Alibaba COLA 架构
如果你需要在项目中引入状态机,此时此刻,我会推荐使用COLA状态机。
COLA状态机是在Github开源的,作者也写了介绍文章:
实现一个状态机引擎,教你看清DSL的本质_张建飞(Frank)的博客-CSDN博客_状态机引擎
官方文章的前半部分重点介绍了DSL(Domain Specific Languages),这一部分比较抽象和概念化,大家感兴趣,可以前往原文查看。我精简一下DSL的主要含义:
什么是DSL? DSL是一种工具,它的核心价值在于,它提供了一种手段,可以更加清晰地就系统某部分的意图进行沟通。
比如正则表达式,
/\d{3}-\d{3}-\d{4}/
就是一个典型的DSL,解决的是字符串匹配这个特定领域的问题。
文章的后半部分重点阐述了作者为什么要做COLA状态机?想必这也是读者比较好奇的问题。我帮大家精简一下原文的表述:
所以COLA状态机设计的目标很明确,有两个核心理念:
COLA状态机的核心概念如下图所示,主要包括:
State:状态
Event:事件,状态由事件触发,引起变化
Transition:流转,表示从一个状态到另一个状态
External Transition:外部流转,两个不同状态之间的流转
Internal Transition:内部流转,同一个状态之间的流转
Condition:条件,表示是否允许到达某个状态
Action:动作,到达某个状态之后,可以做什么
StateMachine:状态机
这一小节,我们先讲几个COLA状态机最重要两个部分,一个是它使用的连贯接口,一个是状态机的注册和使用原理。如果你暂时对它的实现原理不感兴趣,可以直接跳过本小节,直接看后面的实战代码部分。
PS:讲解的代码版本为cola-component-statemachine 4.2.0-SNAPSHOT
下图展示了COLA状态机的源代码目录,可以看到非常的简洁。
COLA状态机的定义使用了连贯接口Fluent Interfaces,连贯接口的一个重要作用是,限定方法调用的顺序。比如,在构建状态机的时候,我们只有在调用了from方法后,才能调用to方法,Builder模式没有这个功能。
下图中可以看到,我们在使用的时候是被严格限制的:
StateMachineBuilder builder = StateMachineBuilderFactory.create();
builder.externalTransition()
.from(States.STATE1)
.to(States.STATE2)
.on(Events.EVENT1)
.when(checkCondition())
.perform(doAction());
这是如何实现的?其实是使用了Java接口来实现。
这里简单梳理一下状态机的注册和触发原理。
用户执行如下代码来创建一个状态机,指定一个MACHINE_ID:
StateMachine stateMachine = builder.build(MACHINE_ID);
COLA会将该状态机在StateMachineFactory类中,放入一个ConcurrentHashMap,以状态机名为key注册。
static Map stateMachineMap = new ConcurrentHashMap<>();
注册好后,用户便可以使用状态机,通过类似下方的代码触发状态机的状态流转:
stateMachine.fireEvent(StateMachineTest.States.STATE1, StateMachineTest.Events.EVENT1, new Context("1"));
内部实现如下:
transition.transit方法中:
检查本次流转是否符合condition,符合,则执行对应的action。
**PS:以下实战代码取自COLA官方仓库测试类
@Test
public void testExternalNormal(){
StateMachineBuilder builder = StateMachineBuilderFactory.create();
builder.externalTransition()
.from(States.STATE1)
.to(States.STATE2)
.on(Events.EVENT1)
.when(checkCondition())
.perform(doAction());
StateMachine stateMachine = builder.build(MACHINE_ID);
States target = stateMachine.fireEvent(States.STATE1, Events.EVENT1, new Context());
Assert.assertEquals(States.STATE2, target);
}
private Condition checkCondition() {
return (ctx) -> {return true;};
}
private Action doAction() {
return (from, to, event, ctx)->{
System.out.println(ctx.operator+" is operating "+ctx.entityId+" from:"+from+" to:"+to+" on:"+event);
};
}
可以看到,每次进行状态流转时,检查checkCondition(),当返回true,执行状态流转的操作doAction()。
后面所有的checkCondition()和doAction()方法在下方就不再重复贴出了。
@Test
public void testExternalTransitionsNormal(){
StateMachineBuilder builder = StateMachineBuilderFactory.create();
builder.externalTransitions()
.fromAmong(States.STATE1, States.STATE2, States.STATE3)
.to(States.STATE4)
.on(Events.EVENT1)
.when(checkCondition())
.perform(doAction());
StateMachine stateMachine = builder.build(MACHINE_ID+"1");
States target = stateMachine.fireEvent(States.STATE2, Events.EVENT1, new Context());
Assert.assertEquals(States.STATE4, target);
}
@Test
public void testInternalNormal(){
StateMachineBuilder builder = StateMachineBuilderFactory.create();
builder.internalTransition()
.within(States.STATE1)
.on(Events.INTERNAL_EVENT)
.when(checkCondition())
.perform(doAction());
StateMachine stateMachine = builder.build(MACHINE_ID+"2");
stateMachine.fireEvent(States.STATE1, Events.EVENT1, new Context());
States target = stateMachine.fireEvent(States.STATE1, Events.INTERNAL_EVENT, new Context());
Assert.assertEquals(States.STATE1, target);
}
@Test
public void testMultiThread(){
buildStateMachine("testMultiThread");
for(int i=0 ; i<10 ; i++){
Thread thread = new Thread(()->{
StateMachine stateMachine = StateMachineFactory.get("testMultiThread");
States target = stateMachine.fireEvent(States.STATE1, Events.EVENT1, new Context());
Assert.assertEquals(States.STATE2, target);
});
thread.start();
}
for(int i=0 ; i<10 ; i++) {
Thread thread = new Thread(() -> {
StateMachine stateMachine = StateMachineFactory.get("testMultiThread");
States target = stateMachine.fireEvent(States.STATE1, Events.EVENT4, new Context());
Assert.assertEquals(States.STATE4, target);
});
thread.start();
}
for(int i=0 ; i<10 ; i++) {
Thread thread = new Thread(() -> {
StateMachine stateMachine = StateMachineFactory.get("testMultiThread");
States target = stateMachine.fireEvent(States.STATE1, Events.EVENT3, new Context());
Assert.assertEquals(States.STATE3, target);
});
thread.start();
}
}
由于COLA状态机时无状态的状态机,所以性能是很高的。相比起来,SpringStateMachine由于是有状态的,就需要使用者自行保证线程安全了。
/**
* 测试选择分支,针对同一个事件:EVENT1
* if condition == "1", STATE1 --> STATE1
* if condition == "2" , STATE1 --> STATE2
* if condition == "3" , STATE1 --> STATE3
*/
@Test
public void testChoice(){
StateMachineBuilder builder = StateMachineBuilderFactory.create();
builder.internalTransition()
.within(StateMachineTest.States.STATE1)
.on(StateMachineTest.Events.EVENT1)
.when(checkCondition1())
.perform(doAction());
builder.externalTransition()
.from(StateMachineTest.States.STATE1)
.to(StateMachineTest.States.STATE2)
.on(StateMachineTest.Events.EVENT1)
.when(checkCondition2())
.perform(doAction());
builder.externalTransition()
.from(StateMachineTest.States.STATE1)
.to(StateMachineTest.States.STATE3)
.on(StateMachineTest.Events.EVENT1)
.when(checkCondition3())
.perform(doAction());
StateMachine stateMachine = builder.build("ChoiceConditionMachine");
StateMachineTest.States target1 = stateMachine.fireEvent(StateMachineTest.States.STATE1, StateMachineTest.Events.EVENT1, new Context("1"));
Assert.assertEquals(StateMachineTest.States.STATE1,target1);
StateMachineTest.States target2 = stateMachine.fireEvent(StateMachineTest.States.STATE1, StateMachineTest.Events.EVENT1, new Context("2"));
Assert.assertEquals(StateMachineTest.States.STATE2,target2);
StateMachineTest.States target3 = stateMachine.fireEvent(StateMachineTest.States.STATE1, StateMachineTest.Events.EVENT1, new Context("3"));
Assert.assertEquals(StateMachineTest.States.STATE3,target3);
}
可以看到,编写一个多分支的状态机也是非常简单明了的。
没想到吧,还能通过代码定义好的状态机反向生成plantUML图,实现状态机的可视化。(可以用图说话,和产品对比下状态实现的是否正确了。)
@Test
public void testConditionNotMeet(){
StateMachineBuilder builder = StateMachineBuilderFactory.create();
builder.externalTransition()
.from(StateMachineTest.States.STATE1)
.to(StateMachineTest.States.STATE2)
.on(StateMachineTest.Events.EVENT1)
.when(checkConditionFalse())
.perform(doAction());
StateMachine stateMachine = builder.build("NotMeetConditionMachine");
StateMachineTest.States target = stateMachine.fireEvent(StateMachineTest.States.STATE1, StateMachineTest.Events.EVENT1, new StateMachineTest.Context());
Assert.assertEquals(StateMachineTest.States.STATE1,target);
}
可以看到,当checkConditionFalse()执行时,永远不会满足状态流转的条件,则状态不会变化,会直接返回原来的STATE1。相关源码在这里:
@Test(expected = StateMachineException.class)
public void testDuplicatedTransition(){
StateMachineBuilder builder = StateMachineBuilderFactory.create();
builder.externalTransition()
.from(StateMachineTest.States.STATE1)
.to(StateMachineTest.States.STATE2)
.on(StateMachineTest.Events.EVENT1)
.when(checkCondition())
.perform(doAction());
builder.externalTransition()
.from(StateMachineTest.States.STATE1)
.to(StateMachineTest.States.STATE2)
.on(StateMachineTest.Events.EVENT1)
.when(checkCondition())
.perform(doAction());
}
会在第二次builder执行到on(StateMachineTest.Events.EVENT1)函数时,抛出StateMachineException异常。抛出异常在on()的verify检查这里,如下:
@Test(expected = StateMachineException.class)
public void testDuplicateMachine(){
StateMachineBuilder builder = StateMachineBuilderFactory.create();
builder.externalTransition()
.from(StateMachineTest.States.STATE1)
.to(StateMachineTest.States.STATE2)
.on(StateMachineTest.Events.EVENT1)
.when(checkCondition())
.perform(doAction());
builder.build("DuplicatedMachine");
builder.build("DuplicatedMachine");
}
会在第二次build同名状态机时抛出StateMachineException异常。抛出异常的源码在状态机的注册函数中,如下:
为了不把篇幅拉得过长,在这里无法详细地横向对比几大主流状态机(Spring Statemachine,Squirrel statemachine等)和COLA的区别,不过基于笔者在Spring Statemachine踩过的深坑,目前来看,COLA状态机的简洁设计适合用在订单管理等小型状态机的维护,如果你想要在你的项目中接入状态机,又不需要嵌套、并行等高级玩法,那么COLA是个十分合适的选择。