我在阿里巴巴工作期間是一個名副其實的“刺頭”，批判中臺、批判架構(gòu)師、批判技術(shù)管理者，當然，也包括自我批判。

今天就先聊聊批判中臺！

前些年，阿里巴巴提出了“大中臺、小前臺”戰(zhàn)略，在業(yè)界掀起了不小的波瀾，一時間，各種中臺建設(shè)的方法論和最佳實踐滿天飛。

中臺的底層邏輯是什么？中臺能帶來的價值到底是什么？

我們有必要用批判的眼光來審視一下中臺建設(shè)。

中臺的底層邏輯

中臺的底層邏輯，用一句話解釋就是通過復(fù)用提升研發(fā)效率。

建一所房子，首先要打地基、鋪鋼筋，然后往上一塊一塊地壘磚頭。沒辦法，原子世界就是這么物質(zhì)，一塊磚頭都少不了。軟件是比特世界，軟件開發(fā)很少是從買服務(wù)器開始的，特別是在云原生時代，云廠商通常已經(jīng)幫我們做好了“基建”的事情。IaaS是對算力、網(wǎng)絡(luò)、存儲、操作系統(tǒng)等基礎(chǔ)設(shè)施的復(fù)用，PaaS是對中間件的復(fù)用。

如圖1所示，基于這樣的演進路徑，有沒有可能做一個Business-PaaS（業(yè)務(wù)中臺），提煉業(yè)務(wù)中具有共性的內(nèi)容，減輕前臺業(yè)務(wù)，提升研發(fā)效率呢？

圖1 ?業(yè)務(wù)中臺的位置

單看圖1，這個邏輯似乎是通的。于是，在“大中臺、小前臺”的旗幟下，業(yè)務(wù)中臺誕生了。可是不管是一線研發(fā)人員的反饋，還是高層人員的質(zhì)疑聲，都表明了業(yè)務(wù)中臺似乎并沒有解決問題，反而制造了更多的阻礙和困難，這是為什么呢？

業(yè)務(wù)中臺為何低效

中臺戰(zhàn)略沒有錯，大中臺也沒有錯，技術(shù)中臺、數(shù)據(jù)中臺都沒問題，為什么到業(yè)務(wù)中臺就出現(xiàn)問題了呢？我想問題就出在這個“業(yè)務(wù)”身上。

IaaS也好，PaaS也罷，之所以能提效，是因為其具有業(yè)務(wù)無關(guān)性，它們和業(yè)務(wù)的邊界很清晰，彼此正交，互不干擾。IaaS?和?PaaS解決的是技術(shù)問題，業(yè)務(wù)解決的是業(yè)務(wù)問題。PaaS偶爾也會侵入業(yè)務(wù)應(yīng)用，為了與應(yīng)用隔離解耦，于是有了PandoraBoot、Service Mesh等技術(shù)。

業(yè)務(wù)中臺卻沒有這樣的“好命”，它解決的是復(fù)雜、多變的業(yè)務(wù)問題。如果你把鏡頭拉近一點看，會發(fā)現(xiàn)業(yè)務(wù)和業(yè)務(wù)中臺的關(guān)系并不是像我們理想的一樣在中間有一道清晰的邊界線，而是像圖2一樣，犬牙交錯地耦合在一起。

圖2 ?業(yè)務(wù)和業(yè)務(wù)中臺的關(guān)系

前臺業(yè)務(wù)要借助業(yè)務(wù)中臺一起去完成業(yè)務(wù)邏輯，所以有一部分埋在了業(yè)務(wù)中臺里，至于埋得多深，則取決于使用中臺能力的多少，用得多就埋得深，用得少就埋得淺。

因此，用一句話來說，業(yè)務(wù)中臺低效的根本原因在于，前臺業(yè)務(wù)和業(yè)務(wù)中臺的“深度單體耦合”。這種耦合性至少在以下3個方面嚴重影響了整體的研發(fā)效率。

1. 協(xié)作成本

研發(fā)≠寫代碼，實際上我們大部分時間不是在寫代碼，而是在溝通協(xié)調(diào)，況且與人打交道要比與機器打交道麻煩得多。這也是《人月神話》一書中說“加人只會讓項目更糟糕”的原因，因為額外增加了更多的協(xié)作成本。

除了組織協(xié)作成本倍增，耦合帶來的工程協(xié)作成本也很高。試想一下：如果幾百名研發(fā)人員在同一個代碼庫上修改代碼并部署，會是怎樣的體驗？

以下是一位同事的真實反饋：

“業(yè)務(wù)中臺在外面宣傳的是業(yè)務(wù)方7í24小時想發(fā)就發(fā)，實際遠遠做不到，很多限制，效率很低，體驗過才知道。”

2. 認知成本

就阿里巴巴的業(yè)務(wù)中臺體系來說，不可謂不復(fù)雜，其中有大量的新概念——業(yè)務(wù)身份、活動（Activity）、領(lǐng)域服務(wù)（Domain Service)、領(lǐng)域能力（Ability）、擴展點（ExtensionPoint），擴展實現(xiàn)（Extension）、奧創(chuàng)、Lattice、業(yè)務(wù)容器，等等。這些概念顯著增加了開發(fā)者的認知負荷，讓系統(tǒng)變得異常復(fù)雜。

正如尼古拉斯所說，

在現(xiàn)代生活中，簡單的做法一直難以實現(xiàn)，因為它有違某些努力尋求復(fù)雜化以證明其工作合理性的人所秉持的精神。

3. 穩(wěn)定性成本

現(xiàn)在的業(yè)務(wù)中臺很精巧，同時也很脆弱。它與所有的大設(shè)計（Big design up front）犯了同一個錯誤，即忽視了那些“對未知的未知（Unknow unknows）”。業(yè)務(wù)的靈活性和差異性導(dǎo)致我們很難提前抽象，因為抽象在歸納之后，可是新的業(yè)務(wù)需求還沒出現(xiàn)。

理想的情況是我們能預(yù)見所有的業(yè)務(wù)變化，提前做抽象，預(yù)留所有的業(yè)務(wù)擴展點，這樣針對不同的業(yè)務(wù)只需要在擴展點中定制就好了。但沒人能預(yù)見未來，這樣就難免要改動平臺代碼，比如加一個擴展點。由于平臺代碼是被所有業(yè)務(wù)共享的，這就給穩(wěn)定性帶來了極大的隱患。比如，A業(yè)務(wù)改動了平臺代碼，然而B業(yè)務(wù)什么也沒做就出了故障。

解決中臺的困境

為了解決上述業(yè)務(wù)中臺碰到的問題，我認為可以嘗試做以下工作。

（1）把業(yè)務(wù)能力做薄。做薄是為了解耦，業(yè)務(wù)最懂自己，因此不要嘗試去“control”它們。中臺可以更多地關(guān)注與“業(yè)務(wù)無關(guān)”的能力建設(shè)，比如穩(wěn)定性、性能、監(jiān)控、運維工具等非功能屬性。

（2）把中臺能力做強。除了非功能屬性，中臺還可以通過建設(shè)豐富的業(yè)務(wù)解決方案庫、業(yè)務(wù)組件庫等工具，賦能業(yè)務(wù)快速發(fā)展，用enable代替control。

（3）把系統(tǒng)結(jié)構(gòu)做簡單。這一點很好理解，因為復(fù)雜是萬惡之源。

1. 解耦

協(xié)作成本和穩(wěn)定性問題都是由前臺業(yè)務(wù)和業(yè)務(wù)中臺的深度耦合造成的，因此，中臺這種集中式的代碼管控和部署的“大單體”模式亟需改變。解決方案顯而易見，解決“大”的問題的方法就是分而治之，解決“單體”的問題的方法就是服務(wù)化。

也就是說，前臺業(yè)務(wù)和業(yè)務(wù)中臺的關(guān)系，必須從代碼和部署的耦合狀態(tài)變成分布式的服務(wù)關(guān)系，如圖3所示。就像BPaas這個名字所隱喻的一樣，讓業(yè)務(wù)中臺真正變成服務(wù)（Business Platform as a Service）。

圖3 ?業(yè)務(wù)和中臺解耦

解耦不難，關(guān)鍵是這一刀要從哪里切？我認為這一刀可以切在“業(yè)務(wù)無關(guān)”這個界面上。

所謂“業(yè)務(wù)無關(guān)”，就是想辦法在業(yè)務(wù)中臺中找到和具體業(yè)務(wù)無關(guān)的內(nèi)核（kernel）。這樣既可以最大程度上復(fù)用中臺能力，又可以保持業(yè)務(wù)的靈活性。比如，所有的業(yè)務(wù)都需要對數(shù)據(jù)進行增刪改查（CRUD）操作，這就是業(yè)務(wù)無關(guān)的，而業(yè)務(wù)的各種校驗邏輯是業(yè)務(wù)相關(guān)的。

當然，這個邊界具體放在哪里，還是要針對具體情況進行具體分析，但結(jié)果肯定會比現(xiàn)在的業(yè)務(wù)中臺要薄。

例如對于商品業(yè)務(wù)，淘寶的商品、盒馬的商品、零售通的商品之間可能存在巨大的差異，它們的擴展屬性和業(yè)務(wù)校驗規(guī)則都不一樣。這種情況就適合把中臺做得很薄，讓其退化成EJB中的Entity Bean。這也是業(yè)務(wù)中臺的底線，即業(yè)務(wù)中臺要做統(tǒng)一的數(shù)據(jù)收口，防止產(chǎn)生數(shù)據(jù)孤島。

即使是薄中臺，也是極其有價值的，因為它能幫助我們解決商品的存儲、存儲擴展、性能、穩(wěn)定性、工具（商品360、forest類目管控）、搜索構(gòu)建等一系列和業(yè)務(wù)無關(guān)的非功能屬性問題，這就足夠了。

但對于支付業(yè)務(wù)，情況可能會不一樣。支付的共性相對比較強，中臺可以做得厚一點。比如，對接不同的支付渠道、建設(shè)統(tǒng)一的支付網(wǎng)關(guān)等業(yè)務(wù)都存在支付的共性需求。

2. Platform as Code

簡單不等于簡陋，幫助業(yè)務(wù)快速發(fā)展的主要職責(zé)不能丟。

假如需要啟動一個全新的業(yè)務(wù)，因為中臺做薄了，之前在業(yè)務(wù)中臺沉淀的業(yè)務(wù)能力很多都釋放給業(yè)務(wù)自己了，中臺要怎么幫助快速搭建新業(yè)務(wù)呢？

這時可以考慮借鑒DevOps中的概念——IaC（Infrastructure as Code），這里暫時將它命名為PaC（Platform as Code）。

如圖4所示，可以由中臺的產(chǎn)品經(jīng)理（Product Designer，PD）和研發(fā)人員共同設(shè)計一個針對不同業(yè)務(wù)場景的中臺解決方案庫。

圖4 ?PaC中臺解決方案

具體的實現(xiàn)方式可以是用Maven的Archetype，并用版本的方式進行迭代。這樣當面對一個全新的業(yè)務(wù)時，業(yè)務(wù)方可以快速地通過Archetype生成一個實際可用的業(yè)務(wù)應(yīng)用，再由前端業(yè)務(wù)部署到自己的服務(wù)器集群中，按需修改完成自己的業(yè)務(wù)訴求即可上線。之后如有需求變更，業(yè)務(wù)就可以按照自己的意愿在自己的“一方樂土”上自由奔跑了。

實際上，重復(fù)（Duplication）也是一種重用（Reuse）。這樣做可能會導(dǎo)致不同的業(yè)務(wù)代碼之間出現(xiàn)一些代碼冗余（實際上，出于快速發(fā)展和穩(wěn)定性的考慮，有些業(yè)務(wù)已經(jīng)在采用重復(fù)代碼的方式，比如淘特、APOS）。然而，在穩(wěn)定性、可理解性、可維護性、工程效率的綜合權(quán)衡之下，這點代碼冗余會顯得微不足道。

正如Neal Ford在《軟件架構(gòu)》一書中提到，

當一個架構(gòu)師設(shè)計一個系統(tǒng)的時候，他如果選擇重用，那么同時也選擇了耦合。因為重用不管是通過組合（Composition）還是繼承（Inheritance）實現(xiàn)，都會引入耦合。然而，如果你不想耦合，可以采用重復(fù)代替重用。

也就是說，架構(gòu)需要在重用高耦合和重復(fù)低耦合之間做一個權(quán)衡，所以代碼重復(fù)（Ctrl+C/Ctrl+V）并不總是差的，而是一種設(shè)計選擇。

3. Platform as Code + 組件化

在PaC的基礎(chǔ)上，可以進一步考慮組件化，即把一些共用的邏輯封裝成組件，打造一個“中臺組件庫”，如圖5所示。業(yè)務(wù)可以按需組合這些組件去實現(xiàn)業(yè)務(wù)，同時，業(yè)務(wù)也可以把自己沉淀的組件“反哺”給組件庫，形成一個良性循環(huán)的“大集市”——好的組件會被大量使用、迭代和演化，不好的組件會被逐漸淘汰。

圖5 ?PaC+組件化的中臺解決方案

然而，業(yè)務(wù)具有易變、不確定、復(fù)雜和模糊性（Volatility Uncertainty Complexity Ambiguity，VUCA），很難標準化，如何設(shè)計組件并讓組件和業(yè)務(wù)之間松耦合——即不要讓組件綁架業(yè)務(wù)，困住業(yè)務(wù)的手腳，將是一個極大的挑戰(zhàn)。這也是我在一開始提出PaC的時候，沒有提組件化的原因。

本文節(jié)選自《程序員的底層思維》一書，想要了解更多相關(guān)內(nèi)容，歡迎閱讀本書！

▊ 《程序員的底層思維》

張建飛 著

• 這是一本超越具體編程技法的技術(shù)書：職場晉升不僅需要技術(shù)能力，更重要的是思維能力。本書帶你學(xué)會用底層思維解決復(fù)雜技術(shù)問題，突破職場“天花板”。

• 這也是一本培養(yǎng)思維能力的通用技能書：打破認知局限，培養(yǎng)通用的思維能力。本書幫你跳出思維定勢，輕松解決生活及工作中遇到的問題。

本書涵蓋程序員應(yīng)知應(yīng)會的16種思維能力，共18章，分為三部分。

第一部分主要介紹抽象思維、邏輯思維、結(jié)構(gòu)化思維、批判性思維、維度思維、分類思維、分治思維、簡單思維，以及成長型思維等解決日常問題的基礎(chǔ)思維能力。

第二部分結(jié)合軟件行業(yè)的特點，主要介紹解耦思維、契約思維、模型思維、工具化思維、量化思維、數(shù)據(jù)思維，以及產(chǎn)品思維等專業(yè)思維能力。

第三部分主要是對上述思維能力的綜合運用實踐。

粉絲專享六折優(yōu)惠，掃碼即購！

如果喜歡本文 歡迎?在看丨留言丨分享至朋友圈?三連

往期推薦

今天我要批判技術(shù)管理者

Apache架構(gòu)師的30條設(shè)計原則！

今天我要批判架構(gòu)師

成為優(yōu)秀軟件工程師的三條路徑

好代碼和壞代碼

漫畫：如何用 K8s 實現(xiàn) CI/CD 發(fā)布流程？

史海峰：我的架構(gòu)師修煉之道

一年之計：如何構(gòu)建知識體系？

創(chuàng)業(yè)公司是如何進行研發(fā)管理和績效考核的？

圖勝千言：電商支付架構(gòu)設(shè)計

總結(jié)

以上是生活随笔為你收集整理的今天我要批判中台！的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。