大中臺模式下如何構建複雜業務核心狀態機組件

大中臺戰略下，中臺將公司業務的公共能力下沉，並採用更加合理、可複用的架構和技術來實現這些基礎能力。在電商行業內，將面臨貨物的採購、商品上架、交易發生、訂單狀態變化、客服介入等大量狀態維護。每一個狀態之間具備很強的邏輯關聯關係，好比：退款操做在發貨前和發貨後將是徹底不一樣的流程,如圖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只是一個框架，還須要搭建一整套基於它的外圍業務邏輯。在狀態流轉過程當中，業務邏輯纔是咱們的肌肉。框架就像骨骼約束着咱們，從而讓技術成長更加健康，這也許就是中臺的魅力。
免費領取更多技術資料及視頻