開發與維運

海量併發高度擴展的交易中臺架構設計與實踐——阿里雲 MVP孫玄

快速成為頂級架構師的內功修煉

查看直播——海量併發高度擴展的交易中臺架構設計與實踐

一、中臺模式和微服務架構的關係

首先講講中臺模式是怎麼來的。在很早之前,芬蘭的一家非常著名的遊戲公司叫Supercell。

這家公司在開發遊戲的時候,能以非常快的速度開發出一個遊戲。這個遊戲其實就是一個業務。

這個業務之所以能夠開發出來,一定會有一些公共的東西來進行賦能和支持。

Supercell以小前臺的方式組織了若干個開發團隊。每個團隊包含開發一款遊戲所需的各種角色,可以快速決策、快速開發。基礎設施、遊戲引擎、內部開發工具和平臺則由類似 “部落” 部門提供。部落可以根據需要擴展為多個小分隊,但各個小分隊都保持共同的目標。部落本身並不提供遊戲給消費者,它只提供一些能力,賦能給你的前臺業務。這裡說的部落,在我看來其實就是一箇中臺。**遊戲本身就是小前臺。
**
image.png

對於任何一家公司而言,中臺可以分為技術中臺,業務中臺,算法中臺和數據中臺。

今天我們主要講業務中臺。業務中臺的落地,可以採用單體架構,微服務架構等等。大家可以看到,微服務架構僅僅是業務中臺落地的一種典型技術架構實現方式。

二、海量併發的業務中臺架構如何設計與實踐

今天我們要講整個的業務中臺,它是基於微服務架構的方式實現。在微服務架構模式裡面,哪些是屬於你的業務中臺,哪些屬於你的前臺,哪些是公共的,哪些是個性化的東西,我們要把它區別出來,這是一個很關鍵的因素。

微服務架構分為幾部分。

第一部分是網關層。很顯然它就做一些和網關相關的事情。比如說通用參數的一個檢查,路由的一些轉發,協議的一些轉化。它是一個服務的概念。

第二部分是業務邏輯層。對於電商來說,一定會有自己的業務層。比如說,APP有APP的業務邏輯,小程序也有小程序專門的一些業務邏輯,但它們都要有一個商品發佈邏輯層。它屬於第三部分,公共邏輯層。在這一層裡面,把一些公共的東西全部下沉下來,沉澱在這一層裡面。

第四部分是數據訪問層,包括商品數據訪問層,搜索數據訪問層,推薦數據訪問層,交易數據訪問層。

第五部分是持久化層。每一層都是由一個服務構成,當然,每一層可能有多個進程,這就是整個的業務架構邏輯。

在這個架構裡面,除業務邏輯層以外,其他屬於中臺。具體來說,公共邏輯層,網關層,數據訪問層是業務中臺。持久化層,註冊中心,配置中心,是技術中臺。而業務邏輯層則屬於業務前臺。我們可以通過這樣的方式來構建業務架構邏輯。

image.png

構建完以後,我們把業務層面公共能力下沉為服務,並做好服務連接。做好公共服務的全連接,使得前臺業務一鍵接入

舉個例子,現在來了一個APP,那麼它最終需要接入的中臺是比較多的,比如說你的網關層,你的公共邏輯層,數據訪問層,我們能不能做到業務中臺設計的時候能讓業務很方便的去接入。另外一塊,做好公共服務的一個全連接,它有很多的服務,商品的列表頁,商品的詳情頁,商品的發佈服務,搜索服務,推薦服務等等。新的一個業務,要去接入這些服務的話,其實是非常繁瑣的。

我希望你這時候能給我一個proxy,幫我去連接好這些東西。我的業務接入的時候,一鍵接入 proxy就好了,這樣的話,業務接入的成本是非常低的。

所以在這種情況下,首先,得對你的業務做一個標識,做一個ID化。標識的目的是讓你做一個標準化,有了標準化以後,接下來接入的時候,你的整個業務只需要完成一個填空題就好了。怎麼樣做一個ID標識,往往可以給你的業務做一個三級的分類。

比如說,一級業務是電商,二級業務是手機,三級業務是好貨。當然,你最終需要幾級體系,取決於你的業務特點的需求。這是一套標準化的東西,我們要去構建這樣的一二三級的一個業務。我們也是按照這樣的思路去構建我們的這樣一個生態。

image.png

三、秒級新業務接入的交易中臺如何設計和實踐

交易中臺有很多流程,或者說很多狀態。比如說,已支付,已發貨,退款,拒絕退款等等。在這種情況下,我們如何方便地讓多個業務接入。

多個業務之間有一個28原則,可能80%的流程都是公共的,只有20%的流程是有差異的。在這種情況下,交易的流程該怎麼去設計,是一個比較好的問題。如下圖所示,以電商訂單狀態為例,退款在發貨前和發貨後,流程完全不同。

image.png

相似業務有兩套業務流程,這種情況是很常見的。在業務初創期,可以硬編碼,通過IF和ELSE語句定製化鏈路,分別針對不同的流程。

image.png

隨著業務量越來越多,複雜度會很大,定製化鏈路不一定可行。在這種情況下,我們要運用架構設計的哲學:抽象。可以對業務場景做一個抽象:狀態和動作。於是,一個新的解決方案應運而生,有限狀態機(FSM):有限狀態以及在狀態之間轉移和動作等行為的數學模型。於是,可以定義交易中臺普適的FSM,定義狀態機的一個框架,以及抽象業務場景的狀態角色。首先,有兩個狀態,一個是初始狀態,一個是目標狀態。初始狀態和目標狀態之間有轉移關係。第二,定義角色。不同角色有不同的操作權限,比如賣家、買家、系統、客服。第三,定義操作,對應事件。第四,定義Handler,事件操作相應的Action實現。其中,一個事件定義為:角色A,在初始狀態S1下,執行OP1操作,將使用handler來處理業務邏輯,執行成功將狀態設置為目標狀態S2

image.png

定義狀態機框架以後,接下來就是FSM的落地。本質上是一個狀態轉移表的定義。如下圖所示,狀態轉移表裡面有這樣幾個角色。第一個是op_type,代表具體的一個操作,只不過我們把這些action變成了一個具體數字。第二個是role,代表你是買家,賣家,還是客戶。第三個是source_status,即源狀態。第四個是target_status,即目標狀態。第五個是handler,代表從源狀態到目標狀態以後要執行什麼操作,比如說拒絕訂單的行為。

如果你是Java生態的,可以通過Spring State Machine框架來實現。如果你是其他語言的,可以通過其他語言的框架進行實現。假設我們現在已經有了這樣一張表,當一個新的業務需要接入的時候,只需要配置狀態轉移表,以及新handler業務處理的編寫,基本上可以秒級完成業務接入。

image.png

回到剛才C2C的交易和B2C的交易,假設我們已經有了中臺能力,通過中臺FSM能力,只需要把狀態圖畫出來,相應的狀態流轉表的配置就有了。handler只需要關注當前操作的業務邏輯,極大的解耦狀態和業務。所以實際過程中,不用去煩惱具體的一些事情。

image.png

關鍵詞:微服務架構,中臺模式,業務中臺,交易中臺,有限狀態機

快速成為頂級架構師的內功修煉

查看直播——海量併發高度擴展的交易中臺架構設計與實踐

Leave a Reply

Your email address will not be published. Required fields are marked *