。

這篇文章主要講解了“”，文中的講解內(nèi)容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“”吧！

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

圖片來自 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)，卻在不斷的進化。從最早的單體架構(gòu)到最新的云原生架構(gòu)，都是為了應對不斷復雜的需求和爆發(fā)式增長的數(shù)據(jù)。

OK，Let's Go!

單體架構(gòu)

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

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

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

如下圖所示：

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

• 怎么支持超多超復雜的業(yè)務啊?

• 擴展性怎么做?

• 怎么解決復用的問題?

• 耦合太緊，一旦出問題就全部完蛋，怎么辦?

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

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

• 開發(fā)簡單

• 測試簡單

• 部署簡單

分層架構(gòu)

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

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

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

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

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

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

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

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

微服務架構(gòu)

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

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

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

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

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

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

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

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

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

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

• 每個微服務可能會用不同語言的不同版本。

• 有太多的基礎框架和工具需要學習。

• 所有的 client、server 都需要維護 n 個版本。

• 上下游需要同步升級，否則你懂的。

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

還真可以。

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

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

中臺架構(gòu)

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

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

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

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

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

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

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

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

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

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

感謝各位的閱讀，以上就是“”的內(nèi)容了，經(jīng)過本文的學習后，相信大家對這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關(guān)知識點的文章，歡迎關(guān)注！