快速成為頂級架構師的内功修煉
檢視直播——海量并發高度擴充的交易中台架構設計與實踐
一、中台模式和微服務架構的關系
首先講講中台模式是怎麼來的。在很早之前，芬蘭的一家非常著名的遊戲公司叫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隻需要關注目前操作的業務邏輯，極大的解耦狀态和業務。是以實際過程中，不用去煩惱具體的一些事情。
關鍵詞：微服務架構，中台模式，業務中台，交易中台，有限狀态機