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