阿里“拆臺”,中臺真的不香了?
圖片來自 Pexels
自從 2015 阿里巴巴提出中臺概念和戰(zhàn)略,“中臺”這個技術(shù)術(shù)語逐漸火熱起來。
尤其是從 2019 年開始,各類技術(shù)大會、各類公眾號都在大力宣揚中臺,出版社也趁著熱點趕緊出版各類中臺書籍,一時間中臺有“舊時王謝堂前燕,飛入尋常百姓家”的感覺。
如果你跟人聊技術(shù)的時候,不發(fā)表一些中臺的言論,不討論一些中臺的問題,那肯定會顯得你技術(shù)有點落伍了!
如果我們仔細(xì)閱讀這些文章,可能會發(fā)現(xiàn)一個有趣的現(xiàn)象,絕大部分談中臺的都是做中臺的,很少看到用中臺的人出來評價。
從人性的角度來講,做中臺的肯定不會說中臺不好,畢竟還要靠這個恰飯,王婆賣瓜不自夸的話,買瓜的人自然會少。
偶爾有幾篇說中臺有問題的文章,例如《中臺翻車紀(jì)實:一年叫停,員工轉(zhuǎn)崗被裁,資源全浪費》、《中臺,我信了你的邪 | 深氪》。
也很快會有人跳出來說“你們能力不行,所以中臺沒做好”、“中臺是一個業(yè)務(wù)、組織、技術(shù)的協(xié)同,你們肯定是組織沒保證”……
總而言之,現(xiàn)在到處都能看到做中臺的人說中臺如何如何好,偶爾有幾個跳出來說不好的都會被質(zhì)疑能力不行!
按照我的技術(shù)理念來看,沒有完美的技術(shù),沒有放之四海皆好的技術(shù),如果你只能看到一項技術(shù)的好處,而看不到坑,那實際上很可能就會掉到坑里去。
我雖然沒有真正負(fù)責(zé)做過中臺,但我做過平臺和中間件,更為特別的是,我參與了兩個基于中臺的業(yè)務(wù)項目,一個項目是將手游交易系統(tǒng)遷移到電商中臺,另一個項目是在支付中臺上從 0 到 1 搭建一個錢包。
這兩個項目讓我親自實踐了一下在阿里和螞蟻的中臺上做項目,讓我有機(jī)會近距離觀察中臺的運作機(jī)制,在一次次與中臺的討論、PK、撕逼的過程中,對中臺也有了更深的理解和認(rèn)識。
從我個人的經(jīng)歷和理解來看,目前關(guān)于中臺的很多說法是言過其實、模棱兩可、甚至是錯誤的,接下來我將給大家談?wù)剬嶋H上的中臺到底是怎么運作的,會有哪些坑。
由于我真正就是用的阿里電商中臺和螞蟻的支付中臺,因此不用質(zhì)疑中臺能力不行和組織能力不行才會有我說的那些問題。
01.中臺的價值真的有那么玄乎么?
關(guān)于中臺的價值,你看到的是這樣的:
可以讓各業(yè)務(wù)部門保持相對的獨立和分權(quán),保證對業(yè)務(wù)的敏感性和創(chuàng)新性;另一方面,用一個強(qiáng)大的平臺來對這些部門進(jìn)行總協(xié)調(diào)和支持,平衡集權(quán)與分權(quán),并為新業(yè)務(wù)新部門提供生長的空間,從而大幅降低組織變革的成本。中臺部門提煉各業(yè)務(wù)線的共性需求,最大限度地減少“重復(fù)造輪子”。
來源《一文讀懂「中臺」的前世今生》
實際上的中臺是這樣的:
①業(yè)務(wù)部門并不獨立
基于中臺的業(yè)務(wù)會被分為不同優(yōu)先級,大業(yè)務(wù)對于中臺的影響力遠(yuǎn)遠(yuǎn)大于小業(yè)務(wù),核心業(yè)務(wù)對中臺的影響力遠(yuǎn)遠(yuǎn)大于新業(yè)務(wù)。
形象點來說,中臺抱大業(yè)務(wù)的大腿,小業(yè)務(wù)抱中臺的大腿,因為中臺也是有 KPI 的,中臺的 KPI 怎么來?
當(dāng)然是大部分了來源于支持的業(yè)務(wù)了,大業(yè)務(wù)天然會有 KPI 數(shù)據(jù)上的優(yōu)勢。
這會導(dǎo)致什么問題呢?大業(yè)務(wù)的創(chuàng)新不管是不是共性的,中臺會鼎力支持,畢竟判斷是不是共性需求是中臺判斷的,而不是每次有個新業(yè)務(wù)的時候拉上所有業(yè)務(wù)方來評估和投票。
小業(yè)務(wù)就比較悲催了,中臺要拒絕你,只需簡單一句話“你這個業(yè)務(wù)不通用”,“你這個需求太特殊”。
如果小業(yè)務(wù)不服氣能怎么辦?沒什么辦法,不會存在仲裁委員會之類的機(jī)構(gòu),就算有,你去仲裁的時間都夠你自己把業(yè)務(wù)實現(xiàn) 5 遍了!
就算中臺認(rèn)為你的需求是共性需求,如果你是小業(yè)務(wù),很可能也會以優(yōu)先級的原因被排在很后面,這里的“很后面”可不是幾天幾周,很可能就是幾個月半年了!
而恰恰很多初創(chuàng)業(yè)務(wù)一開始規(guī)??隙ㄊ潜容^小的,基于中臺的開發(fā)模式很可能會制約創(chuàng)新業(yè)務(wù)的快速發(fā)展,除非這個創(chuàng)新業(yè)務(wù)一開始就有重量級人物掛帥,對中臺能夠有足夠的影響力。
②中臺并不總是能夠提煉共性需求
注意這里的需求不是指電商中臺里面“交易”這個粒度的需求,而是指“交易”系統(tǒng)里面一個個實際的功能點,你要是堅持說“交易”是共性需求,這實際上是一句正確的廢話。
事實上,提煉共性需求主要是中臺從 0 到 1 的建設(shè)的時候,因為這個時候已經(jīng)有多個業(yè)務(wù)需求的樣本存在,哪些是共性哪些是個性是比較容易分析出來的。
但一旦建成后后續(xù)的業(yè)務(wù)發(fā)展和創(chuàng)新,中臺和業(yè)務(wù)方天然存在對共性需求的不同訴求。
業(yè)務(wù)方總是期望將自己的需求劃為共性需求,因為這樣就能夠讓中臺出人來實現(xiàn)需求。
中臺總是期望先不要把需求劃為共性需求,而是等到多個業(yè)務(wù)都有類似需求的時候再由中臺來抽象提煉,這樣才能最大化復(fù)用,否則中臺每個需求都認(rèn)為是共性需求的話,中臺會累死。
而事實上幾乎不太可能出現(xiàn)多個業(yè)務(wù)同時提出某個需求,除了國家頒布的法律法規(guī)相關(guān)的需求外,絕大部分業(yè)務(wù)需求都是由某個業(yè)務(wù)方先提出來的。
這個時候中臺是無法判斷是否為共性需求的,只能又回到前面說的潛規(guī)則來操作:優(yōu)先滿足大業(yè)務(wù),怠慢小業(yè)務(wù)。
反正大業(yè)務(wù)的需求不管是不是共性的,做了后數(shù)據(jù)肯定好看,中臺 KPI 有保證;小業(yè)務(wù)就算以后被證明是共性的,前期做了也沒多少數(shù)據(jù),中臺很可能費力不討好。
③中臺的“輪子”會不斷變化
很多朋友看到“避免重復(fù)造輪子”就以為中臺把輪子造好了,業(yè)務(wù)方只管用就可以了,而實際情況是中臺確實把輪子造好了。
但是它每隔一段時間就會把輪子換一遍,例如中臺的數(shù)據(jù)模型、接口、架構(gòu)等其實都是需要根據(jù)業(yè)務(wù)發(fā)展不斷變化的。
為了達(dá)到中臺“復(fù)用”的目標(biāo),通常情況下中臺在推出新輪子后,就不會再長期維護(hù)老輪子,否則如果中臺同時維護(hù) 4~5 個相似的輪子,復(fù)用就無從談起。
這就要求基于中臺的業(yè)務(wù)都必須在某個時間段內(nèi)完成輪子的切換,相當(dāng)于是業(yè)務(wù)方進(jìn)行了一次被動架構(gòu)演進(jìn)。
當(dāng)然,如果沒有中臺,業(yè)務(wù)方的架構(gòu)肯定也要隨著業(yè)務(wù)的發(fā)展而演進(jìn),那這和跟隨中臺被動演進(jìn)有什么區(qū)別呢?
最主要的區(qū)別是中臺的架構(gòu)演進(jìn)頻率會比獨立的業(yè)務(wù)架構(gòu)演進(jìn)要快,道理很簡單:中臺融合了多個相似業(yè)務(wù)的發(fā)展!
舉個簡單例子:如果中臺支持 10 個業(yè)務(wù),其中有 1 個業(yè)務(wù)發(fā)展很快,中臺就必須跟著演進(jìn),剩余的 9 個業(yè)務(wù)即使沒有任何發(fā)展,也必須跟著被動演進(jìn)!更何況如果這 10 個業(yè)務(wù)本身都在不斷發(fā)展,那中臺的演進(jìn)會更快!
那是否存在某種牛逼的技術(shù),讓中臺的演進(jìn)不影響業(yè)務(wù)呢?絕大部分情況下都不可能,這是由中臺演進(jìn)的本質(zhì)決定的:中臺演進(jìn)的絕大部分動力來源于業(yè)務(wù),它的演進(jìn)不可能做到反過來不影響業(yè)務(wù)。
這點和技術(shù)平臺(存儲、消息隊列這類)不一樣,技術(shù)平臺演進(jìn)的動力來源于技術(shù)更新,是可以做到不影響業(yè)務(wù)的。
④中臺是某類業(yè)務(wù)的中臺,不是所有業(yè)務(wù)的中臺
中臺的本質(zhì)是提煉共性需求復(fù)用,如果業(yè)務(wù)差異太大的話,復(fù)用度不高,提煉和維護(hù)中臺花費的代價抵不上中臺復(fù)用帶來的價值。
所以,實際上應(yīng)該叫“電商中臺”、“支付中臺”、“物流中臺”、“出行中臺”、“視頻中臺”、“保險中臺”,而不應(yīng)該是“阿里中臺”、“騰訊中臺”、“百度中臺”、“滴滴中臺”。
當(dāng)然,因為現(xiàn)在“中臺”概念火爆,出現(xiàn)了原來很多做中間件和技術(shù)平臺的團(tuán)隊,紛紛將自己負(fù)責(zé)的“XX平臺”改為“技術(shù)中臺”。
從廣義的角度來說也可以,因為這確實是“各業(yè)務(wù)線共性需求”,畢竟存儲、緩存、消息隊列這些肯定是各業(yè)務(wù)線的共性需求,但通常情況下我們說中臺時所指的“需求”,還是指“業(yè)務(wù)需求”,即客戶可以使用到的功能。
所以,即使只是看到“茅臺云商”這種中臺項目的 PPT,也能大概率是可以推斷這個項目失敗的可能性會非常高:
圖片來源:中臺,我信了你的邪 | 深氪
02.中臺真的能夠以搭積木的方式來快速創(chuàng)新業(yè)務(wù)么?
關(guān)于中臺的效果,你看到的是這樣的:
因為阿里巴巴的生態(tài)非常復(fù)雜,很多業(yè)務(wù)方本身也很年輕,要怎么去做,下層到底能提供什么樣的支撐是不清楚的。
當(dāng)有大中臺思路之后,第一,我們這個體系里有什么樣的能力,可以讓各業(yè)務(wù)很清楚的知道,也可以讓前臺業(yè)務(wù)方更快的理解、選擇和使用中臺能力。
第二、我們提供了基礎(chǔ)解決方案,業(yè)務(wù)方根據(jù)需要做定制開發(fā)滿足自己的業(yè)務(wù)特性,對前臺的業(yè)務(wù)來說會更快。
摘自《中臺的問題,是技術(shù)的問題,還是人的問題》
實際的中臺是這樣的:
①中臺的體系有什么樣的功能,業(yè)務(wù)方根本不是很清楚的知道,而是基本不知道
事實上中臺自己也沒有人完整的知道中臺里面各個域各個子系統(tǒng)的能力,更加談不上業(yè)務(wù)方更快的理解、選擇和使用了。
你可以隨便打開一張某個技術(shù)大會上分享的中臺架構(gòu),滿滿的一頁甚至幾頁 PPT,大框小框幾十上百個,對應(yīng)到具體的線上運行的系統(tǒng)可能幾百上千個,這么復(fù)雜的一個系統(tǒng),怎么可能有人知道所有的功能和細(xì)節(jié)?更何況是業(yè)務(wù)方了。
至于說中臺提供完整的解決方案,業(yè)務(wù)方只要定制一下就可以快速上線,說起來容易做起來難,除非業(yè)務(wù)方是準(zhǔn)備復(fù)制一個和已有業(yè)務(wù)基本一樣的業(yè)務(wù),否則基本上是不可能實現(xiàn)的。
原因在于中臺提供的解決方案,必然是基于已有的業(yè)務(wù)來抽象出來的“共性需求”的大集合,如果這個解決方案可定制化度很高,那么就說明可復(fù)用度比較低;如果這個解決方案的可定制化度很低,雖然可復(fù)用度高但業(yè)務(wù)可擴(kuò)展度比較低。
而從中臺的本質(zhì)出發(fā),中臺必然會選取“可定制度低可復(fù)用度高”的方向,這就約束了只有復(fù)制一個非常類似的新業(yè)務(wù)的時候中臺的解決方案才有很大價值,但是對于同一個公司來說,為何要復(fù)制兩個基本一樣的業(yè)務(wù)呢?
如果真的有中臺選擇了“可定制度高”的解決方案,當(dāng)新業(yè)務(wù)和已有業(yè)務(wù)有較大差異的時候,中臺的解決方案并沒有什么很大價值,因為大量的工作量會耗費在定制那部分。
實際上我接觸的中臺是這樣運作的:中臺會分為很多“域”,例如“交易”、“搜索”、“會員”等,然后業(yè)務(wù)方將自己的業(yè)務(wù)需求寫出來,然后拉上各個域的產(chǎn)品接口人和技術(shù)接口人,一個域一個域的討論。
以“會員域”為例,討論的時候,會員域的產(chǎn)品接口人技術(shù)接口人肯定很熟悉會員的功能、模型和接口。
業(yè)務(wù)方需要跟中臺子域接口人講解業(yè)務(wù)需求,然后中臺子域接口人來評估會員當(dāng)前的能力哪些是支持的,哪些是不支持的。
不支持的部分是屬于共性需求還是屬于個性需求,如果是共性需求,需要給出中臺的修改的方案,而且修改方案還要會員域的架構(gòu)師進(jìn)行評審,因為改中臺是影響所有業(yè)務(wù)的。
如果是個性需求,需要設(shè)計出中臺和業(yè)務(wù)方交互的方式,例如是提供接口、配置、擴(kuò)展包等。
所以如果你真正基于中臺做過項目你就會發(fā)現(xiàn),編碼的時間確實少了,但是前期的溝通和后期的聯(lián)調(diào)非常耗時間,隨便做個什么項目,拉上 20~30 人算一般的,稍微大點的項目拉上 50~100 人也是很正常的。
以淘寶的中臺為例,如下是淘寶電商中臺共享事業(yè)部里面交易中心的結(jié)構(gòu):
圖片來源:《企業(yè) IT 架構(gòu)轉(zhuǎn)型之道》
注意:交易中心只是共享事業(yè)部的一個業(yè)務(wù)域,同級別的業(yè)務(wù)域從公開資料來看有 10 來個,而交易中心內(nèi)部就有 13 個子功能了,這些子功能最后都可能對應(yīng) 1 個或者多個實際運行的系統(tǒng)。
②中臺的所謂的“快”,并沒有嚴(yán)謹(jǐn)?shù)暮饬?/strong>
目前各類文章都會說有了中臺后業(yè)務(wù)開發(fā)快,但并沒有詳細(xì)的案例和分析到底有多快,僅有的幾個案例看起來很夸張,但沒有詳細(xì)背景描述其實并沒有說服力。
例如說某個業(yè)務(wù)新上線很快,到底是因為第一版功能很簡單,還是第一個版本投入了大量的人力來做,還是真的是因為用了中臺?
事實上我經(jīng)歷過的兩個接入中臺項目并不能看出來快,從實際的開發(fā)經(jīng)驗來看,業(yè)務(wù)方和中臺的需求講解和討論,業(yè)務(wù)方和中臺方案的設(shè)計討論,后期的業(yè)務(wù)系統(tǒng)和中臺系統(tǒng)聯(lián)調(diào)這些工作量并沒有減少,反而還會有一定程度的增加。
因為中臺在分析需求、設(shè)計方案、聯(lián)調(diào)測試的時候需要考慮對其它業(yè)務(wù)的影響。
中臺能夠帶來的效率提升主要體現(xiàn)在兩方面:
- 一是編碼的工作量確實會少,畢竟還是有大量的代碼可以重用的。
- 二是中臺的人員都對已有的類似業(yè)務(wù)和技術(shù)很熟悉,需求的確認(rèn)和方案的設(shè)計會更高效,全流程綜合來看,很難判斷效率到底高還是低。
事實上我之前在阿里游戲做過幾個從 0 到 1 的項目,因為老板重視,都是將原來類似的系統(tǒng)已有的核心開發(fā)人員拉過去開發(fā)新項目,最初的代碼也是從原系統(tǒng)拷貝過去改,開發(fā)效率一樣很高,核心原因簡單來說就是“熟手開發(fā)”。
以上是我從基于中臺的開發(fā)項目中觀察到的一些問題,歸納總結(jié)出來的一些經(jīng)驗。
總體來看好像我在質(zhì)疑中臺,其實不然。關(guān)于中臺的好處已經(jīng)有太多的文章了,本文試圖提供從使用者的視角來看中臺所看到的一些信息和問題,目的在于幫助大家更加全面的了解中臺。
我在《從零開始學(xué)架構(gòu)》一書中提煉出的架構(gòu)設(shè)計三原則中第一條就是“合適原則”,這個原則對中臺也是適應(yīng)的。
03.總結(jié)
總結(jié)來說就是:中臺不是靈丹妙藥,不要有問題就想著用中臺解決;中臺也不是放之四海而皆準(zhǔn),明確中臺的適應(yīng)場景和可能的坑,才能更好的落地中臺!
其實提出中臺的逍遙子已經(jīng)早就諄諄告誡了:
中臺并不適用于每家公司的每個階段。在獨立業(yè)務(wù)拓展期、突破期,“一定用獨立團(tuán)、獨立師、獨立旅建制來做”,否則就會變成瓶頸;但發(fā)展到一定階段,出現(xiàn)太多山頭時,就要“關(guān)停并轉(zhuǎn)、要合并同類項。問管理要效率,取消重復(fù)性建設(shè)。
來源《中臺,我信了你的邪 | 深氪》
作者:李運華
編輯:陶家龍
出處:zhuanlan.zhihu.com/p/339439639