點擊上方“朱小廝的博客”，選擇“設為星標”

后臺回復"書"，獲取

后臺回復“k8s”，可領取k8s資料

圍繞中臺的爭議非常多，但是往往爭議的原因是連中臺這個概念都完全沒有達成共識，可以說是毫無意義的爭吵。在 12 月 20 日由極客邦科技舉辦的 QCon 全球軟件開發大會 2020（上海站）上，車好多 CTO 郭東白博士發表了主題演講《從中臺技術談架構師的獨立思考能力》。由于演講時間有限， 關于中臺的思考沒辦法講得非常透徹，本文是對演講的補充，期望能與大家形成思想碰撞。

中臺的定義

我們的討論先從定義中臺這個概念開始。

定義中臺我認為可以有兩個角度， 一個是從中臺本身的價值和出發點來：中臺是在多個部門之間共享的開發資源所提供的業務能力、數據能力和計算能力的集合；另一個定義從中臺的相對定位來：前臺是面向終端用戶的一組業務能力，業務中臺是對前臺應用的抽象，提供多個前臺業務之間共享的業務邏輯、數據和計算能力。

我想特別強調這個定義是相對中性的， 我們能夠通過這個定義區分什么東西是中臺，什么不是中臺。有的中臺定義嚴格來說不是定義， 比如說“中臺是提升效率和加速業務增長的一種工具”、“中臺是我們的戰略目標”、“中臺就是一個革命性的設計”，似乎不做中臺就成了反革命一樣，就是落后生產力的代表。

其實中臺本質上是一個對業務能力的抽象和共享的過程，一直存在，也談不上革命。甚至業務中臺這個概念也沒有那么新：Oracle Fusion Middleware 早在 2006 年就發布了， 覆蓋了包括企業智能、團隊協作、內容等多個領域。

我想特別強調中臺和前臺的定義差別。前臺服務單個業務，目標是就是這個業務的增長；前臺必須緊貼業務做好差異化；前臺的定位要考慮到競爭環境、目標客群、業務成長階段、運營人員能力、人才供給、監管環境等因素；前臺要有自己的技術內容、定制流程、流程對接和個性化數據應用。中臺服務整個集團，目標往往是降低成本、加強管控，或者是擴大規模優勢；中臺的定位在以集團利益最大化的前提下最大化服務前臺業務的需求；中臺有自己的技術實現、研發流程和數據標準。而后臺是不具備任何業務語義的基礎計算能力。下圖就是對這種定位的一個示意：

對待中臺的兩種極端態度

當前對中臺的看法主要有兩種極端，一種是認為中臺是一個完全錯誤的方向，要緊急剎車；另一種是認為中臺就是技術終局，是業務增長的不二法門。我們先分別討論一下這兩種觀點。

我開始考慮 QCon 演講話題的時候，中臺只是多個備選話題之一， 但是當我意識到大家對待這個話題非常極端的時候， 我才覺得有必要把這個話題講通講透。最終選擇以中臺做為架構師獨立思考的能力的一個案例。這是題外話。

先說中臺是否是個完全錯誤的方向？想思考清楚這個方向是否錯誤， 我們可以先看中臺最初的動力來自哪里。不論是甲骨文還是后來的阿里， 其實本質動因是一個大公司內部的大業務呈軍閥割據現象，導致多條業務線重復造輪子。由此而衍生出其他的問題， 比如說團隊之間內耗嚴重；小業務無資源， 增長乏力；整個公司數字資產不統一， 損失機會成本；業務線也不能對核心系統做打磨，業務線不穩定。因為這些原因， 所以阿里的高管們就以美國海軍陸戰隊和 Supercell 的組織形式為啟發， 做了“大 (業務) 中臺， 小 (業務) 前臺”的策略。這里先不談中臺是否能解決這些問題， 或者是說戰略啟發是否正確， 但是毫無疑問的是， 中臺想解決的問題既沒有過時， 也依然正在不同的公司里發生， 所以這些問題還是必須解決。也就是說從問題定義角度來說， 中臺是個完全正確的方向。

那么中臺是否是這些問題的完美解決方案？中臺是不是萬能藥？我們已經知道答案是否定了。現在看來中臺的解決方案至少有以下幾個缺陷：

對創新的遏制：一個被完全中臺化的業務導致集團內部過分分工， 任何前臺業務都被認為是中臺能力的線性組合。舉個例子， 有的公司會有接近或超過千人的供應鏈中臺、搜索廣告中臺、內容中臺等等， 而多數業務前臺少則幾個人，多不過幾十人。前臺團隊任何一個人哪怕是全職和一個中臺域對接， 也無法理解該域的全貌或者跟上這個中臺的演變。這意味著前臺業務完全無法在這些中臺相關的領域做創新。本來的創新業務變成無從創新， 當初的動力變成了中臺最大的詛咒。有說法說，一個業務靠拖拉拽就能編排出來了， 這不是創新是什么？事實證明這種創新完全無用。沒有任何一個投資人會把自己的錢投到一個可以被大公司拖拉拽出來的商業模式。真正的創新不是現有能力的線性組合。

反人性：中臺自身的場景往往缺乏前瞻設計 ，是對現有場景的抽象。而當某個創新在一個前線業務線孵化出來之后，中臺團隊會通過強制收編該能力來擴大自己的能力， 同時強迫前臺團隊下線一個他們研發了很久的創新。這種行為往往造成精英人才的流失， 使得本來就受到遏制的前臺創新變得更為匱乏。

過度設計：中臺經常以最全的最復雜的實現來應對任何一個簡單的應用場景。大量成熟行業和強監管環境下的需求被帶入到了創新業務中。在帶來大量運營復雜性的同時增加了用戶（買家、賣家、本地運營）的學習難度。這就是我們常講的膨脹軟件（Bloatware）：巨大、復雜、緩慢、低效。

喪失對客戶心智的追求：中臺團隊的產品和研發的核心技能在于抽象和降本。前臺業務的核心能力在于對商業機會的捕捉和新商業機會的創造。這是兩種完全不同的技能，往往對應著完全不同類型的人才。一個長期在多個業務中間找共性來降本的人是不會專注在最大化前臺業務增長的。

之前做中臺的公司往往被以上一個或者多個問題所困擾。也就是說中臺事實上不是完美的。為什么呢？

思考中臺的本質

我們先思考一下中臺的本質。中臺本質是把一些分散的重復的開發工作集中起來， 通過共享同一個研發團隊來提升不同業務線之間的共性， 也就是通過抽象和統一來獲取增量價值。具體的增量可以分成以下幾類：

以零成本研發加速上線：對完全可以復用的標準化功能集中開發，未來以低研發成本上線，比如說一些無狀態的計算能力，類似 SDK。

提升業務穩定性：對產品差異不大的領域，通過集中研發運維而獲取更高的業務穩定性。這樣一個團隊開發的底層服務能夠同時服務多個業務場景， 聚合所有的流量來加速積累。同時研發同學也通過更多的場景來加速打磨設計。常見的領域是會員、營銷、交易、資金等服務。

加速技術和業務能力擴散：把整個集團的能力盡量跨 BU 復制。這包括兩種類型，一種是類似 SaaS 服務的場景，比如說 Chatbot、直播、內容等領域；另一種是類似 ISV 的場景，由一個中央的團隊同時提供研發，對內服務和運營，比如說安全、風控、財務、人力資源等。

統一數據資產：在集團內部統一數據標準，最大化數據復用， 把一個場景積累的數據優勢應用到其他的業務場景中去，逐漸建設企業的數據壁壘。

集團層次的資源高效利用：把部分資源中央化，變成全集團資源， 比如說商品中臺不但包括商品庫，也包括商品質量控制體系、背后的貨源、相關貨源的價格以及服務競爭力。而商家中臺，不僅僅是包含商家的信息，還包括商家的合作意愿和對集團品牌的信任，從而使得商家更愿意和一個新孵化的初創業務合作。集團真正想跨 BU 復用的是從一個大業務孵化而來的競爭力，而不是信息本身。

從研發和管理難度來說從１到５逐漸變難，而帶來的增量價值也依次變得更大。

從這個本質來看， 那么中臺似乎就是完美的， 那么之前提到的不完美又從哪里來的呢？我們有必要更深度的思考一下。

中臺的適用范圍

首先我們思考一下上面的要求， 我們把這些要求歸類成六類， 其中第一種場景細分成低成本上線和加速上線兩個類別，那么這些類別有以下共同特征：

0.低成本上線：同一個功能模塊在多個場景中被使用， 要求該能力的接口確定性高。

1.加速上線：同一個基礎能力不需修改或者簡單修改即可上線， 也就是模塊化支持，要求高 API 確定性和好的功能通用性。

2.提升穩定性：同一個業務能力持續打磨， 要求需求同時具備高的接口穩定性和好的跨業務線通用性。

3.加速能力擴散：基礎業務能力可以跨業務線模式， 要求該能力具備比較好的通用性，可以在多個業務線之間共享。

4.統一數據資產：數據模型可以在多個業務線之間統一， 對功能的通用性要求高， 且業務需求相對穩定。

5.集團資源高效利用：業務能力共享， 不僅僅是技術資源， 其實是業務能力有高通用性且需求穩定。

下圖把這幾個特征分別放在一個四象限圖里面。這四個象限的橫軸代表技術演化穩定性，豎軸代表功能的通用性。中臺的優勢領域在第三象限，這個象限技術具有高確定性，業務功能通用。第二象限屬于比較穩定但是不通用的小眾行業。第四象限屬于普遍流行但是高速變化的領域，比如說內容和服飾或者端上的交互。而第一象限屬于創新業務，不但定制化程度高且快速演化，比如說面向垂直行業或者初創技術。也就是說：中臺的使用范圍是有限的，僅僅限于技術演化相對慢且功能通用性高的場景中。這是我們得出的第一個結論。過往中臺的失敗案例也往往集中在把中臺強推到創新業務中的情況。

中臺的組織機制

那么為什么即便是在相對優勢的領域，中臺也沒有取得類似 Supercell 那樣的效率呢？他們不過是 100~200 人便撐起一個獨角獸， 甚至是跨多個大洲的超級獨角獸。值得一提的類似 Supercell 的中臺并非個案， 僅僅百萬人口的小國愛沙尼亞就有 4 個獨角獸， 他們的中臺團隊也不過是百人左右。那么國內的中臺為啥動輒就是成百上千人的研發團隊呢？

我有幸深度接觸過芬蘭和愛沙尼亞的幾家獨角獸， 我覺得導致這個巨大差異的根源在于研發文化和資源環境。這兩個國家由于歷史和文化傳統，造就了崇尚簡約、尊重原創和組織扁平的研發文化。而我們國家的高科技從業人口全球第一， 過去的十年間每年又有大量的新從業者。這些新從業者又普遍有大廠情節， 期望為一個技術品牌相對比較高且收入穩定的公司工作。也就是說大廠同時具備了孵化中臺的條件且有源源不斷的對成長沒有太多訴求的勞動力。這其實是不斷重復造輪子的必要條件。

當前幾乎所有的大廠都有同樣的晉升和薪酬激勵機制，就是一個人管理的研發越多， 層級越高， 收入也越高。這種機制有個巨大的弊端， 一個獎勵組織膨脹的機制必然會帶來組織膨脹。而組織膨脹最終因為康威定理的作用也必然導致膨脹的系統， 也就是前面提到的膨脹軟件（Bloatware）。這個就是不斷重復造輪子的充分條件。

大量的勞動力供給和鼓勵膨脹的機制合在一起， 結果就是團隊上下不斷加速重復造破輪子。下圖就是對這個過程示意。某個研發經理從狀態 1 開始， 帶領一個小團隊。這個時候他對應的層級是 2， 收入是 3。某一天， 他啟動一個大項目， 給這個項目一個冠冕堂皇的名字， 比如說“拿破侖項目”。他的團隊急速膨脹到 4。項目上線時間一到， 不論完成與否質量如何， 他立即對外發戰報、做宣講：我們取得了“滑鐵盧大捷！”。緊接著他的上級內舉不避親， 把他從層級 2 提拔到 5， 收入也相應的從 3 調整到 6。然后周而復始， 他再啟動“拿破侖二世項目”繼續開發膨脹軟件。很快他的“成功”也被瘋狂復制。公司變得臃腫遲緩。

這個現象當然不局限于中臺， 整個公司都在膨脹。但是這種膨脹對中臺而言卻是災難性的。一個膨脹的業務線傷害到自己， 但一個膨脹的中臺放緩的是整個集團。

所以我們有了第二條重要結論： 中臺的建設要有與之匹配的組織文化機制。

尋找中臺的合理組織機制

那么什么樣的機制才是一個合理的組織文化機制呢？很遺憾我自己也不知道正確答案。但是我們或多或少可以從過去的失敗中尋求教訓，從歷史中尋找啟發。

先來思考一下過去的失敗。我歸納下來大致有這么幾個根因：

對哪個團隊做中臺或者哪個人來設計中臺的決策是個自頂而下的中央決策過程。做中臺的人沒有所必須的抽象能力和業務理解，類似過去封建王朝的分封的過程。受封的僅僅是生在帝王家， 有沒有治理和決策能力不重要。

中臺的推行機制往往是個掠奪的過程。對業務線的創新直接復制， 不尊重發明者的知識產權和勞動。中臺所到處，寸草不生。

中臺能力一旦發布， 獨家專供， 哪怕功能不完善， 設計不合理也不允許業務團隊復制或分支。

中臺為了做規模強制向業務線推行，業務線被迫削足適履，消耗嚴重。每次中臺升級，小的 BU 更是叫苦不迭，故障頻發。

其實這幾個問題并非中臺所獨有。上面的四個問題其實和封建社會的分封機制類似，本來應該有市場選擇、良性競爭和創新來完成的事情變成了強權。其實這個問題是有解決方案的。

伴隨工業革命帶來的人類勞動力巨大釋放（具體見 Berkley 大學 De Long 教授對人類文明史的人均 GDP 分析）背后也有完整的機制，這些機制就是我們可以借鑒的出路：

機會配置由市場決定。

尊重知識產權和創新， 保護參與者的創新意愿。

通過自由準入維持市場活力。

最終由規模效應形成統一的事實標準。

雖然我還不能確定這是不是完整且合理的中臺機制， 但是我們的思想實驗至少給了我們避免過去的失敗的一些希望：

誰來做中臺、誰的設計才是真正合理的中臺設計，由市場決定。

尊重原創，通過溯源和產權機制保護創新。

自由準入， 不做獨家專供。

不強制推行， 設計統一是演化的結果， 而不是行政命令。

中臺的演進機制探索

不過哪怕有這個機制， 我們還是要認識到中臺天然的局限性。中臺不是萬能的， 它僅僅合適在高確定性和高通用性場景下創造增量價值。沒有合理的期望設定，其實還會讓迭代過程漫長而艱苦。在一個競爭環境下， 錯誤的目標設定不但會帶來大量的資本和時間消耗，而且對員工士氣打擊也很大， 甚至會最終毀掉一家公司。

從公司層面來看， 中臺要降低成本， 但是抽象帶來的增值是有天花板的。抽象的終局是個零和游戲， 不過就是把前臺的事情交割給中臺去做。沒有價值創造，只有權力轉移。另外，中臺要加速業務迭代也有逐漸減少的邊際收入。?一個健康的行業中需求是永遠進化的，不存在超前的完美設計為未來不斷創造價值。中臺在業務起初產生最大的價值，其后逐漸衰減。

從一個團隊或者是 BU 角度來看，小 BU 期望通過中臺帶來業務增長，但事實上大 BU 的需求總是優先， 會占用幾乎所有的中臺資源。小 BU 的需求永遠排在第二位，會餓死在等待的途中。另外中臺靠合理的設計創造價值， 我們期望中臺的設計是最優的， 但是真正有能力的架構師不一定在你所依賴的中臺團隊。你接觸的中臺邊界不一定合理。如果中臺很復雜， 跨團隊的溝通也會變得更艱難。中臺創造的增量價值就越小了。

從個人來看，每個人都期望能力提升， 但是擅于發現機會也擅于抽象的人不一定在中臺團隊。每個人都期望職業高速發展， 但是高增長的團隊往往是高風險的前臺團隊，而高穩定的中臺團隊往往變化緩慢。所以沒有不論中臺還是前臺團隊， 人才的配置不一定是最優的。

知道了這些局限性， 我們才能對中臺設定合理的期望。有了合理的期望， 我們還需要建設合理的迭代機制。這里我們還是可以借鑒其他領域的成功路徑。我認為對中臺機制探索應該向任何科學探索一樣， 是個從假設到實驗， 到結果分析， 到修正，最終到正確結論的過程。?我們從相對合理的中臺訴求出發， 做合理的機制設計， 通過實施，到效果驗證，然后對機制不斷修正， 來最終得出逼近真理的一個機制。

車好多的中臺實踐

在分享車好多的中臺實現機制之前， 我想先講一下我為什么要分享車好多的機制。每一個機制的設計和迭代都是一個漫長的過程。雖然我們剛剛開始， 但是我把我們中臺的機制完整的分享出來，也歡迎大家采用， 甚至是加入到我們的建設中來。我也想聽到反饋， 尤其是你們已經發現機制漏洞的地方，那么我們就能夠共同進步。

為什么考慮在車好多做中臺

首先，考慮在車好多做中臺的原因和之前提到的幾個原因類似：加速技術能力和業務能力擴散，整合數據資產，最大化公司資源利用。

那么具體什么時間啟動有這么幾個考慮，第一和下圖有關， 就是中臺啟動之后的復雜度的變化情況。隨著時間變化，首先中臺服務的調用頻次逐漸上升，甚至往往呈指數上漲， 其次是 BU 數目逐漸上升， 最后是變更頻次逐漸變少。太早上線其實價值不大， 因為極端情況就是一兩條業務線之間做復用， 中臺帶來的合力還抵不上增加的重構成本、溝通成本和人力開銷。這一點上車好多有 8 條不同的業務線， 有了足夠的場景復雜度和中臺增值空間， 但是也不至于像某些公司有成百條業務線，建設難度非常大。?另外車好多的業務天生是低頻業務， QPS 低于傳統電商３～４個數量級， 所以做中臺有絕對優勢。最后車好多的主流業務和新興業務都在不同層次的迭代當中，所以我們的變更頻次比較高， 對做中臺也是利好。

以上三個因素，是決定中臺的研發復雜度的核心指標，我們可以大致建模為：中臺變更復雜度 =（QPS*Count(BU)/ 變更頻次)。任何一個服務，QPS 越低，依賴這個服務的 BU 數越少，迭代的越頻繁， 那么變更的難度越小， 變更帶來的風險越小。

如下圖所示。在中臺建設期間， 由于自動化測試能力還不夠，接口設計不完善， 團隊同學的運維和溝通能力也還在成長中， 那么風險上升就會相對比較快。等到中臺建設相對完善了，風險的增長和迭代難度就相對變緩。

車好多的優勢是 QPS 增長不快，原因是汽車交易本來就是個低頻事件， 全年全國不過是千萬量級，和傳統電商完全沒辦法比， 而車好多自生的業務迭代速度非常快， 變更頻繁， BU 數增長很慢， 也就是車好多的中臺變更復雜度隨著時間的變化非常慢， 留給車好多的中臺建設時間相對就比較充裕。另外車好多最大的兩個板塊新車和二手車有很大的相似性， 所以建設中臺可以從這兩個板塊的最相似業務線出手來打造能力， 這也是優勢。

但是車好多的中臺也有自己的挑戰：首先三大板塊新車、二手車和車后的差異大，而且業務所處的階段不一樣， 有的在做增長，有的在做轉型，有的在做賽道探索。所以同樣有前面第二節里提到的中臺適用范圍的挑戰。另外整個產業互聯網行業還不同于傳統互聯網，我們的產品技術還在從生產工具到核心生產力的過渡過程中。也就是說，技術的投入是有限的，技術帶來的增量價值也待驗證，所以研發投入不能過度超前。最后一個挑戰是這幾大板塊對應著數萬億的線下市場，所以車好多的業務與線下高度結合， 流程往往以天計算， 因此變革要和行業的適配能力和期望相符。

車好多的中臺定位和組織文化保障

在定位上，車好多中臺要解決的問題集中在集團高確定性和高通用性領域的技術和數據共享，我們不對創新業務探索加速。車好多中臺是技術產業鏈的規模化之后的分工， 它的核心是對研發成本的優化和某些計算和運營資源的集中化管控和共享。

在組織保障層面上， 我們以加速業務迭代為目標， 通過市場機制加速中臺的進化，通過內部開源且允許分支的方式加速進化和保障自由準入。我們鼓勵原創，以物質、獎金、股票和晉升激勵和固定人員投入來放大團隊原創的動力。

在文化保障上，技術上我們關注設計, 崇尚簡約，鼓勵創新。對中臺保持一個客觀的態度， 中臺回報不一定為正，也要迭代進化甚至消亡。中臺既不是管理方式，也不是價值觀。我們尊重學術自由， 中臺設計沒有權威， 邏輯面前人人平等。

下圖是車好多的中臺構成， 所有的業務線共享數據、計算、研發效能和企業效能中臺， 業務線對業務中臺形成部分依賴， 算法能力我們還沒有中臺化， 更多是個共享的組織， 而不是共享的技術能力， 所以用虛線表示。?每個中臺域的研發范圍如圖所示。業務線則按需定制， 我們通過控制業務線的研發人數防止膨脹軟件。

對中臺軟件的要求

以前各家公司開發中臺， 很少對中臺軟件做出系統性要求。中臺團隊想交付什么就交付什么。這些軟件的質量參差不齊， 往往是項目的時間節點一到， 中臺團隊就三呼完美，那時候就有什么算什么， 業務團隊如果稍有抱怨， 未來的需求就免不了受打壓。為了避免這種情況， 我們對中臺的軟件做了一個定性要求。這些定性要求又可以大致分成兩類， 一類是必要條件， 一類是充分條件。

先說必要條件：

中臺軟件必須具有可解釋性， 也就是中臺能力可以被分解成一組可以被完整描述的行為。這里特別要強調完整描述， 有些團隊做中臺， 先不說自己能做什么， 而是先占領一個關鍵詞之后問你想要什么？你想要什么我們就可以做什么。?這個就是典型的圈地心態。對做什么功能，解決什么問題完全沒有任何前瞻思考， 結果就是越做越無序， 前臺團隊跟著變得越來越低效。

中臺必須具備可驗證性，也就是說中臺和計算的結果可以驗證， 中臺的交付的功能可以確定性的被證偽或者被證真。這是獨立測試和邊界穩定需求，很多中臺是從業務線里劃分出來的。因為需求繁忙， 往往對自己的邊界也不做清晰定義， 也沒有完備的自動化功能測試，更別說場景集成測試了。哪怕有邊界，也經常變動， 沒有兼容能力。這個要求就是對能力的驗證和兼容性做限制， 避免中臺墮入深不可測狀態。

再說充分條件：

中臺軟件必須具備可隔離性，中臺能力應該由多個相對獨立的模塊構成， 每個模塊對相關實體的狀態改變必須隔離在模塊內部。這個要求是確保前臺對中臺可以做到最小化。而且對中臺的依賴可以局限在前臺的個別業務模塊中， 這樣對某個中臺的依賴不會帶來整個系統的穩定性降低。這個要求可以防止中臺過度侵入到前臺，無序擴張。

中臺的模塊必須可以被局部替代，中臺的各模塊加載獨立，且個別模塊所封裝能力可以被等價接口所替代而不影響剩余的模塊功能。這個要求和前面可解釋性 / 可驗證性一起就可以允許業務線對中臺形成部分依賴， 而不是只要依賴某個中臺的一個功能， 就必須所有功能全依賴，永遠全家桶。

中臺能力可以被第三方擴展和傳播。也就是說中臺的某個模塊可以被前臺團隊重寫后發布給全集團使用。這樣可以避免中臺能力僅僅獨家定制，創新被遏制在遠離前臺的后臺團隊。

為什么說前面兩個要求是必要條件呢？因為他們合在一起就是要解決中臺提供能力的可封裝性和可用性， 也就是說一個前臺團隊根據能力的描述可以決定是否使用一個中臺功能。而后面三個是充分條件， 就是中臺提供的能力前臺業務線也可以選擇不用， 或者部分使用那些有價值的模塊。?這樣中臺既可用、亦可棄， 才滿足了中臺做為一個通用能力加速業務線迭代的充分必要條件。

車好多中臺的設計原則

中臺設計和使用上我們有如下原則：

業務優先。多數時候由業務線同學決定架構選型， 而不是中央決策。

反膨脹軟件。對中臺 API 穩定性和數據模型兼容性做強制要求， 避免中臺膨脹過快。避免復雜依賴。

整個中臺要求扁平化微服務化設計，降低依賴深度，加速功能發現。

模塊化開發。各模塊有明確邊界，獨立文檔，可獨立設計 / 發布 / 被替代 / 升級。?模塊盡量以原子服務模式向往透出，模塊間依賴主要是服務依賴。

中臺的具體邊界和抽象深度是個非常有挑戰的問題，往往是個平衡，沒有對錯。對此我們做了設計追求的建議，就是期望各中臺團隊在交付壓力允許的情況下最大化的做到以下兩點：

邊界合理：尋找中臺的正確邊界，平衡研發成本和業務迭代速度。中臺的邊界應當使得 API 最簡化。

中臺對多個業務的抽象逼近最優， 模型在信息量最大的情況下能夠保持相對穩定。

下面兩張圖就是個具體的例子， 前一個模型簡單， 相對穩定， 但是在這個模型下能夠提供的服務粒度粗。第二個模型更復雜， 這個模型下能夠提供相對更細粒度的服務。后者能夠適用多個車好多業務線的現有模式， 且信息容量更大，所以在當前的業務矩陣之下是個更好的模型。

車好多的中臺組織和孵化機制

車好多之前沒有中臺，怎么孵化出中臺來也是個挑戰。

孵化中臺有多個方式：

自由競爭制：個人或者團隊自主入場， 自主投入。代碼開源，去中心化研發， 通過統一發現機制對外露出。

中央授權制：由公司做頂層決策，不做團隊調整， 做項目強制統一多個技術分支。

集中孵化制：由公司做頂層決策， 對團隊先做整合， 之后由該團隊孵化中臺。

重點扶持制：不對稱的做研發人員補貼，對特定領域做引導，加速該領域的中臺建設。

視情況不同， 我們這幾種組織和孵化機制都有采用。

中臺的孵化具體有如下幾個平行的方向：

逐步建設市場機制：由前臺業務線研發做選型決策，保障業務優先。同時通過 HC 管理引導最優決策，靠市場和預算驅動最經濟的決策， 防止中臺和前臺的膨脹軟件。在考核指標上前臺考核業務增長；中臺則考核前臺接入成本、前臺新需求延遲、前臺定制成本和接口高穩定性。

建設自由準入能力，同時鼓勵經營和創新。除了前面提到的內部開源且允許分支，我們會逐步建設去中心化研發體系，加速分布式創新。同時為了鼓勵中臺經營， 通過控制業務線分支權利來說防止重復造輪子。

人才流轉策略：中臺和前臺必須有統一的研發體系和統一的人才流轉機制，保持雙方的活力。對有基本的能力、偏好和專業度差異的研發人才做定向培養， 支持轉崗。

保障業務連續性和人員穩定性：對中臺我們會保留一定程度的頂層設計，避免大范圍技術和組織重構。

關于人才

最后講講人才。不論設計多么完美的機制， 最終還是要靠人來實現。合理的機制僅僅能夠避免引人誤入歧途， 但是價值創造還是要靠優秀的人才。

車好多對人才的畫像可以總結成兩句話：做學問要包容求真， 做人要有良知和勇氣。?第一點是期望我們的人才能夠保持開闊的視野， 對新事物和不同觀點的包容，和不斷探索尋求真正有價值洞察的欲望， 從而發現別人不能發現的機會。第二點是希望我們的人才能夠為公司做正確的決策， 不斷讓正確的事情發生。同時他也要有勇氣，愿意站出來阻止錯誤的事情發生。我們當下雖然有一些這樣的人才，但也渴望更多的這樣的人才加入。

結? ? ? ?語

中臺不是萬能的， 但是可以在高確定性和高通用性場景下能創造增量價值。中臺應該有合理的應用場景和時間窗口， 需要用一些設計原則來約束， 也需要相應的組織機制支持。中臺有自己的生命周期， 要做階段性的重構和重定位。這就是我對中臺的大致理解。

車好多的中臺實踐不是標準答案，甚至不一定正確。我的分享是僅僅是為了帶動高質量的思想碰撞， 也希望得到大家的幫助和反饋。謝謝大家。

原文出處：

https://www.linkedin.com/pulse/%E5%85%B3%E4%BA%8E%E4%B8%AD%E5%8F%B0%E7%9A%84%E6%80%9D%E8%80%83%E5%92%8C%E5%B0%9D%E8%AF%95-dongbai-guo-%E9%83%AD%E4%B8%9C%E7%99%BD-

作者介紹：

郭東白博士，車好多 CTO，有二十年大型軟件系統研發和架構經驗，對跨大洲、高可用、高流量服務端軟件架構和研發有深入研究。領導設計了全球跨國家、多市場、多語言、多幣種、實時個性化、每秒近萬筆訂單量的多機房異地多活電商平臺，連續兩年在超過 200% 流量增速下保持了 99.99% 的可用性。在 2015 年 11 月 11 日創造了 2200 萬單跨境交易，全球 214 個國家逾千萬人用 16 種語言下單。除電商領域的鉆研外，郭東白還為多個公司在不同領域打造了多維度、多層次的數據供應鏈產品，并且有十多年的大型跨國界項目和大團隊管理經驗。在甲骨文，微軟和亞馬遜開發了多項突破性科技創新產品并且在市場上取得了巨大成功。過去分別為甲骨文，微軟，亞馬遜設計制定實施了工業標準戰略，參與規則制定，策略整合，伙伴發展，和長期戰略規劃。

想知道更多？掃描下面的二維碼關注我

后臺回復"技術"，加入技術群

后臺回復“k8s”，可領取k8s資料

【精彩推薦】

• 原創|OpenAPI標準規范

• 如此簡單| ES最全詳細使用教程

• ClickHouse到底是什么？為什么如此牛逼！

• 原來ElasticSearch還可以這么理解

• 面試官：InnoDB中一棵B+樹可以存放多少行數據？

• 微服務下如何解耦？對于已經緊耦合下如何重構？

• 如何構建一套高性能、高可用、低成本的視頻處理系統？

• 架構之道：分離業務邏輯和技術細節

• 星巴克不使用兩階段提交
  

點個贊+在看，少個 bug?????

總結

以上是生活随笔為你收集整理的中台不是万能药，关于中台的思考和尝试的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。