說起Spring狀態機,大家很容易聯想到這個狀態機和設計模式中狀態模式的區別是啥呢?沒錯,Spring狀態機就是狀態模式的一種實現,在介紹Spring狀態機之前,讓我們來看看設計模式中的狀態模式。
1. 狀態模式
狀態模式的定義如下:
狀態模式(State Pattern)是一種行為型設計模式,它允許對象在內部狀態發生變化時改變其行為。在狀態模式中,一個對象的行為取決于其當前狀態,而且可以隨時改變這個狀態。狀態模式將對象的狀態封裝在不同的狀態類中,從而使代碼更加清晰和易于維護。當一個對象的狀態改變時,狀態模式會自動更新該對象的行為,而不需要在代碼中手動進行判斷和處理。
通常業務系統中會存在一些擁有狀態的對象,而且這些狀態之間可以進行轉換,并且在不同的狀態下會表現出不同的行為或者不同的功能,比如交通燈控制系統中會存在紅燈、綠燈和黃燈,再比如訂單系統中的訂單會存在已下單、待支付、待發貨、待收貨等狀態,這些狀態會通過不同的行為進行相互轉換,這時候在系統設計時就可以使用狀態模式。
下面是狀態模式的類圖:
??
可以看到狀態模式主要包含三種類型的角色:
1、上下文(Context)角色:封裝了狀態的實例,負責維護狀態實例,并將請求委托給當前的狀態對象。
2、抽象狀態(State)角色:定義了表示不同狀態的接口,并封裝了該狀態下的行為。所有具體狀態都實現這個接口。
3、具體狀態(Concrete State)角色:具體實現了抽象狀態角色的接口,并封裝了該狀態下的行為。
下面是使用狀態模式實現紅綠燈狀態變更的一個簡單案例:
抽象狀態類:
/** * @description: 抽象狀態類 */ public abstract class MyState { abstract void handler(); }
具體狀態類A
/** * @description: 具體狀態A */ public class RedLightState extends MyState{ @Override void handler() { System.out.println("紅燈停"); } }
具體狀態類B
/** * @description: 具體狀態B */ public class GreenLightState extends MyState{ @Override void handler() { System.out.println("綠燈行"); } }
環境類:維護當前狀態對象,并提供了切換狀態的方法。
/** * @description: 環境類 */ public class MyContext { private MyState state; public void setState(MyState state) { this.state = state; } public void handler() { state.handler(); } }
測試類
/** * @description: 測試狀態模式 */ public class TestStateModel { public static void main(String[] args) { MyContext myContext = new MyContext(); RedLightState redLightState = new RedLightState(); GreenLightState greenLightState = new GreenLightState(); myContext.setState(redLightState); myContext.handler(); //紅燈停 myContext.setState(greenLightState); myContext.handler(); //綠燈行 } }
下面是對應的執行結果
??
可以發現,使用狀態模式中的狀態類在一定程度上也消除了if-else邏輯校驗,看到這里, 有些人可能會有疑問:狀態模式和策略模式的區別是什么呢?
狀態模式更關注對象在不同狀態的行為和狀態之間的流轉,而策略模式更關注對象不同策略的選擇。
上面我們介紹了設計模式中的狀態模式,接下來我們來看看Spring狀態機。
2. Spring狀態機
狀態機,也就是 State Machine ,不是指一臺實際機器,而是指一個數學模型。說白了,就是指一張狀態轉換圖。狀態機是狀態模式的一種應用,相當于上下文角色的一個升級版。在工作流或游戲等各種系統中有大量使用,如各種工作流引擎,它幾乎是狀態機的子集和實現,封裝狀態的變化規則。Spring也提供了一個很好的解決方案。Spring中的組件名稱就叫作狀態機(StateMachine)。狀態機幫助開發者簡化狀態控制的開發過程,讓狀態機結構更加層次化。
通過定義,我們很容易分析得到狀態機應當具備一下幾個要素:
1.當前狀態:也就是狀態流轉的起始狀態。
2.觸發事件:引起狀態之間流轉的一些列動作。
3.響應函數:觸發事件到下一個狀態之間的規則。
4.目標狀態:狀態流轉的目標狀態。
對于組件化的狀態機,當前使用較多的主要是兩種:一種是Spring 狀態機,一種是COLA狀態機,這兩種狀態機的對比如下表所示:
? |
Spring 狀態機 | COLA 狀態機 |
---|---|---|
API 調用 | 使用 Reactive 的 Mono、Flux 方式進行 API 調用 | 同步的 API 調用,如果有需要也可以將方法通過 消息隊列、定時任務、多線程等方式進行異步調用 |
代碼量 | core 包 284 個接口和類 | 36 個接口和類 |
生態 | 非常豐富 | 較為貧瘠 |
定制化難度 | 困難 | 簡單 |
可以看到,Spring狀態機鎖提供的內容較為豐富,當然對于自定義的支持就不如COLA狀態機好,如果對自定義的需求比較高,那建議使用COLA狀態機。
本文以Spring狀態機為例,展示如何在業務系統中使用狀態機。
為了便于大家了解Spring狀態機的實現原理和使用方式以及其提供的功能,下面列出了官方文檔和源碼,感興趣的同學可以閱讀閱讀。
官方文檔: https://docs.spring.io/spring-statemachine/docs/4.0.0/reference/index.html#statemachine-config-states
源代碼: https://github.com/spring-projects/spring-statemachine
3. Spring狀態機實現訂單狀態流轉
對于狀態模式,Spring封裝好了一個組件,就叫狀態機(StateMachine)。Spring狀態機可以幫助我們開發者簡化狀態控制的開發過程,讓狀態機結構更加層次化。下面用Spring狀態機模擬一個訂單狀態流轉的過程。
3.1 環境準備
首先,如果要使用spring狀態機,需要引入對應的jar包,這里我的springboot版本是:2.2.1.RELEASE
org.springframework.statemachine/groupId?> spring-statemachine-core/artifactId?> ${springboot.version}/version?> /dependency?>
下面是簡化的訂單的定義,以及訂單狀態和訂單轉換行為的枚舉
/** * @description: 模擬訂單類 */ @Data public class Order { private Long orderId; private OrderStatusEnum orderStatus; } /** * @description: 訂單狀態 */ public enum OrderStatusEnum { // 待支付 WAIT_PAYMENT, // 待發貨 WAIT_DELIVER, // 待收貨 WAIT_RECEIVE, // 完成 FINISH; } /** * @description:訂單狀態轉換行為 */ public enum OrderStatusChangeEventEnum { //支付 PAYED, //發貨 DELIVERY, //收貨 RECEIVED; }
3.2 構造訂單狀態機
在引入jar包之后,需要構建一個針對訂單狀態流轉的狀態機
訂單狀態機配置類如下:
/** * @description: 訂單狀態機 */ @Configuration @EnableStateMachine public class OrderStatusMachineConfig extends StateMachineConfigurerAdapter { /** * 配置狀態 */ @Override public void configure(StateMachineStateConfigurer states) throws Exception { states.withStates() .initial(OrderStatusEnum.WAIT_PAYMENT) .end(OrderStatusEnum.FINISH) .states(EnumSet.allOf(OrderStatusEnum.class)); } /** * 配置狀態轉換事件關系 */ @Override public void configure(StateMachineTransitionConfigurer transitions) throws Exception { transitions.withExternal().source(OrderStatusEnum.WAIT_PAYMENT).target(OrderStatusEnum.WAIT_DELIVER) .event(OrderStatusChangeEventEnum.PAYED) .and() .withExternal().source(OrderStatusEnum.WAIT_DELIVER).target(OrderStatusEnum.WAIT_RECEIVE) .event(OrderStatusChangeEventEnum.DELIVERY) .and() .withExternal().source(OrderStatusEnum.WAIT_RECEIVE).target(OrderStatusEnum.FINISH) .event(OrderStatusChangeEventEnum.RECEIVED); } }
3.3 編寫狀態機監聽器
監聽狀態變更事件,完成狀態轉換。
/** * @description: 狀態監聽 */ @Component @WithStateMachine @Transactional public class OrderStatusListener { @OnTransition(source = "WAIT_PAYMENT", target = "WAIT_DELIVER") public boolean payTransition(Message message) { Order order = (Order) message.getHeaders().get("order"); order.setOrderStatus(OrderStatusEnum.WAIT_DELIVER); System.out.println("支付,狀態機反饋信息:" + message.getHeaders().toString()); return true; } @OnTransition(source = "WAIT_DELIVER", target = "WAIT_RECEIVE") public boolean deliverTransition(Message message) { Order order = (Order) message.getHeaders().get("order"); order.setOrderStatus(OrderStatusEnum.WAIT_RECEIVE); System.out.println("發貨,狀態機反饋信息:" + message.getHeaders().toString()); return true; } @OnTransition(source = "WAIT_RECEIVE", target = "FINISH") public boolean receiveTransition(Message message) { Order order = (Order) message.getHeaders().get("order"); order.setOrderStatus(OrderStatusEnum.FINISH); System.out.println("收貨,狀態機反饋信息:" + message.getHeaders().toString()); return true; } }
3.4 編寫訂單服務類
模擬對訂單的一些業務操作
/** * @description: 訂單服務 */ @Service public class OrderServiceImpl implements OrderService { @Resource private StateMachine orderStateMachine; private long id = 1L; private Map orders = Maps.newConcurrentMap(); @Override public Order create() { Order order = new Order(); order.setOrderStatus(OrderStatusEnum.WAIT_PAYMENT); order.setOrderId(id++); orders.put(order.getOrderId(), order); System.out.println("訂單創建成功:" + order.toString()); return order; } @Override public Order pay(long id) { Order order = orders.get(id); System.out.println("嘗試支付,訂單號:" + id); Message message = MessageBuilder.withPayload(OrderStatusChangeEventEnum.PAYED). setHeader("order", order).build(); if (!sendEvent(message)) { System.out.println(" 支付失敗, 狀態異常,訂單號:" + id); } return orders.get(id); } @Override public Order deliver(long id) { Order order = orders.get(id); System.out.println(" 嘗試發貨,訂單號:" + id); if (!sendEvent(MessageBuilder.withPayload(OrderStatusChangeEventEnum.DELIVERY) .setHeader("order", order).build())) { System.out.println(" 發貨失敗,狀態異常,訂單號:" + id); } return orders.get(id); } @Override public Order receive(long id) { Order order = orders.get(id); System.out.println(" 嘗試收貨,訂單號:" + id); if (!sendEvent(MessageBuilder.withPayload(OrderStatusChangeEventEnum.RECEIVED) .setHeader("order", order).build())) { System.out.println(" 收貨失敗,狀態異常,訂單號:" + id); } return orders.get(id); } @Override public Map getOrders() { return orders; } /** * 發送狀態轉換事件 * @param message * @return */ private synchronized boolean sendEvent(Message message) { boolean result = false; try { orderStateMachine.start(); result = orderStateMachine.sendEvent(message); } catch (Exception e) { e.printStackTrace(); } finally { if (Objects.nonNull(message)) { Order order = (Order) message.getHeaders().get("order"); if (Objects.nonNull(order) && Objects.equals(order.getOrderStatus(), OrderStatusEnum.FINISH)) { orderStateMachine.stop(); } } } return result; } }
3.5 測試入口
這里編寫一個controller模擬c端用戶請求,為了便于展示,這里使用一個測試方法完成所有的操作
@RestController public class OrderController { @Resource private OrderService orderService; @RequestMapping("/testOrderStatusChange") public String testOrderStatusChange(){ orderService.create(); orderService.create(); orderService.pay(1L); orderService.deliver(1L); orderService.receive(1L); orderService.pay(2L); orderService.deliver(2L); orderService.receive(2L); System.out.println("全部訂單狀態:" + orderService.getOrders()); return "success"; } }
下面是對應的執行結果
??
可以看到spring狀態機很好的控制了訂單在各個狀態之間的流轉。
4. 思考與總結
思考:針對狀態機的特點,還有其他思路實現一個狀態機嗎?下面是一些常規思路,如果還有其他方法歡迎在評論區留言。
1. 消息隊列方式
訂單狀態的流轉可以通過MQ發布一個事件,消費者根據業務條件把訂單狀態進行流轉,可以根據不同的事件發送到不同的Topic。
2. 定時任務驅動
每隔一段時間啟動一下job,根據特定的狀態從數據庫中拿對應的訂單記錄,然后判斷訂單是否有條件到達下一個狀態。
3. 規則引擎方式
業務團隊可以在規則引擎里編寫一系列的狀態及其對應的轉換規則,由規則引擎根據已經加載的規則對輸入數據進行解析,根據解析的結果執行相應的動作,完成狀態流轉。
總結:
本文主要介紹了設計模式中的狀態模式,并在此基礎上介紹了Spring狀態機相關的概念,并根據常見的訂單流轉場景,介紹了Spring狀態機的使用方式。文中如有不當之處,歡迎在評論區批評指正。
5. 參考內容
https://docs.spring.io/spring-statemachine/docs/4.0.0/reference/index.html#statemachine-config-states
https://cloud.tencent.com/developer/article/2198477?areaId=106001
https://cloud.tencent.com/developer/article/2360708?areaId=106001
https://juejin.cn/post/7087064901553750030
https://my.oschina.net/u/4090830/blog/10092135
https://juejin.cn/post/7267506576448929811
審核編輯 黃宇
-
接口
+關注
關注
33文章
9032瀏覽量
153949 -
封裝
+關注
關注
128文章
8741瀏覽量
145729 -
狀態機
+關注
關注
2文章
493瀏覽量
28306 -
spring
+關注
關注
0文章
341瀏覽量
15148 -
組件
+關注
關注
1文章
533瀏覽量
18466
發布評論請先 登錄
Verilog狀態機+設計實例

如何寫好狀態機
什么是狀態機 狀態機的描述三種方法
什么是狀態機?狀態機5要素

狀態模式(狀態機)

評論