孫玄?

奈學教育CEO

讀完需要

10

分鐘

速讀僅需 3 分鐘

• 10年技術老兵，擅長系統架構設計、大數據、運維、機器學習、技術管理等領域；

• 曾供職于百度、58集團、轉轉等公司。

本文根據孫玄老師在〖deeplus 直播第 219 期〗線上分享演講內容整理而成。

微信公眾號：dbaplus

（文末有獲取本期 PPT&回放的途徑，不要錯過）

大家好，今天我將從以下這三方面，來和大家分享一些海量高并發的經驗：

中臺模式和微服務架構到底有什么樣的關系

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

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

1

? ?

中臺模式與微服務架構的關系

現在大家應該都知道，中臺最早是由芬蘭一家著名的游戲公司Supercell提出的，以小前臺的模式來組織若干個開發團隊。

也就是說，你的每個前臺的開發團隊，只需要了解開發一個業務/一個游戲所需要的業務邏輯就行。這樣的話，像每個業務會需要一些公共的東西，比如說像游戲引擎、一些內部的開發工具、基礎設施等等，就不需要花時間去關注，會有一些專門的“部落”，也就是中臺部門來負責提供。“部落”可以根據需要擴展為多個小分隊，每個小分隊都保持共同的目標，“部落”本身并不會提供游戲給消費者。

怎么理解呢？

首先我們都知道公司里面會分為多個前臺，每個前臺需要寫自己的業務邏輯，這個業務邏輯的底層是一個公共的東西，比如說你的游戲引擎、內部的開發工具、平臺、基礎設施等等。

那什么是中臺？這些游戲引擎、內部的開發工具、平臺、基礎設施等等就屬于中臺。

那什么是前臺？你的每個產品其實就是一個前臺，或者說，你每一個產品需要的業務模式就是前臺。

這種中臺模式在業界漸漸流行了起來，在2015年的時候，阿里巴巴張勇（逍遙子）宣布啟動中臺戰略，構建符合數據技術時代，更具備創新性和靈活性的“大中臺、小前臺”的組織機制和業務機制，實現管理模式創新。

這時候是想做一個什么事情呢？其實阿里巴巴想做的一件事情就是把一些產品的技術力量、數據運營力量從前臺剝離出來，成為獨立的中臺。這個中臺就包括了像搜索事業部、共享業務事業部、數據平臺事業部等，為前臺即零售電商事業群提供服務。

也就是說，中臺總共包含了這樣的四部分：

• 搜索事業部，做的是算法中臺。其實從名字來看，搜索事業部更多是在搞搜索，搜索中主要的兩件事一個是召回，一個是排序。所以搜索事業部在做的事情其實就是算法相關的一些事情，會偏多一些；

• 共享業務事業部，做的是業務中臺，包括比如交易中心、商品中心、用戶中心……；

• 數據平臺事業部，圍繞數據，也就是做數據中臺；

• 另外它還會涉及到一塊兒技術相關的（技術中臺），比如存儲、開發的整個框架等等。

那么今天我重點想講的是業務中臺，一個業務中臺到底包含哪些東西，這個對我們也是比較重要的一部分。要考慮的是怎么樣讓你的業務支撐的更加快一些。

業務中臺在我看來更多是一種從公司層面的組織架構，或者說業務架構。我們將業務中臺抽象出來，既然它是一種業務架構和組織架構的結合體，那么我該怎樣實現它呢？

實現的時候，我可以采用微服務架構，也可以采用單體架構，還可以采用SOA架構，還可以采用數據架構。

所以大家想一下，業務中臺也好，技術中臺也好，它想要承擔的責任是什么呢？業務中臺在實現過程中可以采用微服務架構，就僅此而已嗎？

在我看來，微服務架構其實僅僅是中臺模式落地的一種典型技術架構實現方式。這一點大家一定要記住。

理解了這點之后，就不會把整個的微服務架構和整個的業務中臺混為一談了。這也是實際過程中比較重要的一部分，我覺得也比較重要。

接下來，也就是本次分享的第二部分，我們來分析一下，業務中臺在實現微服務架構的時候，應該怎么做？

2

? ?

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

大家可以想一下，假如你要做一個交易業務中臺，或者打算做一個電商業務，業務里面一個請求過來，比如說發布一個商品，到了你的服務端，你要構建你服務的一套架構，要怎樣構建呢？

首先業務過來，一定要有一個接入，負責接入這個請求。接入請求是為了做什么呢？比如可能是負責和前端的一個連接，連接后，要對請求做一些處理，比如說對它做一些請求鑒權、通用參數的檢查、路由的轉發等等，這些東西總得有一個服務來做，這個服務我們就叫做網關層。

圖1

網關層并不負責處理具體的業務邏輯。比如說你發布商品的時候，一定會有一個具體的業務邏輯，這個業務邏輯是誰來處理呢？當然是交給下一層——業務邏輯層。

業務邏輯層里就是對你業務的一個數據的處理。舉個例子，比如說我們整個的業務邏輯層包含什么東西呢？你使用微信，給你好久沒有聯系的一個朋友發了一條消息：“哥們兒，今天有空嗎？我們約個飯”

當你發出去后，微信告訴你信息已發送，但被對方拒收。說明什么？說明你被對方拉黑了。在座的各位都有過這種經歷吧？沒有的話，你的人生是不完整的，哈哈。

那這種情況下，他拉黑的處理，對我們來說就是一個業務邏輯的處理。這個業務邏輯處理，包含“拉黑”這個操作，包括不管你是發消息，還是聊天、轉賬，都需要這樣的一個模塊。既然是一個模塊，我們就把他抽出來，變成了一個業務公共的邏輯層。

所以我們邏輯層一般來說會分為兩部分，一部分是個性化的業務，另一部分是公共的業務。比如“拉黑”這種操作，就是公共的。但不管是公共的業務邏輯，還是個性化的業務邏輯，都需要訪問數據。所以接下來的一層就是數據訪問層（見圖1）。

數據訪問層很顯然，就是提供底層數據庫的一個增刪改查；以及當數據量比較大的時候，要能夠做到分庫分表，做一個Sharding的工作；以及要做到屏蔽底層數據存儲差異性。

再往下就是DB和Cache。

那么，在這個架構里面，大家想想看，我們整個的業務邏輯層包含了哪些部分呢？

圖2

所謂中臺，其實就是哪些東西是公共的，是不變的。

那很顯然，網關是不變的；業務邏輯層是變化的，但業務邏輯層里中臺的部分，是不變化的；數據訪問層也是公共的；包括底層的db，不屬于業務范疇，其實是一個技術的支撐，我們叫技術中臺。

所以在這個架構里面，我們就會看到：

• 網關層屬于業務中臺；

• 公共的業務邏輯層屬于業務中臺；

• 數據訪問層屬于業務中臺；

• 個性化業務邏輯層屬于業務前臺；

• 底層DB屬于技術中臺；

• 注冊中心，已有的配置中心，也可以劃入技術中臺的范疇。

所以我們就會看到，實際上當你將整個的業務按照微服務這樣來落地的時候，網關層、公共業務邏輯層、數據訪問層這些都屬于中臺范疇；個性化的業務邏輯層屬于前臺范疇。大家一定要搞清楚。

搞清楚之后，我們做中臺就比較簡單了，也就是說，取決于能不能在業務層面將公共能力下沉為服務，并做好服務連接。

怎么理解呢？

比如說，像網關層、公共的業務邏輯層等，你應該把它抽象出來，做為一個獨立的服務來執行。這是我們在整體的思路上需要去沉淀的。

那么下沉為服務后，服務連接要怎么去做呢？我們接下來花點時間講講這塊兒。

比如轉轉，里面有些怎樣的業務呢？因為它是轉賣的二手商品，所以就會有C2C（個人對個人）、B2C（商家對個人）、C2B（個人對商家）各種不同的商品模式，會有很多不同的業務。

圖3

在這些業務里面，不論是C2C、B2C還是C2B，這幾種業務模式里面都一定會有些公共的業務邏輯，也一定會有個性化的部分。個性化的東西，比如你是C2C的，有C2C的業務邏輯層；B2C的，有B2C的業務邏輯層；C2B的有C2B的業務邏輯層，那么這時我們在沉淀中臺的時候，就將公共的東西抽出來，變成我們的業務中臺，這個是我們實際過程中在做的一個事兒。

剛才說到了，我們在實現中臺架構的時候，其實就是實現了微服務架構，里面網關、公共邏輯層、數據訪問層屬于業務中臺。但是業務邏輯層，很顯然，它是個性化的，屬于小前臺。我們重點聚焦的就是業務中臺的范疇可以怎么去做，也就是將公共能力下沉為服務。

圖4

另外一塊，業務中臺可能會有很多，比如說商品、交易、搜索、推薦……確實，如果我的前臺業務，比如說新做了一個業務線，怎樣才能讓它一鍵接入呢？這個對我們來說也是一個比較有意思的事情。

大家可以看這個圖，一起想想看：

圖5

圖中右邊部分，使我們整個的一個中臺，比如說商品中心、用戶中心、交易中心、搜索中心等等，還有很多的一些其他的事情，也可以去做。在這種情況下，有這么多的中臺需要接入，當我如果真的需要接入一個小前臺的時候，難道這些中心我都要一個一個接入嗎？

很顯然，對我們來說太麻煩了。我們希望怎樣？

我們希望，一個業務，首先能夠給我分配一個ID，比如是1，就將這個業務注冊為業務中心的1號，注冊完后，接下來我對這個業務的標識就都會通過這個ID來做。當然這個ID有可能是一個ID，也有可能是一個三級ID。比如說一級類，二級類，三級類……

那在這種情況下，大家可以想一個問題：你現在已經對這個業務做好一個標識了，那接下來這個業務需要哪些中臺的能力呢？

你需要做什么？你需要做一個配置。

那這個配置配的是什么呢？

舉個例子，就是把你這個業務需要的中臺，比如要接入商品中心、搜索中心，接下來要做的的事情就是把ID和搜索中心構建起來就好了，你需要在配置中心里配置一下你前臺所需要接入的中臺。

配置完以后會有一個接入策略，也就是以什么方式進行接入，比方說商品要接入到搜索，需要告訴我搜索在接入時要提供哪些字段可建索引、哪些字段不能建索引。首先對業務進行標識以后，業務要接入哪些中臺需要有個配置，配置完后業務要怎么接入需要有個接入策略，這樣當我要發布一個商品的時候，把商品推到搜索中心，搜索中心拿到商品后按照配置規則就會知道哪些字段可建索引、哪些字段不可建索引，最終把整個事情構建起來。因此構建這樣一套接入體系很重要。

3

? ?

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

要構建一個中臺，首先要做一個微服務架構，把微服務架構里的網關、公用業務邏輯、訪問順序做成中臺，把個性化的部分做成業務邏輯層這個小前臺，然后接入的時候把整個業務通過這種方式進行接入。

那么，秒級新業務的接入我們應該怎么做呢？

圖6

大家可以從上圖看到，在很多情況下訂單的整個流程是比較復雜的，電商訂單的狀態持續變化，每個狀態的邏輯關聯關系在不同的狀態里變化都是不一樣的。比如說退款這個操作，在發貨前和發貨后是完全不同的流程，發貨前申請退款就會馬上給予退款，但在已發貨的狀態下申請退款，就需要看商家是否同意，同意則退款完成，不同意則會駁回。

圖7

在很多情況下，同一個業務或者兩個不同的業務，它們80%的業務流程都是一樣的，只有20%不同，如果每一個不同的場景全都通過硬編碼的方式來做，那整個業務的復雜度就會比較高。大家可以對比看看上圖中C2C交易與自營交易的流程。

圖8

如果是在業務初創期，可以用硬編碼就行，硬編碼就是同一個狀態它在滿足不同流程里的繼續往下不同的流轉，你就可以if else。比如說if這個時間等于1干什么事情，else if這個時間等于2干什么事情。這時如果你的狀態不復雜的情況下，這個事情做起來是比較簡單的。但如果狀態比較復雜的情況下用硬編碼，基本上你就廢了，那這種情況下怎么做呢？

這時無非就是要做什么事情？從一個初始狀態到目標狀態，你給它一個動作以后讓它進行流轉，就是在有限狀態以及在狀態之間的一個轉移的數據模型，也就是狀態和動作之間的轉移。什么是動作和轉移？可以看回圖6的例子，已支付是一個初始狀態，申請退款是一個動作，然后它就進入了退款這個目標狀態。其實所有狀態之間的轉移，都可以用圖8說的FSM狀態機來表達。

圖9

這個FSM解決方案的作用是，怎樣在動作的加持下進行狀態的流轉，之后我們就可以對狀態機進行抽象。那么狀態機包含哪些要素？

圖10

首先要定義狀態機的框架，抽象業務場景狀態的角色，包括初識狀態、目標狀態，還有角色及角色不同的操作權限，以及操作對應的事件、事件操作相應的Action實現（Handler）。需要展開說明一下的是事件的定義，就是角色A在初始狀態S1下，執行OP1操作，將使用Handler來處理業務邏輯，執行成功將狀態設置為目標狀態S2。這些就是交易中臺FSM普適的架構設計和實踐。

圖11

如果要用一些結構化來描述應該怎么描述呢？FSM落地其實無非就是狀態轉移表的定義，狀態轉移表里包含操作、角色、初始狀態、目標狀態、Handler這幾個因素，只要構建起這個狀態轉移表，其他就好辦了。如果你用Java語言，那這套框架可以基于Spring State Machine來做。

假設現在有了這套狀態轉移表，或者說是整個通用的FSM框架表，那么要接入新事件的話需要做什么事情？首先是要配置好這個表，然后進行新Handler業務處理的編寫，這樣就能很快進行接入。如果你沒有新的Handler，那整個接入就是秒級的，如果有新的Handler需要做的話，寫幾行代碼就可以了，所以說這套東西對于我們來說整個處理是非常快的。

圖12

如果我們有了這套FSM狀態機，這時再去接入不同的業務，無非就是在數據庫里配置一下，寫一些配置表就好了。也就是說通過中臺FSM能力，只要將狀態圖繪制出來，相應的狀態流轉表配置就已經產生。然后Handler只需要關注當前操作的業務邏輯就行，極大地解耦狀態和業務。這套FSM在早期的百度和58都很好地滿足了業務場景。

>>>>

Q &?A

Q1：為什么不用MySQL做分庫分表？

A：分庫分表用MySQL還是可以的，但畢竟你的數據訪問層還是要關注分庫分表這個動作，這個時候業務開發起來工作量就比較大，所以最好的方式是你的業務同學不需要關注分庫分表，把分庫分表的東西下沉到DB層，讓DB層直接來做就好。另外，分表還會帶來很多問題，比如查詢有多維度的情況下，其實不是很好分表，分表后反而會帶來很多問題。

Q2：互聯網app類的架構能大概講一下嗎？

A：微服務架構包含網關層、業務邏輯層、數據訪問層以及DB，其實這就是一個APP的后臺架構，目前基本都采用微服務架構來做，但有些公司是業務邏輯層和數據訪問層合在一起的，我個人是建議分開。

Q3：請問狀態機機制有什么缺點？

A：我覺得缺點只有一個，就是開發成本比較高，但一旦開發出來之后，只要配置就好了，整個靈活性很高。

Q4：訂單屬于交易領域嗎？

A：是的，屬于交易的子領域，但是訂單和交易要分成兩個不同的服務，因為它們屬于一個大的領域，但不同的子領域，訂單是一個服務，交易是一個服務，還有清算、結算也是一個服務。

Q5：你們的中臺系統都是多IDC的嗎？

A：我們原來是多機房的，有兩個機房，北京一個，天津一個，在這種情況下我們的整個中臺其實是兩個機房的。

Q6：能介紹一下您對中臺的理解嗎？

A：中臺本身就是把一些公共的東西做一個抽象，比如把業務的東西抽象出來那它就是一個中臺，然后用中臺來服務不同的業務。

Q7：你們用Redis都存儲什么數據？用哨兵還是cluster？

A：用Redis存我們的緩存數據。目前主要是用cluster模式，如果量小的話可以用Redis的主從模式，通過哨兵機制來做，但如果是比較成型的還是推薦用cluster模式來做。

Q8：ui層的網關用kong么？

A：不是，推薦大家用zuul。

Q9：狀態機有決策表嗎？決策樹是否都能達到目的？

A：這個不需要，因為它其實現在這個還不涉及到智能決策問題，本質上就是流程都是確定的一個狀態，確定的東西其實沒必要引入一些智能的角色，直接把需要流轉的東西配置在狀態表里就好。

Q10：Spring Cloud gateway上生產如何？

A：還不是非常成熟，不建議直接上生產。

Q11：一個微服務都要對應單獨的一個庫嗎？

A：不一定，有可能會存在多個微服務對應一個DB，還是要看你業務本身的設計，沒必要為了對應而對應。

Q12：docker swarm的overlay網絡是不是慢？用什么網絡好？

A：docker本身沒問題，但swarm用得比較少，我建議你直接用k8s就好了。

Q13：k8s和docker的關系？

A：docker本身是一個容器，目的是讓你方便擴容。想想看當你有很多個容器的時候，每個容器的生命周期、重啟、遷移等，總得有個地方去管理，而k8s就是對docker進行管理的系統。

Q14：您是怎么快速構建知識體系的？

A：很多同學學習了半天，學習了很多知識點，但光有知識點是沒用的，因為無論你最終做一個架構師也好、工程師也好，你都需要具備架構設計的能力，也就是當你面對一個業務場景，能不能給出一個迎刃而解的方案，這種光有很多知識點是沒用的，要由點連成線，由線成面。那這個過程需要干什么呢？我覺得最主要是通過深度思考來把這些知識點關聯起來，這個東西其實很難的，最好的方式就是跟著大牛，讓他帶著你去做。

Q15：老師的職業路線很好，能講一下您每段職業當時的想法嗎？

A：第一是內驅力，就是對自己的職業定位，你想成為什么樣的人？這可以說是拉開人與人之間距離的核心發動機；第二是深度思考能力，就是能不能透過現象看出本質問題，這個能力非常重要；第三是技術視野，就是要把你的眼界打開。

---

獲取本期PPT

請添加菲菲VX：dbafeifei

想要加入中生代架構群的小伙伴，請添加群合伙人大白的微信

申請備注（姓名+公司+技術方向）才能通過哦！

? ?END ? ?? #接力技術，鏈接價值#精彩推薦

?

云計算監控—Prometheus監控系統（文末贈書）

?

520書粉節！薅當當羊毛的機會又!雙!!叒!!!叕!!!!來了

?

當我們在談數字化轉型的時候，我們在談什么？

?

Spring Cloud入門，看這篇就夠了！

?

阿里云MVP喬幫主：五大類型負載均衡的原理場景詳解（文末贈書）

?

阿里高級技術專家邱小俠：微服務架構的理論基礎 - 康威定律

好文點個在看吧！

回看本期直播，請點擊閱讀原文↓

總結

以上是生活随笔為你收集整理的中台设计和实践：海量并发业务中台，新业务秒级接入交易中台的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。