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

[[338746]]

 

圖片來自 Pexels

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

從技術(shù)角度上來說，中臺是一種技術(shù)架構(gòu)方法;從組織角度上來說，中臺也是一種組織架構(gòu)方法。

我只能看清中臺在這兩個角度上的投影。這兩個投影都與架構(gòu)相關(guān)，唯獨與“萬能”無關(guān)。

今天我就從技術(shù)架構(gòu)的角度幫大家捋一捋中臺到底是什么鬼。

信息系統(tǒng)架構(gòu)

軟件開發(fā)技術(shù)的發(fā)展與硬件不一樣。馮諾依曼早在 1945 年就提出了“馮·諾依曼體系結(jié)構(gòu)”，硬件系統(tǒng)在幾十年間，基本沒有任何變化。

 

但是軟件開發(fā)的架構(gòu)，卻在不斷的進(jìn)化。從最早的單體架構(gòu)到最新的云原生架構(gòu)，都是為了應(yīng)對不斷復(fù)雜的需求和爆發(fā)式增長的數(shù)據(jù)。

 

OK，Let's Go!

單體架構(gòu)

在當(dāng)年單機(jī)時代，所有的軟件架構(gòu)都是單體架構(gòu)。當(dāng)時流行的架構(gòu)區(qū)分為 C/S 架構(gòu)和 B/S 架構(gòu)。

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

當(dāng)時是不叫單體架構(gòu)的，因為還沒區(qū)分出其他架構(gòu)。當(dāng)時最典型的架構(gòu)框架叫做 MVC，即 medel(代表數(shù)據(jù))、view(代表展示)、controller(代表業(yè)務(wù)邏輯處理)。

如下圖所示：

 

架構(gòu)敏感的同學(xué)會立刻生出一堆問題：

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

是的，但是不用擔(dān)心，當(dāng)時的需求并沒有那么復(fù)雜，基本上從業(yè)務(wù)邏輯到數(shù)據(jù)訪問到返回結(jié)果一路寫下來也就搞定了。

所以單體架構(gòu)的優(yōu)點非常明顯：

• 開發(fā)簡單
• 測試簡單
• 部署簡單

分層架構(gòu)

當(dāng)業(yè)務(wù)邏輯復(fù)雜到一定程度，單體架構(gòu)就沒法支撐了，上述問題也就逐一暴露出來。

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

Tips：架構(gòu)演進(jìn)的過程中，“拆”和“合”就是架構(gòu)的核心中的核心。

 

是的，有兩種拆分方法，橫向和縱向。橫向把業(yè)務(wù)邏輯拆分為網(wǎng)關(guān)層、業(yè)務(wù)邏輯層和數(shù)據(jù)訪問層，這就是“水平分層架構(gòu)”。

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

 

縱向按照業(yè)務(wù)進(jìn)行拆分，每個模塊提供一個單獨的服務(wù)，可以拆成用戶服務(wù)、商品服務(wù)和訂單服務(wù)。

這就是“垂直分層架構(gòu)”，也就是大名鼎鼎的“面向服務(wù)架構(gòu)”--SOA。

拆完之后，該抽象抽象，該解耦解耦，各自對外提供相應(yīng)服務(wù)，單體結(jié)構(gòu)遇到的復(fù)雜業(yè)務(wù)、復(fù)用、一錯全崩等問題都迎刃而解了。

 

微服務(wù)架構(gòu)

但是，當(dāng)需求提的越來越多，業(yè)務(wù)變得越來越復(fù)雜的時候，我們發(fā)現(xiàn)，無論是水平拆分還是垂直拆分，都無法再提升我們的開發(fā)效率，一些公共耦合會導(dǎo)致系統(tǒng)的復(fù)雜度提升，程序包慢慢變成祖?zhèn)魇荷健?/p>

這時候又要祭出架構(gòu)的法寶“拆”字訣。

 

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

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

同時，為了應(yīng)對高吞吐量和海量請求，微服務(wù)還對靜態(tài)資源和代理進(jìn)行進(jìn)一步拆解，引入了 MQ 將同步請求解耦為異步請求，加入 RPC 框架，進(jìn)行遠(yuǎn)程服務(wù)調(diào)用等等。

 

這時候就會有人問了，這得拆多少個微服務(wù)?這對管理簡直是一個災(zāi)難!各管一灘事，誰去統(tǒng)一管控?

所以微服務(wù)架構(gòu)還有一個事情是必須做的，就是增加管理組件。

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

 

服務(wù)網(wǎng)格架構(gòu)

是的，您發(fā)現(xiàn)了，解決一個問題必然會帶來其他問題。微服務(wù)做到了進(jìn)一步解耦，解決了很多分層架構(gòu)的很多問題，但是遇到了以下挑戰(zhàn)：

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

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

還真可以。

這個時候，我們的整個微服務(wù)體系，就變成了這個網(wǎng)格的樣子，所以叫服務(wù)網(wǎng)格架構(gòu)。

 

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

中臺架構(gòu)

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

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

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

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

 

是的，信息系統(tǒng)的核心就是抽象，我們在業(yè)務(wù)線之上，再抽象一層就完了。所以中臺架構(gòu)的核心思想不再是“拆”了，而是“合”。

各自的微服務(wù)中必然就有共同的服務(wù)，我們可以把這些共同的服務(wù)合并、標(biāo)準(zhǔn)化、統(tǒng)一化，封裝后對外提供服務(wù)。

所以就會出現(xiàn)各種中心，這些中心的組合，就是中臺：

 

在業(yè)務(wù)邏輯部分做這種抽象整合重組，就是業(yè)務(wù)中臺;在數(shù)據(jù)部分做這種抽象整合重組，就是數(shù)據(jù)中臺;在算法部分做這種抽象整合重組，就是算法中臺;在技術(shù)底層做這種抽象整合重組，就是技術(shù)中臺。

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

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

作者：彭文華

編輯：陶家龍

出處：轉(zhuǎn)載自公眾號大數(shù)據(jù)架構(gòu)師(ID：bigdata_arch)