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

[[338746]]

 

圖片來自 Pexels

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

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

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

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

信息系統(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ī)時(shí)代，所有的軟件架構(gòu)都是單體架構(gòu)。當(dāng)時(shí)流行的架構(gòu)區(qū)分為 C/S 架構(gòu)和 B/S 架構(gòu)。

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

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

如下圖所示：

 

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

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

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

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

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

分層架構(gòu)

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

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

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)行拆分，每個(gè)模塊提供一個(gè)單獨(dú)的服務(wù)，可以拆成用戶服務(wù)、商品服務(wù)和訂單服務(wù)。

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

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

 

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

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

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

 

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

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

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

 

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

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

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

 

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

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

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

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

還真可以。

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

 

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

中臺(tái)架構(gòu)

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

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

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

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

 

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

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

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

 

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

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

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

作者：彭文華

編輯：陶家龍

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