車好多 CTO，關于中臺的思考和嘗試
我們的討論先從定義中臺這個概念開始。
定義中臺我認為可以有兩個角度， 一個是從中臺本身的價值和出發(fā)點來：中臺是在多個部門之間共享的開發(fā)資源所提供的業(yè)務能力、數(shù)據(jù)能力和計算能力的集合；另一個定義從中臺的相對定位來：前臺是面向終端用戶的一組業(yè)務能力，業(yè)務中臺是對前臺應用的抽象，提供多個前臺業(yè)務之間共享的業(yè)務邏輯、數(shù)據(jù)和計算能力。
我想特別強調這個定義是相對中性的， 我們能夠通過這個定義區(qū)分什么東西是中臺，什么不是中臺。有的中臺定義嚴格來說不是定義， 比如說“中臺是提升效率和加速業(yè)務增長的一種工具”、“中臺是我們的戰(zhàn)略目標”、“中臺就是一個革命性的設計”，似乎不做中臺就成了反革命一樣，就是落后生產(chǎn)力的代表。
其實中臺本質上是一個對業(yè)務能力的抽象和共享的過程，一直存在，也談不上革命。甚至業(yè)務中臺這個概念也沒有那么新：Oracle Fusion Middleware 早在 2006 年就發(fā)布了， 覆蓋了包括企業(yè)智能、團隊協(xié)作、內容等多個領域。
我想特別強調中臺和前臺的定義差別。前臺服務單個業(yè)務，目標是就是這個業(yè)務的增長；前臺必須緊貼業(yè)務做好差異化；前臺的定位要考慮到競爭環(huán)境、目標客群、業(yè)務成長階段、運營人員能力、人才供給、監(jiān)管環(huán)境等因素；前臺要有自己的技術內容、定制流程、流程對接和個性化數(shù)據(jù)應用。中臺服務整個集團，目標往往是降低成本、加強管控，或者是擴大規(guī)模優(yōu)勢；中臺的定位在以集團利益最大化的前提下最大化服務前臺業(yè)務的需求；中臺有自己的技術實現(xiàn)、研發(fā)流程和數(shù)據(jù)標準。而后臺是不具備任何業(yè)務語義的基礎計算能力。下圖就是對這種定位的一個示意：
當前對中臺的看法主要有兩種極端，一種是認為中臺是一個完全錯誤的方向，要緊急剎車；另一種是認為中臺就是技術終局，是業(yè)務增長的不二法門。我們先分別討論一下這兩種觀點。
我開始考慮 QCon 演講話題的時候，中臺只是多個備選話題之一， 但是當我意識到大家對待這個話題非常極端的時候， 我才覺得有必要把這個話題講通講透。最終選擇以中臺做為架構師獨立思考的能力的一個案例。這是題外話。
先說中臺是否是個完全錯誤的方向？想思考清楚這個方向是否錯誤， 我們可以先看中臺最初的動力來自哪里。不論是甲骨文還是后來的阿里， 其實本質動因是一個大公司內部的大業(yè)務呈軍閥割據(jù)現(xiàn)象，導致多條業(yè)務線重復造輪子。由此而衍生出其他的問題， 比如說團隊之間內耗嚴重；小業(yè)務無資源， 增長乏力；整個公司數(shù)字資產(chǎn)不統(tǒng)一， 損失機會成本；業(yè)務線也不能對核心系統(tǒng)做打磨，業(yè)務線不穩(wěn)定。因為這些原因， 所以阿里的高管們就以美國海軍陸戰(zhàn)隊和 Supercell 的組織形式為啟發(fā)， 做了“大 (業(yè)務) 中臺， 小 (業(yè)務) 前臺”的策略。這里先不談中臺是否能解決這些問題， 或者是說戰(zhàn)略啟發(fā)是否正確， 但是毫無疑問的是， 中臺想解決的問題既沒有過時， 也依然正在不同的公司里發(fā)生， 所以這些問題還是必須解決。也就是說從問題定義角度來說， 中臺是個完全正確的方向。
那么中臺是否是這些問題的完美解決方案？中臺是不是萬能藥？我們已經(jīng)知道答案是否定了。現(xiàn)在看來中臺的解決方案至少有以下幾個缺陷：
對創(chuàng)新的遏制：一個被完全中臺化的業(yè)務導致集團內部過分分工， 任何前臺業(yè)務都被認為是中臺能力的線性組合。舉個例子， 有的公司會有接近或超過千人的供應鏈中臺、搜索廣告中臺、內容中臺等等， 而多數(shù)業(yè)務前臺少則幾個人，多不過幾十人。前臺團隊任何一個人哪怕是全職和一個中臺域對接， 也無法理解該域的全貌或者跟上這個中臺的演變。這意味著前臺業(yè)務完全無法在這些中臺相關的領域做創(chuàng)新。本來的創(chuàng)新業(yè)務變成無從創(chuàng)新， 當初的動力變成了中臺最大的詛咒。有說法說，一個業(yè)務靠拖拉拽就能編排出來了， 這不是創(chuàng)新是什么？事實證明這種創(chuàng)新完全無用。沒有任何一個投資人會把自己的錢投到一個可以被大公司拖拉拽出來的商業(yè)模式。真正的創(chuàng)新不是現(xiàn)有能力的線性組合。
反人性：中臺自身的場景往往缺乏前瞻設計 ，是對現(xiàn)有場景的抽象。而當某個創(chuàng)新在一個前線業(yè)務線孵化出來之后，中臺團隊會通過強制收編該能力來擴大自己的能力， 同時強迫前臺團隊下線一個他們研發(fā)了很久的創(chuàng)新。這種行為往往造成精英人才的流失， 使得本來就受到遏制的前臺創(chuàng)新變得更為匱乏。
過度設計：中臺經(jīng)常以最全的最復雜的實現(xiàn)來應對任何一個簡單的應用場景。大量成熟行業(yè)和強監(jiān)管環(huán)境下的需求被帶入到了創(chuàng)新業(yè)務中。在帶來大量運營復雜性的同時增加了用戶（買家、賣家、本地運營）的學習難度。這就是我們常講的膨脹軟件（Bloatware）：巨大、復雜、緩慢、低效。
喪失對客戶心智的追求：中臺團隊的產(chǎn)品和研發(fā)的核心技能在于抽象和降本。前臺業(yè)務的核心能力在于對商業(yè)機會的捕捉和新商業(yè)機會的創(chuàng)造。這是兩種完全不同的技能，往往對應著完全不同類型的人才。一個長期在多個業(yè)務中間找共性來降本的人是不會專注在最大化前臺業(yè)務增長的。
之前做中臺的公司往往被以上一個或者多個問題所困擾。也就是說中臺事實上不是完美的。為什么呢？
我們先思考一下中臺的本質。中臺本質是把一些分散的重復的開發(fā)工作集中起來， 通過共享同一個研發(fā)團隊來提升不同業(yè)務線之間的共性， 也就是通過抽象和統(tǒng)一來獲取增量價值。具體的增量可以分成以下幾類：
以零成本研發(fā)加速上線：對完全可以復用的標準化功能集中開發(fā)，未來以低研發(fā)成本上線，比如說一些無狀態(tài)的計算能力，類似 SDK。
提升業(yè)務穩(wěn)定性：對產(chǎn)品差異不大的領域，通過集中研發(fā)運維而獲取更高的業(yè)務穩(wěn)定性。這樣一個團隊開發(fā)的底層服務能夠同時服務多個業(yè)務場景， 聚合所有的流量來加速積累。同時研發(fā)同學也通過更多的場景來加速打磨設計。常見的領域是會員、營銷、交易、資金等服務。
加速技術和業(yè)務能力擴散：把整個集團的能力盡量跨 BU 復制。這包括兩種類型，一種是類似 SaaS 服務的場景，比如說 Chatbot、直播、內容等領域；另一種是類似 ISV 的場景，由一個中央的團隊同時提供研發(fā)，對內服務和運營，比如說安全、風控、財務、人力資源等。
統(tǒng)一數(shù)據(jù)資產(chǎn)：在集團內部統(tǒng)一數(shù)據(jù)標準，最大化數(shù)據(jù)復用， 把一個場景積累的數(shù)據(jù)優(yōu)勢應用到其他的業(yè)務場景中去，逐漸建設企業(yè)的數(shù)據(jù)壁壘。
集團層次的資源高效利用：把部分資源中央化，變成全集團資源， 比如說商品中臺不但包括商品庫，也包括商品質量控制體系、背后的貨源、相關貨源的價格以及服務競爭力。而商家中臺，不僅僅是包含商家的信息，還包括商家的合作意愿和對集團品牌的信任，從而使得商家更愿意和一個新孵化的初創(chuàng)業(yè)務合作。集團真正想跨 BU 復用的是從一個大業(yè)務孵化而來的競爭力，而不是信息本身。
從研發(fā)和管理難度來說從１到５逐漸變難，而帶來的增量價值也依次變得更大。
從這個本質來看， 那么中臺似乎就是完美的， 那么之前提到的不完美又從哪里來的呢？我們有必要更深度的思考一下。
首先我們思考一下上面的要求， 我們把這些要求歸類成六類， 其中第一種場景細分成低成本上線和加速上線兩個類別，那么這些類別有以下共同特征：
0.低成本上線：同一個功能模塊在多個場景中被使用， 要求該能力的接口確定性高。
1.加速上線：同一個基礎能力不需修改或者簡單修改即可上線， 也就是模塊化支持，要求高 API 確定性和好的功能通用性。
2.提升穩(wěn)定性：同一個業(yè)務能力持續(xù)打磨， 要求需求同時具備高的接口穩(wěn)定性和好的跨業(yè)務線通用性。
3.加速能力擴散：基礎業(yè)務能力可以跨業(yè)務線模式， 要求該能力具備比較好的通用性，可以在多個業(yè)務線之間共享。
4.統(tǒng)一數(shù)據(jù)資產(chǎn)：數(shù)據(jù)模型可以在多個業(yè)務線之間統(tǒng)一， 對功能的通用性要求高， 且業(yè)務需求相對穩(wěn)定。
5.集團資源高效利用：業(yè)務能力共享， 不僅僅是技術資源， 其實是業(yè)務能力有高通用性且需求穩(wěn)定。
下圖把這幾個特征分別放在一個四象限圖里面。這四個象限的橫軸代表技術演化穩(wěn)定性，豎軸代表功能的通用性。中臺的優(yōu)勢領域在第三象限，這個象限技術具有高確定性，業(yè)務功能通用。第二象限屬于比較穩(wěn)定但是不通用的小眾行業(yè)。第四象限屬于普遍流行但是高速變化的領域，比如說內容和服飾或者端上的交互。而第一象限屬于創(chuàng)新業(yè)務，不但定制化程度高且快速演化，比如說面向垂直行業(yè)或者初創(chuàng)技術。也就是說：中臺的使用范圍是有限的，僅僅限于技術演化相對慢且功能通用性高的場景中。這是我們得出的第一個結論。過往中臺的失敗案例也往往集中在把中臺強推到創(chuàng)新業(yè)務中的情況。
那么為什么即便是在相對優(yōu)勢的領域，中臺也沒有取得類似 Supercell 那樣的效率呢？他們不過是 100~200 人便撐起一個獨角獸， 甚至是跨多個大洲的超級獨角獸。值得一提的類似 Supercell 的中臺并非個案， 僅僅百萬人口的小國愛沙尼亞就有 4 個獨角獸， 他們的中臺團隊也不過是百人左右。那么國內的中臺為啥動輒就是成百上千人的研發(fā)團隊呢？
我有幸深度接觸過芬蘭和愛沙尼亞的幾家獨角獸， 我覺得導致這個巨大差異的根源在于研發(fā)文化和資源環(huán)境。這兩個國家由于歷史和文化傳統(tǒng)，造就了崇尚簡約、尊重原創(chuàng)和組織扁平的研發(fā)文化。而我們國家的高科技從業(yè)人口全球第一， 過去的十年間每年又有大量的新從業(yè)者。這些新從業(yè)者又普遍有大廠情節(jié)， 期望為一個技術品牌相對比較高且收入穩(wěn)定的公司工作。也就是說大廠同時具備了孵化中臺的條件且有源源不斷的對成長沒有太多訴求的勞動力。這其實是不斷重復造輪子的必要條件。
當前幾乎所有的大廠都有同樣的晉升和薪酬激勵機制，就是一個人管理的研發(fā)越多， 層級越高， 收入也越高。這種機制有個巨大的弊端， 一個獎勵組織膨脹的機制必然會帶來組織膨脹。而組織膨脹最終因為康威定理的作用也必然導致膨脹的系統(tǒng)， 也就是前面提到的膨脹軟件（Bloatware）。這個就是不斷重復造輪子的充分條件。
大量的勞動力供給和鼓勵膨脹的機制合在一起， 結果就是團隊上下不斷加速重復造破輪子。下圖就是對這個過程示意。某個研發(fā)經(jīng)理從狀態(tài) 1 開始， 帶領一個小團隊。這個時候他對應的層級是 2， 收入是 3。某一天， 他啟動一個大項目， 給這個項目一個冠冕堂皇的名字， 比如說“拿破侖項目”。他的團隊急速膨脹到 4。項目上線時間一到， 不論完成與否質量如何， 他立即對外發(fā)戰(zhàn)報、做宣講：我們取得了“滑鐵盧大捷！”。緊接著他的上級內舉不避親， 把他從層級 2 提拔到 5， 收入也相應的從 3 調整到 6。然后周而復始， 他再啟動“拿破侖二世項目”繼續(xù)開發(fā)膨脹軟件。很快他的“成功”也被瘋狂復制。公司變得臃腫遲緩。
這個現(xiàn)象當然不局限于中臺， 整個公司都在膨脹。但是這種膨脹對中臺而言卻是災難性的。一個膨脹的業(yè)務線傷害到自己， 但一個膨脹的中臺放緩的是整個集團。
所以我們有了第二條重要結論： 中臺的建設要有與之匹配的組織文化機制。
那么什么樣的機制才是一個合理的組織文化機制呢？很遺憾我自己也不知道正確答案。但是我們或多或少可以從過去的失敗中尋求教訓，從歷史中尋找啟發(fā)。
先來思考一下過去的失敗。我歸納下來大致有這么幾個根因：
對哪個團隊做中臺或者哪個人來設計中臺的決策是個自頂而下的中央決策過程。做中臺的人沒有所必須的抽象能力和業(yè)務理解，類似過去封建王朝的分封的過程。受封的僅僅是生在帝王家， 有沒有治理和決策能力不重要。
中臺的推行機制往往是個掠奪的過程。對業(yè)務線的創(chuàng)新直接復制， 不尊重發(fā)明者的知識產(chǎn)權和勞動。中臺所到處，寸草不生。
中臺能力一旦發(fā)布， 獨家專供， 哪怕功能不完善， 設計不合理也不允許業(yè)務團隊復制或分支。
中臺為了做規(guī)模強制向業(yè)務線推行，業(yè)務線被迫削足適履，消耗嚴重。每次中臺升級，小的 BU 更是叫苦不迭，故障頻發(fā)。
其實這幾個問題并非中臺所獨有。上面的四個問題其實和封建社會的分封機制類似，本來應該有市場選擇、良性競爭和創(chuàng)新來完成的事情變成了強權。其實這個問題是有解決方案的。
伴隨工業(yè)革命帶來的人類勞動力巨大釋放（具體見 Berkley 大學 De Long 教授對人類文明史的人均 GDP 分析）背后也有完整的機制，這些機制就是我們可以借鑒的出路：
機會配置由市場決定。
尊重知識產(chǎn)權和創(chuàng)新， 保護參與者的創(chuàng)新意愿。
通過自由準入維持市場活力。
最終由規(guī)模效應形成統(tǒng)一的事實標準。
雖然我還不能確定這是不是完整且合理的中臺機制， 但是我們的思想實驗至少給了我們避免過去的失敗的一些希望：
誰來做中臺、誰的設計才是真正合理的中臺設計，由市場決定。
尊重原創(chuàng)，通過溯源和產(chǎn)權機制保護創(chuàng)新。
自由準入， 不做獨家專供。
不強制推行， 設計統(tǒng)一是演化的結果， 而不是行政命令。
不過哪怕有這個機制， 我們還是要認識到中臺天然的局限性。中臺不是萬能的， 它僅僅合適在高確定性和高通用性場景下創(chuàng)造增量價值。沒有合理的期望設定，其實還會讓迭代過程漫長而艱苦。在一個競爭環(huán)境下， 錯誤的目標設定不但會帶來大量的資本和時間消耗，而且對員工士氣打擊也很大， 甚至會最終毀掉一家公司。
從公司層面來看， 中臺要降低成本， 但是抽象帶來的增值是有天花板的。抽象的終局是個零和游戲， 不過就是把前臺的事情交割給中臺去做。沒有價值創(chuàng)造，只有權力轉移。另外，中臺要加速業(yè)務迭代也有逐漸減少的邊際收入。?一個健康的行業(yè)中需求是永遠進化的，不存在超前的完美設計為未來不斷創(chuàng)造價值。中臺在業(yè)務起初產(chǎn)生最大的價值，其后逐漸衰減。
從一個團隊或者是 BU 角度來看，小 BU 期望通過中臺帶來業(yè)務增長，但事實上大 BU 的需求總是優(yōu)先， 會占用幾乎所有的中臺資源。小 BU 的需求永遠排在第二位，會餓死在等待的途中。另外中臺靠合理的設計創(chuàng)造價值， 我們期望中臺的設計是最優(yōu)的， 但是真正有能力的架構師不一定在你所依賴的中臺團隊。你接觸的中臺邊界不一定合理。如果中臺很復雜， 跨團隊的溝通也會變得更艱難。中臺創(chuàng)造的增量價值就越小了。
從個人來看，每個人都期望能力提升， 但是擅于發(fā)現(xiàn)機會也擅于抽象的人不一定在中臺團隊。每個人都期望職業(yè)高速發(fā)展， 但是高增長的團隊往往是高風險的前臺團隊，而高穩(wěn)定的中臺團隊往往變化緩慢。所以沒有不論中臺還是前臺團隊， 人才的配置不一定是最優(yōu)的。
知道了這些局限性， 我們才能對中臺設定合理的期望。有了合理的期望， 我們還需要建設合理的迭代機制。這里我們還是可以借鑒其他領域的成功路徑。我認為對中臺機制探索應該向任何科學探索一樣， 是個從假設到實驗， 到結果分析， 到修正，最終到正確結論的過程。?我們從相對合理的中臺訴求出發(fā)， 做合理的機制設計， 通過實施，到效果驗證，然后對機制不斷修正， 來最終得出逼近真理的一個機制。
在分享車好多的中臺實現(xiàn)機制之前， 我想先講一下我為什么要分享車好多的機制。每一個機制的設計和迭代都是一個漫長的過程。雖然我們剛剛開始， 但是我把我們中臺的機制完整的分享出來，也歡迎大家采用， 甚至是加入到我們的建設中來。我也想聽到反饋， 尤其是你們已經(jīng)發(fā)現(xiàn)機制漏洞的地方，那么我們就能夠共同進步。
首先，考慮在車好多做中臺的原因和之前提到的幾個原因類似：加速技術能力和業(yè)務能力擴散，整合數(shù)據(jù)資產(chǎn)，最大化公司資源利用。
那么具體什么時間啟動有這么幾個考慮，第一和下圖有關， 就是中臺啟動之后的復雜度的變化情況。隨著時間變化，首先中臺服務的調用頻次逐漸上升，甚至往往呈指數(shù)上漲， 其次是 BU 數(shù)目逐漸上升， 最后是變更頻次逐漸變少。太早上線其實價值不大， 因為極端情況就是一兩條業(yè)務線之間做復用， 中臺帶來的合力還抵不上增加的重構成本、溝通成本和人力開銷。這一點上車好多有 8 條不同的業(yè)務線， 有了足夠的場景復雜度和中臺增值空間， 但是也不至于像某些公司有成百條業(yè)務線，建設難度非常大。?另外車好多的業(yè)務天生是低頻業(yè)務， QPS 低于傳統(tǒng)電商３～４個數(shù)量級， 所以做中臺有絕對優(yōu)勢。最后車好多的主流業(yè)務和新興業(yè)務都在不同層次的迭代當中，所以我們的變更頻次比較高， 對做中臺也是利好。
以上三個因素，是決定中臺的研發(fā)復雜度的核心指標，我們可以大致建模為：中臺變更復雜度 =（QPS*Count(BU)/ 變更頻次)。任何一個服務，QPS 越低，依賴這個服務的 BU 數(shù)越少，迭代的越頻繁， 那么變更的難度越小， 變更帶來的風險越小。
如下圖所示。在中臺建設期間， 由于自動化測試能力還不夠，接口設計不完善， 團隊同學的運維和溝通能力也還在成長中， 那么風險上升就會相對比較快。等到中臺建設相對完善了，風險的增長和迭代難度就相對變緩。
車好多的優(yōu)勢是 QPS 增長不快，原因是汽車交易本來就是個低頻事件， 全年全國不過是千萬量級，和傳統(tǒng)電商完全沒辦法比， 而車好多自生的業(yè)務迭代速度非?？?， 變更頻繁， BU 數(shù)增長很慢， 也就是車好多的中臺變更復雜度隨著時間的變化非常慢， 留給車好多的中臺建設時間相對就比較充裕。另外車好多最大的兩個板塊新車和二手車有很大的相似性， 所以建設中臺可以從這兩個板塊的最相似業(yè)務線出手來打造能力， 這也是優(yōu)勢。
但是車好多的中臺也有自己的挑戰(zhàn)：首先三大板塊新車、二手車和車后的差異大，而且業(yè)務所處的階段不一樣， 有的在做增長，有的在做轉型，有的在做賽道探索。所以同樣有前面第二節(jié)里提到的中臺適用范圍的挑戰(zhàn)。另外整個產(chǎn)業(yè)互聯(lián)網(wǎng)行業(yè)還不同于傳統(tǒng)互聯(lián)網(wǎng)，我們的產(chǎn)品技術還在從生產(chǎn)工具到核心生產(chǎn)力的過渡過程中。也就是說，技術的投入是有限的，技術帶來的增量價值也待驗證，所以研發(fā)投入不能過度超前。最后一個挑戰(zhàn)是這幾大板塊對應著數(shù)萬億的線下市場，所以車好多的業(yè)務與線下高度結合， 流程往往以天計算， 因此變革要和行業(yè)的適配能力和期望相符。
在定位上，車好多中臺要解決的問題集中在集團高確定性和高通用性領域的技術和數(shù)據(jù)共享，我們不對創(chuàng)新業(yè)務探索加速。車好多中臺是技術產(chǎn)業(yè)鏈的規(guī)?；蟮姆止ぃ?它的核心是對研發(fā)成本的優(yōu)化和某些計算和運營資源的集中化管控和共享。
在組織保障層面上， 我們以加速業(yè)務迭代為目標， 通過市場機制加速中臺的進化，通過內部開源且允許分支的方式加速進化和保障自由準入。我們鼓勵原創(chuàng)，以物質、獎金、股票和晉升激勵和固定人員投入來放大團隊原創(chuàng)的動力。
在文化保障上，技術上我們關注設計, 崇尚簡約，鼓勵創(chuàng)新。對中臺保持一個客觀的態(tài)度， 中臺回報不一定為正，也要迭代進化甚至消亡。中臺既不是管理方式，也不是價值觀。我們尊重學術自由， 中臺設計沒有權威， 邏輯面前人人平等。
下圖是車好多的中臺構成， 所有的業(yè)務線共享數(shù)據(jù)、計算、研發(fā)效能和企業(yè)效能中臺， 業(yè)務線對業(yè)務中臺形成部分依賴， 算法能力我們還沒有中臺化， 更多是個共享的組織， 而不是共享的技術能力， 所以用虛線表示。?每個中臺域的研發(fā)范圍如圖所示。業(yè)務線則按需定制， 我們通過控制業(yè)務線的研發(fā)人數(shù)防止膨脹軟件。
以前各家公司開發(fā)中臺， 很少對中臺軟件做出系統(tǒng)性要求。中臺團隊想交付什么就交付什么。這些軟件的質量參差不齊， 往往是項目的時間節(jié)點一到， 中臺團隊就三呼完美，那時候就有什么算什么， 業(yè)務團隊如果稍有抱怨， 未來的需求就免不了受打壓。為了避免這種情況， 我們對中臺的軟件做了一個定性要求。這些定性要求又可以大致分成兩類， 一類是必要條件， 一類是充分條件。
先說必要條件：
中臺軟件必須具有可解釋性， 也就是中臺能力可以被分解成一組可以被完整描述的行為。這里特別要強調完整描述， 有些團隊做中臺， 先不說自己能做什么， 而是先占領一個關鍵詞之后問你想要什么？你想要什么我們就可以做什么。?這個就是典型的圈地心態(tài)。對做什么功能，解決什么問題完全沒有任何前瞻思考， 結果就是越做越無序， 前臺團隊跟著變得越來越低效。
中臺必須具備可驗證性，也就是說中臺和計算的結果可以驗證， 中臺的交付的功能可以確定性的被證偽或者被證真。這是獨立測試和邊界穩(wěn)定需求，很多中臺是從業(yè)務線里劃分出來的。因為需求繁忙， 往往對自己的邊界也不做清晰定義， 也沒有完備的自動化功能測試，更別說場景集成測試了。哪怕有邊界，也經(jīng)常變動， 沒有兼容能力。這個要求就是對能力的驗證和兼容性做限制， 避免中臺墮入深不可測狀態(tài)。
再說充分條件：
中臺軟件必須具備可隔離性，中臺能力應該由多個相對獨立的模塊構成， 每個模塊對相關實體的狀態(tài)改變必須隔離在模塊內部。這個要求是確保前臺對中臺可以做到最小化。而且對中臺的依賴可以局限在前臺的個別業(yè)務模塊中， 這樣對某個中臺的依賴不會帶來整個系統(tǒng)的穩(wěn)定性降低。這個要求可以防止中臺過度侵入到前臺，無序擴張。
中臺的模塊必須可以被局部替代，中臺的各模塊加載獨立，且個別模塊所封裝能力可以被等價接口所替代而不影響剩余的模塊功能。這個要求和前面可解釋性 / 可驗證性一起就可以允許業(yè)務線對中臺形成部分依賴， 而不是只要依賴某個中臺的一個功能， 就必須所有功能全依賴，永遠全家桶。
中臺能力可以被第三方擴展和傳播。也就是說中臺的某個模塊可以被前臺團隊重寫后發(fā)布給全集團使用。這樣可以避免中臺能力僅僅獨家定制，創(chuàng)新被遏制在遠離前臺的后臺團隊。
為什么說前面兩個要求是必要條件呢？因為他們合在一起就是要解決中臺提供能力的可封裝性和可用性， 也就是說一個前臺團隊根據(jù)能力的描述可以決定是否使用一個中臺功能。而后面三個是充分條件， 就是中臺提供的能力前臺業(yè)務線也可以選擇不用， 或者部分使用那些有價值的模塊。?這樣中臺既可用、亦可棄， 才滿足了中臺做為一個通用能力加速業(yè)務線迭代的充分必要條件。
中臺設計和使用上我們有如下原則：
業(yè)務優(yōu)先。多數(shù)時候由業(yè)務線同學決定架構選型， 而不是中央決策。
反膨脹軟件。對中臺 API 穩(wěn)定性和數(shù)據(jù)模型兼容性做強制要求， 避免中臺膨脹過快。避免復雜依賴。
整個中臺要求扁平化微服務化設計，降低依賴深度，加速功能發(fā)現(xiàn)。
模塊化開發(fā)。各模塊有明確邊界，獨立文檔，可獨立設計 / 發(fā)布 / 被替代 / 升級。?模塊盡量以原子服務模式向往透出，模塊間依賴主要是服務依賴。
中臺的具體邊界和抽象深度是個非常有挑戰(zhàn)的問題，往往是個平衡，沒有對錯。對此我們做了設計追求的建議，就是期望各中臺團隊在交付壓力允許的情況下最大化的做到以下兩點：
邊界合理：尋找中臺的正確邊界，平衡研發(fā)成本和業(yè)務迭代速度。中臺的邊界應當使得 API 最簡化。
中臺對多個業(yè)務的抽象逼近最優(yōu)， 模型在信息量最大的情況下能夠保持相對穩(wěn)定。
下面兩張圖就是個具體的例子， 前一個模型簡單， 相對穩(wěn)定， 但是在這個模型下能夠提供的服務粒度粗。第二個模型更復雜， 這個模型下能夠提供相對更細粒度的服務。后者能夠適用多個車好多業(yè)務線的現(xiàn)有模式， 且信息容量更大，所以在當前的業(yè)務矩陣之下是個更好的模型。
車好多之前沒有中臺，怎么孵化出中臺來也是個挑戰(zhàn)。
孵化中臺有多個方式：
自由競爭制：個人或者團隊自主入場， 自主投入。代碼開源，去中心化研發(fā)， 通過統(tǒng)一發(fā)現(xiàn)機制對外露出。
中央授權制：由公司做頂層決策，不做團隊調整， 做項目強制統(tǒng)一多個技術分支。
集中孵化制：由公司做頂層決策， 對團隊先做整合， 之后由該團隊孵化中臺。
重點扶持制：不對稱的做研發(fā)人員補貼，對特定領域做引導，加速該領域的中臺建設。
視情況不同， 我們這幾種組織和孵化機制都有采用。
中臺的孵化具體有如下幾個平行的方向：
逐步建設市場機制：由前臺業(yè)務線研發(fā)做選型決策，保障業(yè)務優(yōu)先。同時通過 HC 管理引導最優(yōu)決策，靠市場和預算驅動最經(jīng)濟的決策， 防止中臺和前臺的膨脹軟件。在考核指標上前臺考核業(yè)務增長；中臺則考核前臺接入成本、前臺新需求延遲、前臺定制成本和接口高穩(wěn)定性。
建設自由準入能力，同時鼓勵經(jīng)營和創(chuàng)新。除了前面提到的內部開源且允許分支，我們會逐步建設去中心化研發(fā)體系，加速分布式創(chuàng)新。同時為了鼓勵中臺經(jīng)營， 通過控制業(yè)務線分支權利來說防止重復造輪子。
人才流轉策略：中臺和前臺必須有統(tǒng)一的研發(fā)體系和統(tǒng)一的人才流轉機制，保持雙方的活力。對有基本的能力、偏好和專業(yè)度差異的研發(fā)人才做定向培養(yǎng)， 支持轉崗。
保障業(yè)務連續(xù)性和人員穩(wěn)定性：對中臺我們會保留一定程度的頂層設計，避免大范圍技術和組織重構。
最后講講人才。不論設計多么完美的機制， 最終還是要靠人來實現(xiàn)。合理的機制僅僅能夠避免引人誤入歧途， 但是價值創(chuàng)造還是要靠優(yōu)秀的人才。
車好多對人才的畫像可以總結成兩句話：做學問要包容求真， 做人要有良知和勇氣。?第一點是期望我們的人才能夠保持開闊的視野， 對新事物和不同觀點的包容，和不斷探索尋求真正有價值洞察的欲望， 從而發(fā)現(xiàn)別人不能發(fā)現(xiàn)的機會。第二點是希望我們的人才能夠為公司做正確的決策， 不斷讓正確的事情發(fā)生。同時他也要有勇氣，愿意站出來阻止錯誤的事情發(fā)生。我們當下雖然有一些這樣的人才，但也渴望更多的這樣的人才加入。
中臺可以在高確定性和高通用性場景下能創(chuàng)造增量價值。中臺應該有合理的應用場景和時間窗口， 需要用一些設計原則來約束， 也需要相應的組織機制支持。中臺有自己的生命周期， 要做階段性的重構和重定位。這就是我對中臺的大致理解。
車好多的中臺實踐不是標準答案，甚至不一定正確。我的分享是僅僅是為了帶動高質量的思想碰撞， 也希望得到大家的幫助和反饋。謝謝大家。
來源：xxxxxx
版權申明：內容來源網(wǎng)絡，版權歸原創(chuàng)者所有。除非無法確認，我們都會標明作者及出處，如有侵權煩請告知，我們會立即刪除并表示歉意。謝謝!
