中臺到底是什么鬼?很多人寫類似的文章，想告訴大家什么是“中臺”。反正我看一篇扔一篇，原因是沒有一篇能夠說清楚。

[[338746]]

 

圖片來自 Pexels

這也不怪誰，原因很簡單，一個“概念”，其實是所有人的想象的合集，跟“鬼”的邏輯是一樣的。

從技術角度上來說，中臺是一種技術架構方法;從組織角度上來說，中臺也是一種組織架構方法。

我只能看清中臺在這兩個角度上的投影。這兩個投影都與架構相關，唯獨與“萬能”無關。

今天我就從技術架構的角度幫大家捋一捋中臺到底是什么鬼。

信息系統架構

軟件開發技術的發展與硬件不一樣。馮諾依曼早在 1945 年就提出了“馮·諾依曼體系結構”，硬件系統在幾十年間，基本沒有任何變化。

 

但是軟件開發的架構，卻在不斷的進化。從最早的單體架構到最新的云原生架構，都是為了應對不斷復雜的需求和爆發式增長的數據。

 

OK，Let's Go!

單體架構

在當年單機時代，所有的軟件架構都是單體架構。當時流行的架構區分為 C/S 架構和 B/S 架構。

C/S 指的是客戶端(那時叫客戶機)和服務端(那時叫服務器)，是桌面程序。B/S 指的是瀏覽器和服務器。

當時是不叫單體架構的，因為還沒區分出其他架構。當時最典型的架構框架叫做 MVC，即 medel(代表數據)、view(代表展示)、controller(代表業務邏輯處理)。

如下圖所示：

 

架構敏感的同學會立刻生出一堆問題：

• 怎么支持超多超復雜的業務啊?
• 擴展性怎么做?
• 怎么解決復用的問題?
• 耦合太緊，一旦出問題就全部完蛋，怎么辦?

是的，但是不用擔心，當時的需求并沒有那么復雜，基本上從業務邏輯到數據訪問到返回結果一路寫下來也就搞定了。

所以單體架構的優點非常明顯：

• 開發簡單
• 測試簡單
• 部署簡單

分層架構

當業務邏輯復雜到一定程度，單體架構就沒法支撐了，上述問題也就逐一暴露出來。

當時的程序員們就想了各種辦法，核心就是“拆”。那么，有幾種拆的方式呢?

Tips：架構演進的過程中，“拆”和“合”就是架構的核心中的核心。

 

是的，有兩種拆分方法，橫向和縱向。橫向把業務邏輯拆分為網關層、業務邏輯層和數據訪問層，這就是“水平分層架構”。

所謂的“前后端分離”，也屬于水平分層的進一步拆分。

 

縱向按照業務進行拆分，每個模塊提供一個單獨的服務，可以拆成用戶服務、商品服務和訂單服務。

這就是“垂直分層架構”，也就是大名鼎鼎的“面向服務架構”--SOA。

拆完之后，該抽象抽象，該解耦解耦，各自對外提供相應服務，單體結構遇到的復雜業務、復用、一錯全崩等問題都迎刃而解了。

 

微服務架構

但是，當需求提的越來越多，業務變得越來越復雜的時候，我們發現，無論是水平拆分還是垂直拆分，都無法再提升我們的開發效率，一些公共耦合會導致系統的復雜度提升，程序包慢慢變成祖傳屎山。

這時候又要祭出架構的法寶“拆”字訣。

 

我們把每一個業務的每一層單獨拆成一個小模塊，各自改各自的東西，不需要再去公共組件中去修改了。

在進行進一步解耦之后，每個模塊的復雜度降低了，模塊之間的耦合度也降低了。由于有多個 DAO，SQL 執行的效率也提升了。

同時，為了應對高吞吐量和海量請求，微服務還對靜態資源和代理進行進一步拆解，引入了 MQ 將同步請求解耦為異步請求，加入 RPC 框架，進行遠程服務調用等等。

 

這時候就會有人問了，這得拆多少個微服務?這對管理簡直是一個災難!各管一灘事，誰去統一管控?

所以微服務架構還有一個事情是必須做的，就是增加管理組件。

這些組件的核心作用就是對各種微服務進行統一管控，不僅能管理微服務的全生命周期，還能在某個微服務被流量撐爆的時候進行各種丟車保帥的操作，在長長的鏈路中，可以不斷向下跟蹤，發現問題的根源。

 

服務網格架構

是的，您發現了，解決一個問題必然會帶來其他問題。微服務做到了進一步解耦，解決了很多分層架構的很多問題，但是遇到了以下挑戰：

• 每個微服務可能會用不同語言的不同版本。
• 有太多的基礎框架和工具需要學習。
• 所有的 client、server 都需要維護 n 個版本。
• 上下游需要同步升級，否則你懂的。

解決辦法呢?能不能進一步解耦?有人說了，都解耦到這種程度了，再解，那得變成啥德行啊?

還真可以。

這個時候，我們的整個微服務體系，就變成了這個網格的樣子，所以叫服務網格架構。

 

這個架構的好處就顯而易見了，所有的通信都讓代理實現，服務就只做自己的業務邏輯處理就好了。所有的跨語言問題、各個微服務版本的問題、上下游的問題全部解決了。

中臺架構

懶婆娘的裹腳布，終于一層層的解開到最后，終于該說中臺架構了。以服務網格架構為分界線，前面的架構優化思路只有一個，就是“拆”。

到服務網格，就沒法再拆下去了，那么還有更好的模式嗎?既然提到了中臺，那么這自然就是解決之道。

Supercell 的故事就不用再重復了。這里必須八卦一下阿里和騰訊，阿里向 Supercell 學習了中臺方法論，并把它進化成超級武器;騰訊把 Supercell 收購了，卻只是用來繼續做游戲。從組織的角度上來說，阿里完勝。

每個微服務都是個性化的，在單一業務線中，這就是最優的架構。但是業務線一多，或者上下游系統太多，每條業務線都在重復造輪子，存在大量資源浪費的情況;不同業務線之間的數據也是孤立的，無法打通。那該怎么辦呢?

 

是的，信息系統的核心就是抽象，我們在業務線之上，再抽象一層就完了。所以中臺架構的核心思想不再是“拆”了，而是“合”。

各自的微服務中必然就有共同的服務，我們可以把這些共同的服務合并、標準化、統一化，封裝后對外提供服務。

所以就會出現各種中心，這些中心的組合，就是中臺：

 

在業務邏輯部分做這種抽象整合重組，就是業務中臺;在數據部分做這種抽象整合重組，就是數據中臺;在算法部分做這種抽象整合重組，就是算法中臺;在技術底層做這種抽象整合重組，就是技術中臺。

而想要實現上述任何一種中臺，必須要先做組織的抽象整合重組，這就是組織中臺。

這也說明了，任何一個中臺并不是孤立的，沒有組織中臺，妄想單獨做其中一個中臺，把中臺當做銀彈，那么必死無疑。

作者：彭文華

編輯：陶家龍

出處：轉載自公眾號大數據架構師(ID：bigdata_arch)