點擊“技術領導力”關注???每天早上8:30推送

概述

中臺這個詞火爆挺久了。但從阿里 2015 年提出并開始實施，發展到目前為止，并沒有「標準化」：換句話說，它跟「人工智能」，「大數據」，「微服務」一樣，具體的含義在不同公司不同時期的不同上下文里，有著千差萬別的含義。

并且和這些詞不太一樣的是，它是一個在中文技術圈被頻繁使用，但在其他語言環境下幾乎找不到的詞。所以我常跟身邊的朋友說，關于它的爭議特別多，大家不用感覺奇怪，可以參考中醫。

本文的主要目的，是總結一下過去在中臺架構和建設的過程中的思路和方法，方便大家對「中臺」有一個相對一致的概念和邊界，從而在后續的工作中更好地進行思考、討論和選擇。因此內容主要集中在：

中臺是什么：我們對中臺的理解是怎樣的。

中臺做什么：我們做出判斷和選擇的思路是怎樣的。

一旦進入具體實現的細節，各個公司的技術棧、上下文和團隊發展階段各不一樣，往往沒有太大的參考意義，故本文不做過多討論。

是什么？

中臺的起源

中國有個好習慣是「治學先治史」，我們要了解中臺究竟是什么，可以看看它發展的歷史。

行業里面最早提出并實施「中臺戰略」的阿里內部，關于它的起源有兩種說法：一個是馬老師 2015 年年中參觀 supercell 之后提出的¹；一個是阿里的工程師們針對業務上的挑戰參考美軍的發展提出的。

supercell 是一家人數只有不到百人，卻連續推出了《部落戰爭》等多款爆款游戲，先后被軟銀和騰訊投資數十億美金的游戲行業的傳奇公司。它最大的特色就是內部以小團隊（cell）形式作戰，每個 cell 最多不超過 7 人。這些小團隊依靠公司提供的公共的后端架構、引擎、算法、美術等中臺資源，按照幾周的時間周期推出大量新游戲，快速試錯。

美軍則是從一戰時的按「軍」為單位作戰，到越戰時按「營」為單位作戰，逐步演進為「突擊隊+航母」的方式進行作戰。前線突擊隊通常 7 到 11 人，有著中后臺的強大支持（包括各種資源上的保障支持，衛星和無人機提供的偵查能力，高精度導彈的炮火支持等等），可以靈活選擇戰術并引領整個進攻高效完成。

可見，無論這兩種說法哪種準確，中臺戰略主要都是指通過「小前臺，大中臺」的架構方式，降低試錯成本，加快響應速度，從而真正做到「降本增效」。

「中臺」和「平臺」的關系

中臺既然是一種架構方式，那么看到「小前臺，大中臺」的時候，最容易有的困惑就是這跟以前行業里流行過的「厚平臺，薄應用」的架構方式有什么區別。

實際上，如果理解了企業級應用的架構難點，以及從服務化到平臺化再到中臺化的演變過程，就能非常清楚中臺架構方式究竟是什么了。

層次與架構

「架構」在軟件行業是一個非常微妙的詞。

我覺得無論是最初的 C/S 架構、B/S 架構還是如今的微服務架構，架構的內涵主要包括以下兩點：

• 是最高層次的系統分解和抽象。

• 是不易改變的設計方案和抉擇。

要想對系統進行分解和抽象，找到不易改變的部分，主要的方法是分層。在計算機本身的架構中，到處都有分層的例子：

• 系統：硬件層->HAL 層->OS 層->應用組件或平臺->各種應用。

• 網絡：不管是五層還是七層的分法，大體上都是硬件->鏈路->網絡->傳輸->應用。

分層的方式最核心的好處在于：

• 封裝細節，解除耦合：不如不用知道硬件細節就可以在 TCP 上構建 FTP 服務，如果硬件層完全換了 FTP 服務也可以正常運行。

• 有利于標準化：因為每層的實現相對自治，就容易形成每一層的標準化協議和運行機制。

和網絡這樣體系架構已經非常成熟的系統相比，互聯網公司構建的「企業級應用」，難度主要在于：

• 復雜的數據層次：需要持久化并經常變更的數據很多，需要打通和集成的外部異構系統很多，數據狀態復雜訪問量大訪問方式異構

• 復雜的業務邏輯：各種商業規則和潛規則形成的業務規則，還會隨時變化，軟件里沒有比業務邏輯更沒有邏輯的東西了

因為這兩方面的復雜性，對企業級應用分層時最困難的問題就是究竟有哪些層次，每一層的職責和邊界是什么。到目前為止，最流行的做法是按照 Brown 的建議²把它分為三層。

• 表現層主要處理用戶與系統之間的交互：可以是 App 或網頁，也可以是桌面客戶端。

• 領域層主要是處理各種業務領域內的邏輯：包括數據抽取，規則計算等等的邏輯。

• 數據層主要是數據庫，消息隊列等進行數據交互和持久化的工作。

各層的運行環境

進行了層次劃分之后，一個需要進行的架構選擇就是在哪里運行這部分工作：是在服務器上，還是在用戶的機器上。

一個常見的誤區是把表現層直接對應到前端應用，領域層直接對應到后端應用。實際上表現層的大量邏輯有可能是在我們的服務器上渲染的。而隨著桌面電腦或者手機的處理能力和交互需求的提升，很多領域層的業務邏輯反而是在客戶端進行處理的。舉個簡單的例子就是各種表單填寫時的字段校驗，在過去是需要提交到后端進行的，現在則有很多是監聽用戶焦點離開當前輸入框就進行了。

因此，在確定各層的運行環境的時候，核心是根據應用本身的特點，考慮不同的運行環境的優劣點安排：運行在客戶的機器上，好處是響應性能和不依賴網絡；缺點是如何把變更同步到各個客戶的機器并且讓它有效（想想不同瀏覽器的兼容性）。

比如數據層，我們當然不希望每個用戶有一個自己的數據庫，然后我們來做這些數據庫之間的讀寫同步，所以它一般都是運行在服務器上的。但是我們又希望用戶有很好的響應和體驗，所以我們各級的緩存里有不少是部署在客戶端的。

再比如表現層，我們希望給用戶很良好的響應速度和用戶體驗，所以可以在后端根據用戶畫像進行千人千面的數據組織來給不同用戶組合不同的操作界面。同時我們又希望能夠對客戶端能夠有更好的控制力，所以會打造客戶端的各種框架和組件。

架構的核心難點

進行了層次劃分和運行環境的選擇之后，架構的核心難點就在于如何抽象出：

標準的協議和運行機制。

滿足標準的分布式執行單元。

去中心化或中心化的控制單元。

正是在這樣的抽象過程中，行業里提出了 SOA，微服務，服務網格等服務化到平臺化的解決方案（SOA 和微服務的一個很重要的區別是執行單元和控制單元和通信方式，SOA 是有總線的）。而在三層里，如何對控制和處理復雜業務邏輯的領域層進行架構是關鍵中的關鍵，它既是公司業務生態的基礎，也直接決定了業務探索的速度和業務創新的成本。

所以我們以領域層為例，看看為什么需要業務平臺，它又如何演化到業務中臺。

業務中臺是什么

建設敏捷的前臺+強大的中臺，絕不是因為阿里或者京東做了，所以貨車幫要趕這個時髦。而是貨車幫本身的業務不斷發展下，技術體系的正確應對策略。

子系統時期

貨車幫初期，只有一個主業務，也只有一套主系統。隨著 ETC/車油/金融等業務的發展和技術人員的增加，這個系統的交付速度和穩定性都變差了。于是在 2017 年開始做分布式系統：把原來的單體系統拆分成多個中心承擔的分布式子系統。

最多的時候我們技術體系有 13 個中心組成，除開包括了用戶中心、活動中心等在內的基礎服務中心，還有包括平臺業務中心（車貨匹配業務），車后業務中心等在內的各個業務系統中心，以及大數據中心，運維中心等。

這個階段的核心工作實際上是把數百人的團隊拆分成了功能相對比較集中的小團隊。每個獨立的系統可以獨立設計、獨立接需求、獨立發布，整個研發交付速度和系統穩定性扛住了業務高速發展的需要。

但隨著事業部化的推進，業務決策鏈路更短，業務發展更快，技術人員的數量也快速增長。而且各個事業部的定位不一樣，業務發展階段、方向和規則都很不一樣。為了快速應對每天的業務需求變更，所有的員工都在加班加點，但由于在業務抽象建模，系統架構的開放性等方面考慮不足，導致業務邏輯之間的耦合和相互影響，研發質量和效率大幅下降。

這種見招拆招，垂直發展，未做足夠抽象通用的架構行業里稱之為「煙囪型架構」，解決這種問題通常就需要平臺化了。

平臺化時期

從一個個的中心到平臺化，核心是業務抽象建模和保持系統架構的開放性：

• 拉通考慮各個業務的邏輯，把基礎能力抽象出來，解決共性的 80%問題。

• 系統架構上保持開放性可擴展性，把業務和業務之間不同的邏輯隔離并進行封裝，解決 20%的個性化問題。

比如每個業務都需要用戶注冊和審核的功能，所以我們通過用戶平臺來提供統一的接口。而不同業務比如車貨匹配業務和車油業務對司機審核的力度要求是不同的，前者需要司機提供駕照等證件，后者可能就寬松很多。平臺要把不同業務的邏輯隔離開進行封裝，對外提供一致的接口。

再比如營銷活動，各個業務都要做。我們就可以抽象出一個從設計，上線，到數據收集全生命周期管理的活動平臺，提供給各個業務使用。但是各個業務具體的活動邏輯要做到很好的封裝，就需要建立元數據中心、規則中心、活動界面自動生成、活動數據自動埋點等等。

圖1 子系統到平臺化的架構升級

平臺化的核心收益其實就是降本增效：

• 抽象共性，減少重復建設投入的人力和時間成本。

• 快速支撐，提高需求到研發上線到效果復盤各環節效率。

平臺化的過程一般都會經歷從 API 治理和提供，到服務化，到最終形成平臺的過程，所以各個平臺并不會在同一天完成。實際上，一直到貨車幫開始建設中臺的時候，仍然有很多平臺正在建設中。

那么我們為什么又要推中臺戰略了呢？

中臺解決的問題

我們以一個新業務負責人的視角就很容易想通平臺化的問題了。

首先，作為各個業務的負責人，要了解各個平臺的功能和職責并且推動合作很困難。做一個新功能的 MVP 究竟需要多少人多少時間甚至都算不出來。

首先，平臺是提供抽象出來的共性功能，每個團隊專注自己的事情，提升效率。但這樣雖然帶來了專業，卻很容易導致「各家自掃門前雪」，對于創新業務的支持力度不足。

所以，就會出現類似下圖的問題：當公司的保險業務負責人想要進行某個新功能的開發時，經過反復溝通，發現自己的團隊承擔的部分可以在兩天之類完成開發，但是依賴的團隊對這相關功能的排期可能排到了兩三周后面。

圖2 業務平臺帶來的「各家自掃門前雪」

最后也是最大的問題是，領域的平臺化解決了領域層內部的問題，但業務的執行都是跨領域的。涉及用戶、商品、交易、營銷、支付、服務等等環節，橫跨多個系統。如何把多個平臺的數據集成到一起并加工分析而產生新的支持到業務的價值，變得非常困難。從當時的實際情況看，按照平臺化的架構方式，基本上是沒有辦法做數據驅動運營的。

因此，平臺化之后雖然解決了煙囪式架構的很多問題，但是隨著公司的發展，整個組織的效率仍然會逐漸降低。這不是一個技術問題，而是一個復雜生態下的協作問題。要解決這樣的問題，就要通過打造中臺來解決前面說的企業級應用架構的三個核心難點：

標準的協議和運行機制。

滿足標準的分布式執行單元。

去中心化或中心化的控制單元。

所以，中臺化其實是平臺化之后的自然階段，它主要是帶來了：

• 提供完整解決方案而不是暴露 API，給業務帶來的快速創新和試錯能力的提升。

• 通過數據統一治理和應用，給業務帶來數據驅動的運營能力的提升。

• 通過解決信息獲取成本高，系統互聯互通成本高的問題，給企業帶來組織效率的提升。

中臺建設的前提和難點

中臺建設的前提也是難點有兩個。

第一個是要需要有穩健的基礎設施：

系統性解決復雜度。

系統性解決高可用，高并發。

系統性解決開發測試環境一致性和便利性。

能夠做好具備這三個能力的基礎設施，要求公司具備較強的 IaaS/PaaS 層的建設能力。

第二個難點，在于中臺本身的建設過程中，如何進行抽象和劃分邊界。

但從技術架構上來說，常見的抽象方式有兩種：

按照信息流、資金流、數據流等等的構成 element 和 process，自上而下進行抽象。

按照對應一個個數據單元的 entity 以及這些 entity 的狀態和轉移，進行自下而上的抽象。

前者是更加常見也容易入手的方式，但是擴展性較差。后者則更加面向領域內的模型³，具有更好的健壯性，能夠支撐更多的業務場景。

但需要注意的是，對系統邊界的劃分，通常不是一個簡單的技術架構的問題，而是牽扯到流程設計、組織架構、業務歸屬等在內的極其復雜的挑戰。

因此，進行中臺建設一個隱含的前提，是公司的文化有一定成熟度，并且核心管理團隊和骨干成員有一致的目標。摩擦在所難免，解決的辦法更多不是靠的技術。

做什么？

理解了中臺是什么，我們來看看做什么。

一個很好的做法是，先看看別人做了什么。

別人做了什么？

圖3 阿里中臺架構圖 - 摘自鐘華云棲大會分享」

核心三大部分：

• 基礎設施：一套支撐分布式服務研發、上線和運營的基礎設施⁴。

• 業務中臺：包括了用戶中心、交易中心、搜索中心、營銷中心等在內的業務中臺

• 數據中臺：包括了數據技術，數據資產管理，數據服務等各個層次的數據中臺。

我們的總體架構

根據我們對中臺的理解，并參考其他公司的做法，貨車幫的總體架構是：

• 前端和接入層

• 前臺業務

• 業務中臺和數據中臺

• 基礎設施

• 企業效能和運維保障體系

圖4 整體系統架構：前臺/中臺/后臺

這套架構的核心目的，是在更快更好的支撐公司進行業務創新的同時，賦予業務真正的數據驅動運營的能力，從而在提升組織效率的同時，為發揮大數據的威力奠定基礎。

基礎設施

圖5 貨車幫面向云原生的基礎設施

包括云原生平臺 Newton 在內的基礎設施的設計和開發，以及統一規劃和提供的企業效能和運維保障能力，過去已經有過不少分享，這里就不再贅述。

但需要再次強調的是，如果沒有一套足夠好的基礎設施，最好先不要開始進行中臺的建設。

業務中臺

業務中臺的核心建設步驟是：

從業務領域的邊界是什么，提供的基礎服務是什么，領域服務和領域服務之間的流程鏈接標準是什么等角度，抽象出模型、規則和協議

基于這些模型、規則和協議，建立業務實施標準和管控標準。

根據實施和管控標準，提供權限集中管理、流程靈活可配的工具和引擎。

也就是說，如果還是像平臺化階段，通過一堆 API 來暴露能力，那就不是「中臺」。

以中臺化之后的用戶中心為例，它將不再只是提供用戶注冊審核相關的 API 或者類庫，而是需要站在公司業務特點上建立物流領域的包括用戶認證，用戶審核，用戶評價，用戶等級，用戶畫像等在內的用戶標準體系，并且負責所有相關的系統開發、業務協同和評價機制搭建，最終形成完整的能力地圖，通過工具和協議開放。

再比如，以訂單的創建過程為例，我們傳統的做法。需要梳理從能力規范、運行機制到配置管理和執行系統以及運營服務團隊構成的整套標準，才能真正為各業務方提供快速、低成本的創新能力。

圖6 通過業務中臺，為各個前臺業務提供統一的訂單處理能力

最終，業務中臺將通過各種層面的產品和服務來落地：

• 業務能力圖譜。

• 業務需求分解和配置的工具。

• 業務流程設計和配置的工具。

• 業務指標度量和跟蹤的工具。

基于這些產品，把每個業務它是怎么出來的，出來之后做了哪些業務需求和業務活動，每個業務活動的效果是怎么樣的，都沉淀下來。在此基礎上，通過統一的運營平臺作為中控單元，把整個業務中臺串起來，將業務邏輯與具體實現的分離。

數據中臺

數據中臺的核心在于從數據技術、數據資產、數據服務等各個層次，進行規范和標準化：

• 數據技術：數據如何采集，如何存儲，如何進行離線和實時計算。

• 數據資產：全域的數據治理，包括建模，數倉，數據集市等。

• 數據服務：包括對外和對內以產品，接口或者中間件形式提供的各種數據服務。

圖7 數據中臺實現真正的數據統一、實時、在線

因此，數據中臺將通過下面這些產品落地：

• 統一的數據采集、存儲、計算平臺。

• 統一的數據資產管理平臺。

• 統一的數據研發工具平臺。

• 豐富的數據服務，完備的數據集市和統一的接口/中間件。

業務中臺與數據中臺的關系

業務中臺和數據中臺是相互促進的關系：

• 業務中臺數據同步到數據中臺，結合外部生態數據，面向場景要求選擇(或設計)合適的算法，進行數據的計算，實現數據在洞察和預測方面的價值。

• 大數據分析的結果要能反饋到業務生產系統中，實現對外提供數據服務，對內提供數據驅動業務運營。

• 數據服務中心在這個架構中，肩負起業務中臺和數據中臺的雙向交互職能：一是通過數據中臺的能力負責業務中臺各中心對跨中心或業務場景下數據需求的收集、反饋和實現；另一方面負責將數據中臺的數據分析后的價值輻射給業務中臺其他中心。

總結

關于中臺的文章已經有很多了，本文主要是討論之前在負責貨車幫時的一些思路。總得來說，我認為：

中臺不是目的是手段，需要根據各個公司自己業務和團隊的情況來量身打造。

中臺建設需要強健的基礎設施，還需要組織架構、企業文化、流程制度等各個緯度的支撐。

負責建設中臺的團隊要有很強的業務抽象能力和很好的服務精神。

Footnotes

《企業IT架構轉型之道》

《企業應用架構模式》

《領域驅動設計》

有些地方稱基礎設施為技術中臺。我覺得基礎設施是國內外（國外叫 infrastructure）同行使用已久一說就懂的詞，沒有必要為了追求和「業務中臺」、「數據中臺」文字上的對稱就胡亂發明概念，而且這層很明顯不是跟其他兩個中臺平行的。

作者介紹：

李昊，西瓜創客 CTO，曾在 IBM，Ericsson，Myriad 等公司從事嵌入式、服務器端和客戶端系統的開發和團隊管理工作。2013 年開始創業，后加入 TestBird 擔任副總裁；2016 年加入貨車幫，負責云原生平臺、中間件、業務中臺、公共服務、運維安全等方面的工作。2018年起擔任貨車幫技術負責人，同時分管平臺產品和運營部門。

如果覺得本文對您有幫助，請點在看、分享朋友圈，感謝您的支持！

?-END-?

關注“技術領導力”公眾號

用故事講技術，有趣，有料！

想加入社區，跟100位互聯網大咖學習？

添加群助理Emma，注明“加群”

技術領導力社群

---

大家在看：

1.迷信中臺是一種病，得治

2.微信架構總監：10億日活場景下的微服務架構

3.雷軍、張小龍：為何高手的努力深入而輕松

4.阿里VP李飛飛：下一代云原生數據庫技術

5.淘寶App出那么大bug，不做Code Review？

6.京東商城，超大型電商系統架構實踐！

喜歡就點在看！

總結

以上是生活随笔為你收集整理的我是如何在一家独角兽公司做业务中台、数据中台的？8页ppt详解中台建设实践！...的全部內容，希望文章能夠幫你解決所遇到的問題。

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