關于中臺，現在已經爛大街了。隨便幾個微服務整一整，對外就號稱中臺。但中臺到底是什么?做好中臺需要具備哪些能力?今天我們就來聊一聊中臺。

什么是中臺?

2015 年阿里巴巴提出中臺概念和戰略，從那時候開始「中臺」這個技術名詞就開始火熱起來，尤其是從 2019 年開始進入了爆發期。前段時間還有一篇關于阿里拆中臺的文章，刷遍了全網。

在我看來，中臺就是功能的復用，并且還是業務功能的復用。例如：一個電商公司里，所有系統都需要給用戶發送消息。如果每個系統都要自行實現消息發送，那這個成本就太大了。于是乎就有一個系統專門來做這個事情，實現「發送消息」這個業務功能的復用。

如此一來的話，那其實用微服務不就可以了，何德何能叫得上中臺呢?

這是一個很好的問題，可以讓我們進一步深入思考中臺這個事。

在微服務時代，消息服務提供接口出去，各個系統直接調用發送就行了。這個時候，系統調用方與系統提供方之間的通信，還是非常技術性的，他們之間的通信可能是這樣的：我要發給 XX 用戶、內容是 XX、用 XX 賬號發送、要發送的是 XX 語言等等。

對比起微服務，中臺應該是微服務的產品化。比起微服務方式，中臺的設計需要抽象出自己的一套業務邏輯，屏蔽底層的細節。 就拿發消息這個例子來說：之前是非常簡單地將要發送的參數傳遞給消息發送系統，消息發送系統不做任何封裝。

但對于消息中臺來說，它可能提出一個業務編碼的概念，通過業務編碼與模板與賬號關聯。而對于調用系統來說，只需要告訴我你需要發給哪個用戶，發哪個業務的消息即可。至于怎么匹配模板、怎么匹配賬號，調用方不需要關心。

總的來說，中臺與微服務的區別在于：中臺是對功能的更深層次封裝，可以說是產品層面上的包裝。

說起中臺與微服務的區別，可能還不止功能封裝程度上的區別，可能還有數據開放、權限管控等方面的區別。對于微服務來說，其只是簡單的提供一個服務。如果后續調用方的 B 端管理系統需要查詢消息發送記錄，那么你就會讓一個 B 端系統去查詢一個 C 端系統，這明顯不合適。另外，查詢數據時需要做權限控制，一個系統只能查詢自己的數據，這時候你又得在 C 端的消息發送系統里去做權限控制，整個系統就非常冗余了。

對于中臺來說，其思考的層次會更高一些。中臺將自己當成是某塊通用業務的服務提供者，而不僅僅是一個內部系統。對于核心的業務功能，其與微服務一樣通過接口提供功能。對于數據開放，其通過開放平臺開放數據，并做權限控制。其實企業內部的業務中臺，就很像淘寶開放平臺、京東開放平臺，只不過是開放的對象以及程度不同而已，因此我們完全可以按照開放平臺的思路去建設業務中臺。

中臺的平衡點

我們都說中臺是通用能力的復用，那么哪些是通用能力?哪些該做、哪些不該做?這或許是困擾我們中臺設計人員一個很痛苦的問題了。

要找到平衡點，我的經驗是首先找到兩個極端點。 就拿我做過的消息中臺這個例子來說，左邊的極端點是極端定制化，即業務方要做什么，我們就做什么，冗余了大量的各種各樣的業務細節。右邊的極端點是極端地平庸化，平庸到提供的服務其實和第三方服務商提供的服務沒啥兩樣，那么業務方干脆直接對接第三方得了。

知道了兩個極端點，我們也知道了一個范圍，我們后續要做的就是在兩個點中找到一個平衡點。 其實對于這個平衡點的選擇，更多的是依賴設計人員對于這塊業務的理解。業務人員需要深入地了解整個業務流程，了解哪些功能是所有調用方都重復做的，以此找出中臺要實現的通用功能。接著需要做的，就是將這些內容封裝起來，設計一套業務邏輯和使用流程，讓調用方能簡單、方便地使用。

以我做過的消息中臺而言，我發現許多系統存在的重復功能是：多語言模板匹配和替換、多地區發送賬號匹配。多語言模板匹配和替換，指的是在國際化背景下，用戶都是各個國家的人，我們需要根據用戶的語言匹配對應的模板。多地區發送賬號匹配，指的是在國際化背景下，用戶分布于各個國家地區，每個國家地區的服務商都不同，因此需要匹配不同的賬號去發送。

找出消息中臺的重復功能之后，我們要做的是設計一套業務邏輯和使用流程。對于消息中臺，我們設計了：「系統 - 業務 - 模板組(賬號組)- 模板(賬號)」的核心業務邏輯。1 個調用方對應 1 個系統，1 個系統可以有多個業務，1 個業務在某個渠道(郵件、短信等)只對應一個賬號組，模板組(賬號組)則通過語言 + 站點(國家)去唯一確定一個模板(賬號)。

通過「系統 - 業務 - 模板組(賬號組)- 模板(賬號)」的業務邏輯設計，以及對應的管理后臺配置流程，我們為消息中臺建立了一整套消息發送邏輯。調用方系統可以建立多個業務，來關聯其真實的消息發送場景。每次需要發送某個消息發送場景，提前在管理后臺配置好對應的模板組和賬號組。在發送的時候，只需要告訴消息中臺發送哪個業務、發給誰就可以了。

中臺的演變

當我們設計好一個中臺之后，我們可能希望其實一成不變的。但事實上，中臺也是隨著業務的變化而變化的。就拿我做過的消息中臺來說，一開始其定位只是發送消息通知類，即注冊發送郵件、發貨通知等小批量的消息。但隨著業務的發展，有些系統需要在很短的時間內發送幾百萬甚至幾千萬的消息。

這時候如果使用原有的系統功能，那么勢必導致消息擠壓，造成消息發送延遲。這時候作為中臺的設計者就需要根據自己對業務的理解，以及未來需要的可能性，去做一個架構上的調整。如果判斷未來很可能有更多的系統需要這個功能，那么我們需要調整中臺的業務架構，去實現這個功能。對于短時間內發送幾百萬消息的這種功能，我們后續是用了與之前完全不同的架構去實現的，也設計了完全不同的數據結構以及實現方法。但整體上，還是與原有功能融為一體，成為一個統一的消息中臺服務的。

前面說的是屬于業務發展中出現的新功能，但實際上也有可能是原有功能的不斷精細化。例如我們所說的通知類消息，它們可能有：發貨通知、注冊驗證碼郵件、COD 貨到付款郵件等。隨著業務的發展，通知類消息越來越多，不同類型的消息的優先級矛盾會越來越明顯。

對于 COD 貨到付款郵件來說，其涉及到用戶訂單付款，因此優先級無疑是最高的。而注冊驗證碼郵件，影響到用戶的注冊，相對來說也是優先級較高的。而發貨通知，則只是一個通知的功能，優先級相對優先。在消息越來越多的情況下，消息中臺需要支持發送資源完全隔離的功能，以此來保障高優先級業務的低延遲快速發送。

那么如何進行業務架構調整，既能滿足新功能的需要，又不影響原有的業務功能。這其實就極度考驗中臺設計者對于業務的理解以及對于系統的理解了。

說到消息優先級的問題，有些朋友會說：那我一開始設計的時候就考慮到優先級問題，直接解決了不就好了么?

這個想法很好，但事實是很骨感的。很多時候我們不僅要考慮技術實現，還要考慮業務當前的情況。如果業務當前并沒有多少消息發送流量，所有消息基本上都能很快發送出去，這時消息中臺來實現優先級的功能，有什么意義呢?不僅增加研發成本不說，還讓系統更加復雜，增加了維護成本。

業務這個因素，其實是很多技術人員忽略的一個問題。我們做設計以及實現的時候，不僅要考慮技術擴展性，還要考慮業務目前的發展情況、團隊成員的能力情況，才能做出適合當下情況的最優選擇。 而不是簡單地拍腦袋做一個大而全的東西，用大炮打蚊子，浪費資源。其實對于是否要在項目中使用設計模式，也是類似的思考方式，重點還是得看團隊成員的專業能力。

總結

什么是中臺?我認為中臺是對重復業務功能的產品級別封裝，有別于微服務的系統級簡單封裝。產品級別的封裝需要深入了解業務，定制出一套自己的業務概念，屏蔽底層的細節。此外，數據開放也是中臺本身有別于微服務的一個關鍵點。

如何找到中臺的平衡點?對于平衡點，我提出了一個方法論：確定區間范圍，即知道最好、最差的情況下是什么，然后找到合理的中間態。這個中間態取決于中臺的定位，如果你的定位是公司級的中臺，那么你解決的就應該是公司級別的通用功能。

如何看待中臺的演進?中臺是隨著業務發展的，中臺設計者需要緊跟業務需求，從需求中洞見未來的趨勢，找到中臺的方向。此外，設計之時不僅應該考慮技術問題，也應該考慮當時業務規模、團隊協作、人員能力問題，做出綜合成本最低的設計方案，而不是用大炮打蚊子。

那么做中臺需要哪些能力呢?

其實從上面我的一些思考不難看出：需要有高度抽象思考的能力。 這可以說是最最重要的能力，沒有這種能力，你很難找出共同的功能點，也就很難找到中臺的定位。另一個能力是綜合權衡，做出最優選擇的能力。 在中臺的演進中我們說到要考慮業務規模、團隊協作等情況，這就需要中臺設計者去綜合各種因素，做出最優選擇，而不是單單追求技術的高大上。