大中臺戰略下，中臺將公司業務的公共能力下沉，并采用更加合理、可復用的架構和技術來實現這些基礎能力。在電商行業內，將面臨貨物的采購、商品上架、交易發生、訂單狀態變化、客服介入等大量狀態維護。每個狀態之間具有很強的邏輯關聯關系，比如：退款操作在發貨前和發貨后將是完全不同的流程,如圖1訂單退款流程。

圖1 退款流程圖

由此可見，對于復雜狀態的管理是一個業務依賴，需求多變的場景。在公司初創期，可以采用硬編碼方式，對于每一個操作進行狀態判斷，每一步操作定制一套邏輯鏈路。隨著業務的增加，定制化鏈路顯然不優雅，大量流程代碼無法維護，此時中臺通用解決思路就尤為重要，有限狀態機（Finite State Machine，縮寫：FSM）開始在中臺落地。

1 有限狀態機

? ?

有限狀態機（以下簡稱FSM）又稱有限狀態自動機，簡稱狀態機。維基百科定義是表示有限個狀態以及在這些狀態之間的轉移和動作等行為的數學模型。

這個模型和業務中臺遇到的問題十分吻合。圖1是狀態轉移圖，可以用來表示狀態機，此外可以使用狀態轉移表來表示。如圖2所示：

圖2 狀態轉移表

可以看出，FSM是通過抽象為動作和狀態，管理有限個狀態轉移的模型。動作是在給定時刻要進行的活動的描述，我們總結動作類型有如下：

• 進入動作：在進入狀態時進行

• 退出動作：在退出狀態時進行

• 輸入動作：依賴于當前狀態和輸入條件進行

• 轉移動作：在進行特定轉移時進行

在FSM框架下，將流水線的狀態流轉流程進行了抽象和結構化，將復雜的狀態轉移圖，分割成相鄰狀態的最小單元。這樣相當于搭建了樂高積木，在這套機制上可以組合成復雜的狀態轉移圖。

2 Spring StateMachine

? ?

Spring Statemachine框架主要是幫助開發者簡化狀態機的開發過程，讓狀態機結構更加層次化，我們來看下Spring SM怎么實現。首先最小的樂高模型如圖3所示 ：

圖3?SM最小單元

假如有狀態 STATE1, STATE2和事件EVENT1, EVENT2。事件驅動狀態流轉。下面來分析下Spring SM的主要代碼。

2.1 依賴pom

? ??

<dependencies><dependency><groupId>org.springframework.statemachine</groupId><artifactId>spring-statemachine-core</artifactId><version>2.1.3.RELEASE</version></dependency> </dependencies>

2.2 創建狀態機

? ?

????通過注解來注冊狀態機的三要素：source、target、event

2.3 注解監聽器

??

????通過監聽器感知事件發生，并相應的處理相關邏輯

2.4 運行狀態機

? ?

3 交易中臺

? ?

在交易場景，定義了自己的狀態機框架，抽象了符合交易場景的狀態角色：

• 初始狀態、目標狀態：狀態關系

• 角色：不同角色有不同的操作權限，比如賣家、買家、系統、客服

• 操作：對應事件

• handler：事件操作相應的action實現

因此一個事件我們可以定義為：在角色A，在初始狀態S1下，執行OP1操作，將使用handler來處理，執行成功將狀態設置為目標狀態S2。

3.1 個性化FSM抽象

? ?

鑒于交易的個性化需要，擴展了狀態表的條件，同時使用handler和Java反射，來對邏輯代碼進一步結構化。到這一步后，我們可以將數據模板存儲到數據庫中。如圖4：

圖4 交易中臺FSM狀態表

通過改造，核心代碼FSM執行引擎只有不到100行。通過注冊業務handler，可以靈活的擴充業務能力。同時數據狀態的維護是通過狀態表，而不依賴手動編寫代碼，這對于代碼質量的保證、工程回歸測試都節省了大量的時間。也為中臺實現配置化做好了鋪墊。

3.2 中臺賦能業務

? ?

中臺沉淀了基礎能力，如何實現？中臺如何賦能業務的，業務是否滿意呢？

看下面一個例子，基于交易，C2C、自營是兩個具有極大區別的業務，他們有完全不同的兩套業務流程。C2C平臺需要對買賣兩端進行擔保，而自營更多的是給予買家保證權益。簡化版流程如圖5：

圖5?簡化版交易流程

通過中臺FSM能力，我們只要能將狀態圖繪制出來，那么相應的狀態流轉表配置也已經產生。handler 只需要關注當前操作的業務邏輯，極大的解耦了狀態和業務。

可以毫不夸張的說，一個新業務過來，中臺能在2天時間內單人完成狀態機配置開發上線。這就是中臺的效率。

4 總結

??

FSM解決復雜業務狀態流轉的問題，并以交易業務進行舉例。但是FSM的應用場景遠多于交易。比如客服工單，商品狀態等。但不是所有的流程都需要使用FSM，需要做好業務流程的折中，就像中臺戰略更適用于10-100 階段的公司一樣。

同時FSM只是一個框架，還需要搭建一整套基于它的外圍業務邏輯。在狀態流轉過程中，業務邏輯才是我們的肌肉。框架就像骨骼約束著我們，從而讓技術成長更加健康，這也許就是中臺的魅力。

參考：https://projects.spring.io/spring-statemachine/

? ? ? ?? #接力技術，鏈接價值#精彩推薦1.?阿里技術專家加多：Java異步編程實戰之基于JDK中的Future實現異步編程2. 為什么你干不過黑客？從多個平臺爆發安全漏洞損失千萬說起3.?知道創宇楊冀龍：技術人的商業思維都是錘出來的，真實需求長在客戶的KPI上 4.?程序員埋邏輯炸彈，被判 6 個月5.?一個全世界最大成人網站的爬蟲 漫畫推薦1.?漫畫：程序員真是太太太太太太太太有趣了！ 2.?漫畫：程序員真的是太太太太太太太太難了！3.?漫畫：普通程序員 vs 優秀程序員 4.?漫畫：35歲的IT何去何從？ 5.?漫畫：從修燈泡來看各種 IT 崗位，你是哪一種？ 6. 漫畫：一批90后已經30歲了，更扎心的是…

總結

以上是生活随笔為你收集整理的大中台模式下如何构建复杂业务核心状态机组件的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。