中臺框架之困
中臺討論了好幾年，我自己之前研究中臺或參與中臺建設也有近兩年的時間了，那中臺那一套方法論還香嗎？
很多公司、團隊引入中臺的目的無外乎兩個：降本增效+業(yè)務創(chuàng)新。
那中臺究竟怎么和這兩件事產(chǎn)生關(guān)系的呢？
我們首先看第一個問題，和降本增效的關(guān)系。
我們可以想象下，影響整體研發(fā)效率的原因有哪些呢？
一、協(xié)作成本
研發(fā)不等于寫代碼，實際上我們交付一個需求的大部分時間不是在寫代碼，而是在溝通和協(xié)調(diào)上，跟人打交道的時間遠遠大于跟機器打交道的時間。
如果中臺深度介入到業(yè)務側(cè)系統(tǒng)太多，會導致協(xié)作成本增加。同時過度的工程耦合進一步帶來協(xié)作成本的增加。
星環(huán)是阿里中臺2.0的解決方案，一些業(yè)務同學反應過星環(huán)的問題：
星環(huán)對外宣稱業(yè)務方可以7*24小時想發(fā)就發(fā)，事實上遠遠做不到，有很多限制，效率也很低，只有體驗過才知道多惡心。
二、認知成本
使用星環(huán)效率低的另一個原因，是需要巨大的認知成本。
星環(huán)里面有一堆新概念：業(yè)務身份、活動、領域服務、領域能力、擴展點、擴展實現(xiàn)、奧創(chuàng)、Lattice、業(yè)務容器等。
研發(fā)同學的體感可能是這樣的：
改動的代碼其實不多，但中間會遇到很多問題
星環(huán)上接口特別多，注釋不是很明確，找到確定的接入點比較困難
buy2對外暴露的接口的參數(shù)、切入點的參數(shù)、調(diào)用其他系統(tǒng)接口的參數(shù)，在文檔上面沒有明確的關(guān)系關(guān)聯(lián)，尋找關(guān)聯(lián)關(guān)系比較困難
切入點的入?yún)⒑芏?/span>是字符串格式，并且參數(shù)眾多，是否所有參數(shù)都需要有值，都是一個未知數(shù)
營銷側(cè)希望把值添加在指定字段上，但找了半天沒找到合適的擴展點
代碼編譯時間很長、單元測試跑半天還是有很多沒跑通
在現(xiàn)代生活中，其實簡單一直是很難實現(xiàn)，因為很多人尋求用復雜的方式做事，證明其工作的合理性和自己的努力。
三、穩(wěn)定性成本
《反脆弱》里說：越是精巧的東西越脆弱。
現(xiàn)在業(yè)務中臺往往設計的很巧妙，但也證明了其背后的脆弱性。
架構(gòu)是對現(xiàn)實業(yè)務的映射。但現(xiàn)實中業(yè)務是靈活的、有差異的，我們很難提前進行歸納、抽象。因為歸納、抽象是建立在現(xiàn)狀之上的，沒有現(xiàn)狀談何抽象。
同時由于平臺代碼是被所有業(yè)務共享的，這就給穩(wěn)定性帶來極大的隱患，可能出現(xiàn)A改了代碼，導致B掛了。
冗余代碼是一種解決這種穩(wěn)定性問題的方式，通過冗余代碼實現(xiàn)更好的隔離，兩者互不影響。
但在復用、成本、穩(wěn)定性之間權(quán)衡取舍出一種解決方案就非常考驗技術(shù)能力。
中臺之變
怎么讓業(yè)務中臺避免以上問題呢？
協(xié)作成本與穩(wěn)定性問題之所以出現(xiàn)，是因為前臺與中臺之間的深度耦合造成的。
星環(huán)這種集中式的代碼控制和部署的大單體模式急需解決。
解決“大”這種問題，最好的方式就是分而治之，也就是讓其服務化。
可以讓前臺與中臺的關(guān)系，從代碼與部署的耦合狀態(tài)，變?yōu)榉植际降姆贞P(guān)系。
可以嘗試以下幾類事情。
一、業(yè)務能力做薄
做薄是為了解耦，只有業(yè)務最懂自己業(yè)務，不要嘗試去控制他們，可以套用張一鳴的那句話“context，not control”。中臺可以更多關(guān)注在業(yè)務無關(guān)的能力建設上，比如穩(wěn)定性、監(jiān)控、性能、運維工具等非功能屬性的事情上。
二、中臺能力做強
中臺除了建設上面提到的非功能性的屬性，還可以建設豐富的業(yè)務解決方案庫、業(yè)務組件庫等框架與工具，賦能于業(yè)務，讓其快速發(fā)展。做強主要體現(xiàn)在這里。
三、系統(tǒng)結(jié)構(gòu)簡單
復雜是萬惡之源，太精巧也代表著太脆弱。
以商品業(yè)務為例
淘寶的商品、盒馬的商品、零售通的商品之間存在著巨大的差異，他們的擴展屬性也不同，業(yè)務校驗規(guī)則也不同。
這種情況下，合適的方式是將中臺做薄，讓其退化成類似于Entity Bean的形式。
如果這種形式的中臺，其實他就是對外提供了API，解決了商品的存儲、擴展、性能、穩(wěn)定性、工具、搜索等和業(yè)務不相關(guān)的功能。
我們討論的更多的是對存量老業(yè)務和中臺的協(xié)作方式上，那對于新業(yè)務有沒有真正提效的方式呢？
可以通過腳手架的方式解決。比如下圖：
一個值得思考的問題是，這個腳手架的生成操作究竟由誰決定呢？
再進一步的話，可以在腳手架基礎之上增加一些組件庫。
也就是把一些公用的邏輯封裝成組件，打造一個中臺組件庫，業(yè)務可以按需組合這種組件，實現(xiàn)自己的業(yè)務定制。
但打造有價值、可迭代的組件不是件輕松的事情，同樣需要考慮組件與業(yè)務之間的耦合關(guān)系，不要讓組件綁架業(yè)務，困住業(yè)務的手腳。