大中台戰略下，中台将公司業務的公共能力下沉，并采用更加合理、可複用的架構和技術來實作這些基礎能力。在電商行業内，将面臨貨物的采購、商品上架、交易發生、訂單狀态變化、客服介入等大量狀态維護。每個狀态之間具有很強的邏輯關聯關系，比如：退款操作在發貨前和發貨後将是完全不同的流程,如圖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
<dependency>
<groupId>org.springframework.statemachine</groupId>
<artifactId>spring-statemachine-core</artifactId>
<version>2.1.3.RELEASE</version>
</dependency>
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隻是一個架構，還需要搭建一整套基于它的外圍業務邏輯。在狀态流轉過程中，業務邏輯才是我們的肌肉。架構就像骨骼限制着我們，進而讓技術成長更加健康，這也許就是中台的魅力。