有一個事情已經困擾我很久了——大中臺、小前臺作爲戰略已經提出很久了，在業界也掀起了不小的波瀾，可是反觀阿里的業務中臺，爲什麼總覺得旁邊有朵小烏雲，感覺哪裏不對勁。
業務中臺小烏雲
建一所房子，你要挖坑打地基，鋪鋼筋，然後一塊磚頭一塊磚頭的往上磊。沒辦法，原子世界就是這麼物質，一塊磚頭都少不了。軟件是比特世界，軟件開發很少是從買服務器開始，特別是在這個Cloud Native的時代，很多基建的事情雲廠商都已經幫我們做好了。IaaS是對算力、網絡、存儲、操作系統等基礎設施的複用；PaaS是對中間件的複用；
基於這樣的演進路徑，有沒有可能做一個Business-PaaS（業務中臺）， 提煉出業務共性的東西，讓前臺業務少做點事情，提升研發效率呢？
單看上面的圖示，這個邏輯似乎是通的。於是乎，在“大中臺、小前臺”的大旗幟下，星環誕生了。可是不管是從一線研發同學的反饋，還是高層的質疑聲，都在表明星環似乎並沒有解決問題，反而是製造了更多的阻礙、困難，這是爲什麼呢？
業務中臺的困境
中臺戰略沒有錯，大中臺也沒有錯，什麼技術中臺、數據中臺都沒問題，爲什麼到業務中臺就有問題了呢？我想問題就出在這個“業務”身上。
IaaS也好，PaaS也罷，之所以能提效是因爲其業務無關性，它們和業務的邊界很清晰，彼此正交，互不干擾。IaaS、PaaS解決的是技術問題，業務解決的是業務問題。（偶爾PaaS也會侵入業務應用，爲了與應用隔離解耦，於是有了PandoraBoot、Service Mesh等技術）
業務中臺卻沒有這樣的好命，它解決的是複雜、多變的業務問題，如果你拉近距離看業務和業務中臺的關係，就會發現，他們並不像上圖描繪的那樣，中間有一道清晰的邊界線，而是犬牙交錯的耦合在一起：
前臺業務要藉助業務中臺一起去完成業務邏輯，所以是有一部分埋在業務中臺裏的，至於埋得有多深，取決於使用中臺能力的多少，用的多就埋的深，用的少就埋的淺。
因此，業務中臺低效的根因，用一句話來說，就是因爲前臺業務和業務中臺的“深度單體耦合”。這種耦合性，至少在三個方面嚴重影響了整體的研發效率：
協作成本
研發≠寫代碼，實際上我們大部分時間不是在寫代碼，而是在溝通協調上。而且跟人打交道要比跟機器打交道要麻煩的多。這也是爲什麼《人月神話》中會說加人只會讓項目更糟糕的原因，因爲你額外增加了更多的協作成本。
因爲中颱的深度介入業務，導致組織協作成本倍增，詳細分析可以參看 複雜組織下協作成本倍增的起因、影響及可能的解
除了組織協作成本倍增之外，因爲耦合帶來的工程協作成本也很高，試想一下如果幾百個研發人員在同一個代碼庫上修改代碼、部署，會是怎樣的體驗。
以下是一個同學的真實反饋：
“星環在外面宣傳的是業務方7*24想發就發，實際遠遠做不到，很多限制，效率很低，體驗過才知道多噁心。”
認知成本
整個星環體系不可謂不復雜，裏面有一堆的新概念——業務身份、活動（Activity）、領域服務（Domain Service)、領域能力（Ability）、擴展點（ExtensionPoint），擴展實現（Extension）、奧創、Lattice、業務容器...
通過下面新人的日報片段，可以感受下其高昂的認知成本。
KISS是一種美德，正如尼古拉斯所說：
“在現代生活中，簡單的做法一直難以實現，因爲它有違某些努力尋求複雜化以證明其工作合理性的人所秉持的精神。”
穩定性成本
《反脆弱》裏說：越是精巧的東西越脆弱。
現在的業務中臺很精巧，同時也很脆弱。跟所有的“Big design up front”犯了同一個錯誤，即忽視了unknow unkowns。業務的靈活性、差異性，導致我們很難提前抽象，因爲抽象是歸納之後的抽象，可是新的業務需求還沒出現，你讓我怎麼歸納，怎麼抽象？
理想的情況是我能預見所有的業務變化，提前做抽象，把所有的業務擴展點都預留好，這樣不同的業務只需要在擴展點中定製就好了。但沒人能預見未來，難免會動到平臺代碼，加一個擴展點啥的，因爲平臺代碼是被所有業務共享的，這就給穩定性帶來了極大隱患。會出現A業務改了平臺代碼，B業務啥事也沒做，就出了故障。
這就是爲什麼對穩定性要求比較高的業務場景，比如APOS，寧願冗餘代碼，也不願被動出故障。實際上，代碼冗餘（Repeat）也是一種代碼複用（Reuse），在很多情景下，Repeat是解耦更徹底，更簡單高效的做法。比如在寫測試代碼的時候，用copy-paste的方式去準備測試數據就是很好的解耦方式，通過代碼的Repeat，可以更好的隔離不同test case之間的相互影響。
總之，在精巧的、不穩定的複用和簡單、高效的重複之間，後者會是一個不錯的選擇。軟件架構無其他，只是權衡（trade-off）。DRY（Dont Repeat Yourself）和Decoupling（解耦）都是對的，選擇哪種方案，應該是仔細權衡後的選擇，而不應該是“拍腦袋”或基於”屁股“的選擇。
可能的解決方案
針對上面的問題，如果讓我來重新設計業務中臺的話，我會嘗試做以下事情：
- 把業務能力做薄。做薄是爲了解耦，業務自己最懂自己的業務，不要嘗試去control他們，放過他們，也放過自己。中臺可以更多的關注在“業務無關”的能力建設上，比如穩定性、性能、監控、運維工具等非功能屬性。
- 把中臺能力做強。除了非功能屬性，中臺還可以通過建設豐富的業務解決方案庫、業務組件庫等工具，賦能業務快速發展，用enable代替control。
- 把系統結構做簡單。複雜是萬惡之源，星環太精巧了。
解耦
協作成本、穩定性問題皆是因爲前臺業務和業務中臺的深度耦合造成的。因此，星環的這種集中式的代碼管控和部署的“大單體”模式亟需得到解決。
其實解決方案大家都知道，解決“大”的問題就是分而治之，解決“單體”的問題就是服務化。
也就是說，前臺業務和業務中臺的關係，必須從代碼和部署的耦合狀態，變成分佈式的服務關係，就像BPass這個名字所隱喻的一樣，讓業務中臺真正變成服務（Business Platform as a Service）。
解耦不難，關鍵是這一刀要從哪裏切？我個人認爲這一刀可以切在“業務無關”這個切面上。
所謂的“業務無關”就是想辦法在業務中臺中找到和具體業務無關的內核（kernel）。這樣可以最大程度的複用中臺能力，又可以保持業務的靈活性。比如所有的業務都需要對數據進行CRUD操作，這個就是業務無關的，而業務的各種校驗邏輯就是業務相關的。
當然，這個邊界具體放在哪，還是要具體情況具體對待，但是肯定會比現在的業務中臺要薄。
舉兩個例子，比較合理的方式可能會像這樣：
- 商品業務：同樣是電商業務，但是淘寶的商品、盒馬的商品、零售通的商品之間可能存在巨大的差異。他們的擴展屬性不一樣，業務校驗規則也不一樣。這種情況就適合把中臺做得很薄，讓其退化成EJB中的Entity Bean。這也是業務中臺的底線，即業務中臺要做統一的數據收口，防止數據孤島。
然而，即使是這樣的薄中臺也是極其有價值的，因爲它幫助我解決商品的存儲、存儲擴展、性能、穩定性、工具（商品360、forest類目管控）、搜索構建等一些列和業務無關的非功能屬性問題。說實話，這就足夠了。
- 支付業務：支付業務的細節我不是特別清楚，但感覺在這裏業務中臺可以做得厚一點，因爲像對接不同的支付渠道，建設統一的支付網關，很多業務都是存在這樣的共性需求的。
簡單
通過上面的解耦工作之後，星環這一套基本就可以deprecate掉了，因爲業務中臺只會保留“業務無關”的通用原子服務，自然也就不需要那套擴展機制了。
於此同時，因爲前臺業務和業務中臺從之前的星環耦合關係，變成簡單的服務調用關係、組件組合關係，系統的複雜度和認知成本也會極大的改善。這樣前臺和中臺的同學就都解放了。
我相信，如果能按照這種“業務的歸業務，中臺的歸中臺”簡單設計，邊界清晰，職責清晰。不同BU的業務的演變、部署都在自己的掌控中，彼此正交、互不干擾，便可以極大的提升業務團隊和中臺團隊的研發效能。
Platform as Code
簡單不等於簡陋，幫助業務快速奔跑的職責不能丟。
假如有這樣一個場景，一個全新的業務需要啓動，因爲中颱做薄了，之前在業務中臺沉澱的業務能力很多都釋放給業務自己了，中臺要怎麼幫助新業務快速搭建呢？
這裏可以考慮借鑑DevOps裏的IaC（Infrastructure as Code）的概念，我暫時給它起個名字叫PaC（Platform as Code）。
如下圖所示，可以由中臺的PD、研發同學設計一個針對不同業務場景的業務解決方案庫。
具體的實現方式可以是Maven的Archetype，並用版本的方式進行迭代，這樣針對一個全新的業務，業務方可以快速的通過Archetype，生成一個functional的業務應用。再由前端業務部署到自己的服務器集羣，按需修改完成自己的業務訴求上線即可。之後需求變更時，業務方便可以按照自己的意願，在自己的“一方樂土”上自由奔跑了。
實際上這也是一種Reuse（重用），只不過是用代碼Repeat（重複）的方式在重用。這樣做，可能會導致不同的業務代碼之間出現一些代碼冗餘（實際上，有些業務爲了快速發展、穩定性的考慮，已經在採用copy代碼的方式，比如陶特、APOS）。但是請相信我，這點代碼冗餘，在穩定性、可理解性、可維護性、工程效率的綜合權衡之下，會顯得微不足道。
正如《Fundamentals of Software Architecture》一書中所說：“There is no best architecture, but the least worst architecture"。
Platform as Code + 組件庫
在PaC的基礎之上，再進一步，可以考慮組件化，即把一些共用的邏輯封裝成組件，打造一個“中臺組件庫”，業務可以按需組合這些組件去實現業務，同時，業務也可以把自己沉澱的組件反哺給“組件庫”，形成一個良性循環的“大集市”：好的組件會被大量使用、迭代和演化。不好的組件會被冷落，躺平。
然而，還是那句話，業務是VUCA（Volatility Uncertainty Complexity Ambiguity）的，很難標準化，如何設計組件，如何讓組件和業務之間松耦合——即不要讓組件綁架業務，困住業務的手腳，將會是一個蠻大的挑戰，需要一些智慧。這也是爲什麼我一開始提出PaC的時候，沒有提組件化的原因。
總之，不管是PaC也好，還是PaC+組件化也好。大的方向都是把“中臺大單體”給拆了，讓業務迴歸業務本身，讓業務和中臺解耦，讓中臺更純粹，讓業務更靈動，讓同學更幸福！
作者：技術匠人
鏈接：https://www.toutiao.com/a6979126309251400228/?log_from=fc1991371deb4_1627024992982