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

奈學教育發表於2020-06-12

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

免費領取更多技術資料及影片

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/69976011/viewspace-2698061/,如需轉載,請註明出處,否則將追究法律責任。

相關文章