快速成為頂級架構師的內功修煉
查看直播——海量併發高度擴展的交易中臺架構設計與實踐
一、中臺模式和微服務架構的關係
首先講講中臺模式是怎麼來的。在很早之前，芬蘭的一家非常著名的遊戲公司叫Supercell。
這家公司在開發遊戲的時候，能以非常快的速度開發出一個遊戲。這個遊戲其實就是一個業務。
這個業務之所以能夠開發出來，一定會有一些公共的東西來進行賦能和支持。
Supercell以小前臺的方式組織了若干個開發團隊。每個團隊包含開發一款遊戲所需的各種角色，可以快速決策、快速開發。基礎設施、遊戲引擎、內部開發工具和平臺則由類似 “部落” 部門提供。部落可以根據需要擴展為多個小分隊，但各個小分隊都保持共同的目標。部落本身並不提供遊戲給消費者，它只提供一些能力，賦能給你的前臺業務。這裡說的部落，在我看來其實就是一箇中臺。**遊戲本身就是小前臺。
**
對於任何一家公司而言，中臺可以分為技術中臺，業務中臺，算法中臺和數據中臺。
今天我們主要講業務中臺。業務中臺的落地，可以採用單體架構，微服務架構等等。大家可以看到，微服務架構僅僅是業務中臺落地的一種典型技術架構實現方式。
二、海量併發的業務中臺架構如何設計與實踐
今天我們要講整個的業務中臺，它是基於微服務架構的方式實現。在微服務架構模式裡面，哪些是屬於你的業務中臺，哪些屬於你的前臺，哪些是公共的，哪些是個性化的東西，我們要把它區別出來，這是一個很關鍵的因素。
微服務架構分為幾部分。
第一部分是網關層。很顯然它就做一些和網關相關的事情。比如說通用參數的一個檢查，路由的一些轉發，協議的一些轉化。它是一個服務的概念。
第二部分是業務邏輯層。對於電商來說，一定會有自己的業務層。比如說，APP有APP的業務邏輯，小程序也有小程序專門的一些業務邏輯，但它們都要有一個商品發佈邏輯層。它屬於第三部分，公共邏輯層。在這一層裡面，把一些公共的東西全部下沉下來，沉澱在這一層裡面。
第四部分是數據訪問層，包括商品數據訪問層，搜索數據訪問層，推薦數據訪問層，交易數據訪問層。
第五部分是持久化層。每一層都是由一個服務構成，當然，每一層可能有多個進程，這就是整個的業務架構邏輯。
在這個架構裡面，除業務邏輯層以外，其他屬於中臺。具體來說，公共邏輯層，網關層，數據訪問層是業務中臺。持久化層，註冊中心，配置中心，是技術中臺。而業務邏輯層則屬於業務前臺。我們可以通過這樣的方式來構建業務架構邏輯。
構建完以後，我們把業務層面公共能力下沉為服務，並做好服務連接。做好公共服務的全連接，使得前臺業務一鍵接入。
舉個例子，現在來了一個APP，那麼它最終需要接入的中臺是比較多的，比如說你的網關層，你的公共邏輯層，數據訪問層，我們能不能做到業務中臺設計的時候能讓業務很方便的去接入。另外一塊，做好公共服務的一個全連接，它有很多的服務，商品的列表頁，商品的詳情頁，商品的發佈服務，搜索服務，推薦服務等等。新的一個業務，要去接入這些服務的話，其實是非常繁瑣的。
我希望你這時候能給我一個proxy，幫我去連接好這些東西。我的業務接入的時候，一鍵接入 proxy就好了，這樣的話，業務接入的成本是非常低的。
所以在這種情況下，首先，得對你的業務做一個標識，做一個ID化。標識的目的是讓你做一個標準化，有了標準化以後，接下來接入的時候，你的整個業務只需要完成一個填空題就好了。怎麼樣做一個ID標識，往往可以給你的業務做一個三級的分類。
比如說，一級業務是電商，二級業務是手機，三級業務是好貨。當然，你最終需要幾級體系，取決於你的業務特點的需求。這是一套標準化的東西，我們要去構建這樣的一二三級的一個業務。我們也是按照這樣的思路去構建我們的這樣一個生態。
三、秒級新業務接入的交易中臺如何設計和實踐
交易中臺有很多流程，或者說很多狀態。比如說，已支付，已發貨，退款，拒絕退款等等。在這種情況下，我們如何方便地讓多個業務接入。
多個業務之間有一個28原則，可能80%的流程都是公共的，只有20%的流程是有差異的。在這種情況下，交易的流程該怎麼去設計，是一個比較好的問題。如下圖所示，以電商訂單狀態為例，退款在發貨前和發貨後，流程完全不同。
相似業務有兩套業務流程，這種情況是很常見的。在業務初創期，可以硬編碼，通過IF和ELSE語句定製化鏈路，分別針對不同的流程。
隨著業務量越來越多，複雜度會很大，定製化鏈路不一定可行。在這種情況下，我們要運用架構設計的哲學：抽象。可以對業務場景做一個抽象：狀態和動作。於是，一個新的解決方案應運而生，有限狀態機（FSM）：有限狀態以及在狀態之間轉移和動作等行為的數學模型。於是，可以定義交易中臺普適的FSM，定義狀態機的一個框架，以及抽象業務場景的狀態角色。首先，有兩個狀態，一個是初始狀態，一個是目標狀態。初始狀態和目標狀態之間有轉移關係。第二，定義角色。不同角色有不同的操作權限，比如賣家、買家、系統、客服。第三，定義操作，對應事件。第四，定義Handler，事件操作相應的Action實現。其中，一個事件定義為：角色A，在初始狀態S1下，執行OP1操作，將使用handler來處理業務邏輯，執行成功將狀態設置為目標狀態S2。
定義狀態機框架以後，接下來就是FSM的落地。本質上是一個狀態轉移表的定義。如下圖所示，狀態轉移表裡面有這樣幾個角色。第一個是op_type，代表具體的一個操作，只不過我們把這些action變成了一個具體數字。第二個是role，代表你是買家，賣家，還是客戶。第三個是source_status，即源狀態。第四個是target_status，即目標狀態。第五個是handler，代表從源狀態到目標狀態以後要執行什麼操作，比如說拒絕訂單的行為。
如果你是Java生態的，可以通過Spring State Machine框架來實現。如果你是其他語言的，可以通過其他語言的框架進行實現。假設我們現在已經有了這樣一張表，當一個新的業務需要接入的時候，只需要配置狀態轉移表，以及新handler業務處理的編寫，基本上可以秒級完成業務接入。
回到剛才C2C的交易和B2C的交易，假設我們已經有了中臺能力，通過中臺FSM能力，只需要把狀態圖畫出來，相應的狀態流轉表的配置就有了。handler只需要關注當前操作的業務邏輯，極大的解耦狀態和業務。所以實際過程中，不用去煩惱具體的一些事情。
關鍵詞：微服務架構，中臺模式，業務中臺，交易中臺，有限狀態機