今天我要批判中台！
我在阿里巴巴工作期間是一個(gè)名副其實(shí)的“刺頭”，批判中臺(tái)、批判架構(gòu)師、批判技術(shù)管理者，當(dāng)然，也包括自我批判。
今天就先聊聊批判中臺(tái)！
前些年，阿里巴巴提出了“大中臺(tái)、小前臺(tái)”戰(zhàn)略，在業(yè)界掀起了不小的波瀾，一時(shí)間，各種中臺(tái)建設(shè)的方法論和最佳實(shí)踐滿天飛。
中臺(tái)的底層邏輯是什么？中臺(tái)能帶來(lái)的價(jià)值到底是什么？
我們有必要用批判的眼光來(lái)審視一下中臺(tái)建設(shè)。
中臺(tái)的底層邏輯
中臺(tái)的底層邏輯，用一句話解釋就是通過復(fù)用提升研發(fā)效率。
建一所房子，首先要打地基、鋪鋼筋，然后往上一塊一塊地壘磚頭。沒辦法，原子世界就是這么物質(zhì)，一塊磚頭都少不了。軟件是比特世界，軟件開發(fā)很少是從買服務(wù)器開始的，特別是在云原生時(shí)代，云廠商通常已經(jīng)幫我們做好了“基建”的事情。IaaS是對(duì)算力、網(wǎng)絡(luò)、存儲(chǔ)、操作系統(tǒng)等基礎(chǔ)設(shè)施的復(fù)用，PaaS是對(duì)中間件的復(fù)用。
如圖1所示，基于這樣的演進(jìn)路徑，有沒有可能做一個(gè)Business-PaaS（業(yè)務(wù)中臺(tái)），提煉業(yè)務(wù)中具有共性的內(nèi)容，減輕前臺(tái)業(yè)務(wù)，提升研發(fā)效率呢？
圖1 ?業(yè)務(wù)中臺(tái)的位置
單看圖1，這個(gè)邏輯似乎是通的。于是，在“大中臺(tái)、小前臺(tái)”的旗幟下，業(yè)務(wù)中臺(tái)誕生了。可是不管是一線研發(fā)人員的反饋，還是高層人員的質(zhì)疑聲，都表明了業(yè)務(wù)中臺(tái)似乎并沒有解決問題，反而制造了更多的阻礙和困難，這是為什么呢？
業(yè)務(wù)中臺(tái)為何低效
中臺(tái)戰(zhàn)略沒有錯(cuò)，大中臺(tái)也沒有錯(cuò)，技術(shù)中臺(tái)、數(shù)據(jù)中臺(tái)都沒問題，為什么到業(yè)務(wù)中臺(tái)就出現(xiàn)問題了呢？我想問題就出在這個(gè)“業(yè)務(wù)”身上。
IaaS也好，PaaS也罷，之所以能提效，是因?yàn)槠渚哂袠I(yè)務(wù)無(wú)關(guān)性，它們和業(yè)務(wù)的邊界很清晰，彼此正交，互不干擾。IaaS?和?PaaS解決的是技術(shù)問題，業(yè)務(wù)解決的是業(yè)務(wù)問題。PaaS偶爾也會(huì)侵入業(yè)務(wù)應(yīng)用，為了與應(yīng)用隔離解耦，于是有了PandoraBoot、Service Mesh等技術(shù)。
業(yè)務(wù)中臺(tái)卻沒有這樣的“好命”，它解決的是復(fù)雜、多變的業(yè)務(wù)問題。如果你把鏡頭拉近一點(diǎn)看，會(huì)發(fā)現(xiàn)業(yè)務(wù)和業(yè)務(wù)中臺(tái)的關(guān)系并不是像我們理想的一樣在中間有一道清晰的邊界線，而是像圖2一樣，犬牙交錯(cuò)地耦合在一起。
圖2 ?業(yè)務(wù)和業(yè)務(wù)中臺(tái)的關(guān)系
前臺(tái)業(yè)務(wù)要借助業(yè)務(wù)中臺(tái)一起去完成業(yè)務(wù)邏輯，所以有一部分埋在了業(yè)務(wù)中臺(tái)里，至于埋得多深，則取決于使用中臺(tái)能力的多少，用得多就埋得深，用得少就埋得淺。
因此，用一句話來(lái)說(shuō)，業(yè)務(wù)中臺(tái)低效的根本原因在于，前臺(tái)業(yè)務(wù)和業(yè)務(wù)中臺(tái)的“深度單體耦合”。這種耦合性至少在以下3個(gè)方面嚴(yán)重影響了整體的研發(fā)效率。
1. 協(xié)作成本
研發(fā)≠寫代碼，實(shí)際上我們大部分時(shí)間不是在寫代碼，而是在溝通協(xié)調(diào)，況且與人打交道要比與機(jī)器打交道麻煩得多。這也是《人月神話》一書中說(shuō)“加人只會(huì)讓項(xiàng)目更糟糕”的原因，因?yàn)轭~外增加了更多的協(xié)作成本。
除了組織協(xié)作成本倍增，耦合帶來(lái)的工程協(xié)作成本也很高。試想一下：如果幾百名研發(fā)人員在同一個(gè)代碼庫(kù)上修改代碼并部署，會(huì)是怎樣的體驗(yàn)？
以下是一位同事的真實(shí)反饋：
“業(yè)務(wù)中臺(tái)在外面宣傳的是業(yè)務(wù)方7í24小時(shí)想發(fā)就發(fā)，實(shí)際遠(yuǎn)遠(yuǎn)做不到，很多限制，效率很低，體驗(yàn)過才知道。”
2. 認(rèn)知成本
就阿里巴巴的業(yè)務(wù)中臺(tái)體系來(lái)說(shuō)，不可謂不復(fù)雜，其中有大量的新概念——業(yè)務(wù)身份、活動(dòng)（Activity）、領(lǐng)域服務(wù)（Domain Service)、領(lǐng)域能力（Ability）、擴(kuò)展點(diǎn)（ExtensionPoint），擴(kuò)展實(shí)現(xiàn)（Extension）、奧創(chuàng)、Lattice、業(yè)務(wù)容器，等等。這些概念顯著增加了開發(fā)者的認(rèn)知負(fù)荷，讓系統(tǒng)變得異常復(fù)雜。
正如尼古拉斯所說(shuō)，
在現(xiàn)代生活中，簡(jiǎn)單的做法一直難以實(shí)現(xiàn)，因?yàn)樗羞`某些努力尋求復(fù)雜化以證明其工作合理性的人所秉持的精神。
3. 穩(wěn)定性成本
現(xiàn)在的業(yè)務(wù)中臺(tái)很精巧，同時(shí)也很脆弱。它與所有的大設(shè)計(jì)（Big design up front）犯了同一個(gè)錯(cuò)誤，即忽視了那些“對(duì)未知的未知（Unknow unknows）”。業(yè)務(wù)的靈活性和差異性導(dǎo)致我們很難提前抽象，因?yàn)槌橄笤跉w納之后，可是新的業(yè)務(wù)需求還沒出現(xiàn)。
理想的情況是我們能預(yù)見所有的業(yè)務(wù)變化，提前做抽象，預(yù)留所有的業(yè)務(wù)擴(kuò)展點(diǎn)，這樣針對(duì)不同的業(yè)務(wù)只需要在擴(kuò)展點(diǎn)中定制就好了。但沒人能預(yù)見未來(lái)，這樣就難免要改動(dòng)平臺(tái)代碼，比如加一個(gè)擴(kuò)展點(diǎn)。由于平臺(tái)代碼是被所有業(yè)務(wù)共享的，這就給穩(wěn)定性帶來(lái)了極大的隱患。比如，A業(yè)務(wù)改動(dòng)了平臺(tái)代碼，然而B業(yè)務(wù)什么也沒做就出了故障。
解決中臺(tái)的困境
為了解決上述業(yè)務(wù)中臺(tái)碰到的問題，我認(rèn)為可以嘗試做以下工作。
（1）把業(yè)務(wù)能力做薄。做薄是為了解耦，業(yè)務(wù)最懂自己，因此不要嘗試去“control”它們。中臺(tái)可以更多地關(guān)注與“業(yè)務(wù)無(wú)關(guān)”的能力建設(shè)，比如穩(wěn)定性、性能、監(jiān)控、運(yùn)維工具等非功能屬性。
（2）把中臺(tái)能力做強(qiáng)。除了非功能屬性，中臺(tái)還可以通過建設(shè)豐富的業(yè)務(wù)解決方案庫(kù)、業(yè)務(wù)組件庫(kù)等工具，賦能業(yè)務(wù)快速發(fā)展，用enable代替control。
（3）把系統(tǒng)結(jié)構(gòu)做簡(jiǎn)單。這一點(diǎn)很好理解，因?yàn)閺?fù)雜是萬(wàn)惡之源。
1. 解耦
協(xié)作成本和穩(wěn)定性問題都是由前臺(tái)業(yè)務(wù)和業(yè)務(wù)中臺(tái)的深度耦合造成的，因此，中臺(tái)這種集中式的代碼管控和部署的“大單體”模式亟需改變。解決方案顯而易見，解決“大”的問題的方法就是分而治之，解決“單體”的問題的方法就是服務(wù)化。
也就是說(shuō)，前臺(tái)業(yè)務(wù)和業(yè)務(wù)中臺(tái)的關(guān)系，必須從代碼和部署的耦合狀態(tài)變成分布式的服務(wù)關(guān)系，如圖3所示。就像BPaas這個(gè)名字所隱喻的一樣，讓業(yè)務(wù)中臺(tái)真正變成服務(wù)（Business Platform as a Service）。
圖3 ?業(yè)務(wù)和中臺(tái)解耦
解耦不難，關(guān)鍵是這一刀要從哪里切？我認(rèn)為這一刀可以切在“業(yè)務(wù)無(wú)關(guān)”這個(gè)界面上。
所謂“業(yè)務(wù)無(wú)關(guān)”，就是想辦法在業(yè)務(wù)中臺(tái)中找到和具體業(yè)務(wù)無(wú)關(guān)的內(nèi)核（kernel）。這樣既可以最大程度上復(fù)用中臺(tái)能力，又可以保持業(yè)務(wù)的靈活性。比如，所有的業(yè)務(wù)都需要對(duì)數(shù)據(jù)進(jìn)行增刪改查（CRUD）操作，這就是業(yè)務(wù)無(wú)關(guān)的，而業(yè)務(wù)的各種校驗(yàn)邏輯是業(yè)務(wù)相關(guān)的。
當(dāng)然，這個(gè)邊界具體放在哪里，還是要針對(duì)具體情況進(jìn)行具體分析，但結(jié)果肯定會(huì)比現(xiàn)在的業(yè)務(wù)中臺(tái)要薄。
例如對(duì)于商品業(yè)務(wù)，淘寶的商品、盒馬的商品、零售通的商品之間可能存在巨大的差異，它們的擴(kuò)展屬性和業(yè)務(wù)校驗(yàn)規(guī)則都不一樣。這種情況就適合把中臺(tái)做得很薄，讓其退化成EJB中的Entity Bean。這也是業(yè)務(wù)中臺(tái)的底線，即業(yè)務(wù)中臺(tái)要做統(tǒng)一的數(shù)據(jù)收口，防止產(chǎn)生數(shù)據(jù)孤島。
即使是薄中臺(tái)，也是極其有價(jià)值的，因?yàn)樗軒椭覀兘鉀Q商品的存儲(chǔ)、存儲(chǔ)擴(kuò)展、性能、穩(wěn)定性、工具（商品360、forest類目管控）、搜索構(gòu)建等一系列和業(yè)務(wù)無(wú)關(guān)的非功能屬性問題，這就足夠了。
但對(duì)于支付業(yè)務(wù)，情況可能會(huì)不一樣。支付的共性相對(duì)比較強(qiáng)，中臺(tái)可以做得厚一點(diǎn)。比如，對(duì)接不同的支付渠道、建設(shè)統(tǒng)一的支付網(wǎng)關(guān)等業(yè)務(wù)都存在支付的共性需求。
2. Platform as Code
簡(jiǎn)單不等于簡(jiǎn)陋，幫助業(yè)務(wù)快速發(fā)展的主要職責(zé)不能丟。
假如需要啟動(dòng)一個(gè)全新的業(yè)務(wù)，因?yàn)橹信_(tái)做薄了，之前在業(yè)務(wù)中臺(tái)沉淀的業(yè)務(wù)能力很多都釋放給業(yè)務(wù)自己了，中臺(tái)要怎么幫助快速搭建新業(yè)務(wù)呢？
這時(shí)可以考慮借鑒DevOps中的概念——IaC（Infrastructure as Code），這里暫時(shí)將它命名為PaC（Platform as Code）。
如圖4所示，可以由中臺(tái)的產(chǎn)品經(jīng)理（Product Designer，PD）和研發(fā)人員共同設(shè)計(jì)一個(gè)針對(duì)不同業(yè)務(wù)場(chǎng)景的中臺(tái)解決方案庫(kù)。
圖4 ?PaC中臺(tái)解決方案
具體的實(shí)現(xiàn)方式可以是用Maven的Archetype，并用版本的方式進(jìn)行迭代。這樣當(dāng)面對(duì)一個(gè)全新的業(yè)務(wù)時(shí)，業(yè)務(wù)方可以快速地通過Archetype生成一個(gè)實(shí)際可用的業(yè)務(wù)應(yīng)用，再由前端業(yè)務(wù)部署到自己的服務(wù)器集群中，按需修改完成自己的業(yè)務(wù)訴求即可上線。之后如有需求變更，業(yè)務(wù)就可以按照自己的意愿在自己的“一方樂土”上自由奔跑了。
實(shí)際上，重復(fù)（Duplication）也是一種重用（Reuse）。這樣做可能會(huì)導(dǎo)致不同的業(yè)務(wù)代碼之間出現(xiàn)一些代碼冗余（實(shí)際上，出于快速發(fā)展和穩(wěn)定性的考慮，有些業(yè)務(wù)已經(jīng)在采用重復(fù)代碼的方式，比如淘特、APOS）。然而，在穩(wěn)定性、可理解性、可維護(hù)性、工程效率的綜合權(quán)衡之下，這點(diǎn)代碼冗余會(huì)顯得微不足道。
正如Neal Ford在《軟件架構(gòu)》一書中提到，
當(dāng)一個(gè)架構(gòu)師設(shè)計(jì)一個(gè)系統(tǒng)的時(shí)候，他如果選擇重用，那么同時(shí)也選擇了耦合。因?yàn)橹赜貌还苁峭ㄟ^組合（Composition）還是繼承（Inheritance）實(shí)現(xiàn)，都會(huì)引入耦合。然而，如果你不想耦合，可以采用重復(fù)代替重用。
也就是說(shuō)，架構(gòu)需要在重用高耦合和重復(fù)低耦合之間做一個(gè)權(quán)衡，所以代碼重復(fù)（Ctrl+C/Ctrl+V）并不總是差的，而是一種設(shè)計(jì)選擇。
3. Platform as Code + 組件化
在PaC的基礎(chǔ)上，可以進(jìn)一步考慮組件化，即把一些共用的邏輯封裝成組件，打造一個(gè)“中臺(tái)組件庫(kù)”，如圖5所示。業(yè)務(wù)可以按需組合這些組件去實(shí)現(xiàn)業(yè)務(wù)，同時(shí)，業(yè)務(wù)也可以把自己沉淀的組件“反哺”給組件庫(kù)，形成一個(gè)良性循環(huán)的“大集市”——好的組件會(huì)被大量使用、迭代和演化，不好的組件會(huì)被逐漸淘汰。
圖5 ?PaC+組件化的中臺(tái)解決方案
然而，業(yè)務(wù)具有易變、不確定、復(fù)雜和模糊性（Volatility Uncertainty Complexity Ambiguity，VUCA），很難標(biāo)準(zhǔn)化，如何設(shè)計(jì)組件并讓組件和業(yè)務(wù)之間松耦合——即不要讓組件綁架業(yè)務(wù)，困住業(yè)務(wù)的手腳，將是一個(gè)極大的挑戰(zhàn)。這也是我在一開始提出PaC的時(shí)候，沒有提組件化的原因。
本文節(jié)選自《程序員的底層思維》一書，想要了解更多相關(guān)內(nèi)容，歡迎閱讀本書！
▊ 《程序員的底層思維》
張建飛 著
這是一本超越具體編程技法的技術(shù)書：職場(chǎng)晉升不僅需要技術(shù)能力，更重要的是思維能力。本書帶你學(xué)會(huì)用底層思維解決復(fù)雜技術(shù)問題，突破職場(chǎng)“天花板”。
這也是一本培養(yǎng)思維能力的通用技能書：打破認(rèn)知局限，培養(yǎng)通用的思維能力。本書幫你跳出思維定勢(shì)，輕松解決生活及工作中遇到的問題。
本書涵蓋程序員應(yīng)知應(yīng)會(huì)的16種思維能力，共18章，分為三部分。
第一部分主要介紹抽象思維、邏輯思維、結(jié)構(gòu)化思維、批判性思維、維度思維、分類思維、分治思維、簡(jiǎn)單思維，以及成長(zhǎng)型思維等解決日常問題的基礎(chǔ)思維能力。
第二部分結(jié)合軟件行業(yè)的特點(diǎn)，主要介紹解耦思維、契約思維、模型思維、工具化思維、量化思維、數(shù)據(jù)思維，以及產(chǎn)品思維等專業(yè)思維能力。
第三部分主要是對(duì)上述思維能力的綜合運(yùn)用實(shí)踐。
粉絲專享六折優(yōu)惠，掃碼即購(gòu)！
如果喜歡本文 歡迎?在看丨留言丨分享至朋友圈?三連往期推薦
今天我要批判技術(shù)管理者
Apache架構(gòu)師的30條設(shè)計(jì)原則！
今天我要批判架構(gòu)師
成為優(yōu)秀軟件工程師的三條路徑
好代碼和壞代碼
漫畫：如何用 K8s 實(shí)現(xiàn) CI/CD 發(fā)布流程？
史海峰：我的架構(gòu)師修煉之道
一年之計(jì)：如何構(gòu)建知識(shí)體系？
創(chuàng)業(yè)公司是如何進(jìn)行研發(fā)管理和績(jī)效考核的？
圖勝千言：電商支付架構(gòu)設(shè)計(jì)
總結(jié)
- 上一篇： NYOJ 920 Trees
- 下一篇： POJ 3628 Bookshelf 2