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