大中臺模式下如何構建複雜業務核心狀態機元件
大中臺戰略下,中臺將公司業務的公共能力下沉,並採用更加合理、可複用的架構和技術來實現這些基礎能力。在電商行業內,將面臨貨物的採購、商品上架、交易發生、訂單狀態變化、客服介入等大量狀態維護。每個狀態之間具有很強的邏輯關聯關係,比如:退款操作在發貨前和發貨後將是完全不同的流程,如圖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/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 如何完成複雜查詢的動態構建?
- LangGraph 狀態機:複雜 Agent 任務流程管理實戰
- 狀態機解決複雜邏輯及使用
- 如何使用建造者模式構造複雜物件?模式物件
- 如何構建更好的複雜系統?容器、微服務和持續交付微服務
- Next App Router 模式下,如何同步服務端 Redux 初始狀態?APP模式服務端Redux
- 業務複雜度不夠,如何深挖複雜度
- 寫一個構建複雜資料的日曆元件 Kalendar元件
- Redux複雜應用(一):淺談狀態管理Redux
- 從任務中心看狀態機功能元件設計元件
- 基於大中臺架構的電商業務中臺最佳實踐之一:業務中臺總體架構介紹架構
- 為構建大型複雜系統而生的微服務框架 Erda Infra微服務框架
- 業務中臺系統架構:大中臺+小前臺電子商務系統搭建框架思維架構框架
- 面對複雜業務,if-else coder 如何升級?
- 如何減小ABAP業務程式碼的複雜度複雜度
- 1688 複雜業務場景下的 Serverless 提效實踐Server
- 資料分析:複雜業務場景下,量化評估流程
- 架構設計(五):有狀態服務和無狀態服務架構
- 使用 Slow Admin 構建較複雜的頁面
- 如何優雅地構建易維護、可複用的 Android 業務流程Android
- 中通快遞關鍵業務和複雜架構挑戰下的 Kubernetes 叢集服務暴露架構
- 得物供應鏈複雜業務實時數倉建設之路
- 構建NFT業務生態,如何自建BSN-DDC城市算力中心?
- 企業大中臺策略剖析
- HarmonyOS 應用中複雜業務場景下的介面設計
- C#機房重構-實時檢視上機餘額(狀態模式)C#模式
- 微服務架構:構建PHP微服務生態微服務架構PHP
- 無廢話設計模式(14)結構型模式--狀態模式設計模式
- 如何優雅地構建易維護、可複用的 Android 業務流程(二)Android
- BBC如何使用團隊拓撲構建內部核心平臺?
- MongoDB原理:複製集狀態同步機制MongoDB
- 構建企業級 Agent 系統:核心元件設計與最佳化元件
- 悟空活動中臺 - 微元件狀態管理(上)元件
- 如何快速構建React元件庫React元件
- 設計模式:狀態模式設計模式
- 設計模式-狀態模式設計模式
- 防機刷防作弊 火爆的教育平臺如何構建第一道業務安全防線
- 還在用ifelse來寫業務?瞭解下Spring狀態機Spring