點(diǎn)擊“技術(shù)領(lǐng)導(dǎo)力”關(guān)注???每天早上8:30推送

概述

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

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

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

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

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

一旦進(jìn)入具體實(shí)現(xiàn)的細(xì)節(jié)，各個(gè)公司的技術(shù)棧、上下文和團(tuán)隊(duì)發(fā)展階段各不一樣，往往沒有太大的參考意義，故本文不做過多討論。

是什么？

中臺的起源

中國有個(gè)好習(xí)慣是「治學(xué)先治史」，我們要了解中臺究竟是什么，可以看看它發(fā)展的歷史。

行業(yè)里面最早提出并實(shí)施「中臺戰(zhàn)略」的阿里內(nèi)部，關(guān)于它的起源有兩種說法：一個(gè)是馬老師 2015 年年中參觀 supercell 之后提出的¹；一個(gè)是阿里的工程師們針對業(yè)務(wù)上的挑戰(zhàn)參考美軍的發(fā)展提出的。

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

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

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

「中臺」和「平臺」的關(guān)系

中臺既然是一種架構(gòu)方式，那么看到「小前臺，大中臺」的時(shí)候，最容易有的困惑就是這跟以前行業(yè)里流行過的「厚平臺，薄應(yīng)用」的架構(gòu)方式有什么區(qū)別。

實(shí)際上，如果理解了企業(yè)級應(yīng)用的架構(gòu)難點(diǎn)，以及從服務(wù)化到平臺化再到中臺化的演變過程，就能非常清楚中臺架構(gòu)方式究竟是什么了。

層次與架構(gòu)

「架構(gòu)」在軟件行業(yè)是一個(gè)非常微妙的詞。

我覺得無論是最初的 C/S 架構(gòu)、B/S 架構(gòu)還是如今的微服務(wù)架構(gòu)，架構(gòu)的內(nèi)涵主要包括以下兩點(diǎn)：

• 是最高層次的系統(tǒng)分解和抽象。

• 是不易改變的設(shè)計(jì)方案和抉擇。

要想對系統(tǒng)進(jìn)行分解和抽象，找到不易改變的部分，主要的方法是分層。在計(jì)算機(jī)本身的架構(gòu)中，到處都有分層的例子：

• 系統(tǒng)：硬件層->HAL 層->OS 層->應(yīng)用組件或平臺->各種應(yīng)用。

• 網(wǎng)絡(luò)：不管是五層還是七層的分法，大體上都是硬件->鏈路->網(wǎng)絡(luò)->傳輸->應(yīng)用。

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

• 封裝細(xì)節(jié)，解除耦合：不如不用知道硬件細(xì)節(jié)就可以在 TCP 上構(gòu)建 FTP 服務(wù)，如果硬件層完全換了 FTP 服務(wù)也可以正常運(yùn)行。

• 有利于標(biāo)準(zhǔn)化：因?yàn)槊繉拥膶?shí)現(xiàn)相對自治，就容易形成每一層的標(biāo)準(zhǔn)化協(xié)議和運(yùn)行機(jī)制。

和網(wǎng)絡(luò)這樣體系架構(gòu)已經(jīng)非常成熟的系統(tǒng)相比，互聯(lián)網(wǎng)公司構(gòu)建的「企業(yè)級應(yīng)用」，難度主要在于：

• 復(fù)雜的數(shù)據(jù)層次：需要持久化并經(jīng)常變更的數(shù)據(jù)很多，需要打通和集成的外部異構(gòu)系統(tǒng)很多，數(shù)據(jù)狀態(tài)復(fù)雜訪問量大訪問方式異構(gòu)

• 復(fù)雜的業(yè)務(wù)邏輯：各種商業(yè)規(guī)則和潛規(guī)則形成的業(yè)務(wù)規(guī)則，還會隨時(shí)變化，軟件里沒有比業(yè)務(wù)邏輯更沒有邏輯的東西了

因?yàn)檫@兩方面的復(fù)雜性，對企業(yè)級應(yīng)用分層時(shí)最困難的問題就是究竟有哪些層次，每一層的職責(zé)和邊界是什么。到目前為止，最流行的做法是按照 Brown 的建議²把它分為三層。

• 表現(xiàn)層主要處理用戶與系統(tǒng)之間的交互：可以是 App 或網(wǎng)頁，也可以是桌面客戶端。

• 領(lǐng)域?qū)又饕翘幚砀鞣N業(yè)務(wù)領(lǐng)域內(nèi)的邏輯：包括數(shù)據(jù)抽取，規(guī)則計(jì)算等等的邏輯。

• 數(shù)據(jù)層主要是數(shù)據(jù)庫，消息隊(duì)列等進(jìn)行數(shù)據(jù)交互和持久化的工作。

各層的運(yùn)行環(huán)境

進(jìn)行了層次劃分之后，一個(gè)需要進(jìn)行的架構(gòu)選擇就是在哪里運(yùn)行這部分工作：是在服務(wù)器上，還是在用戶的機(jī)器上。

一個(gè)常見的誤區(qū)是把表現(xiàn)層直接對應(yīng)到前端應(yīng)用，領(lǐng)域?qū)又苯訉?yīng)到后端應(yīng)用。實(shí)際上表現(xiàn)層的大量邏輯有可能是在我們的服務(wù)器上渲染的。而隨著桌面電腦或者手機(jī)的處理能力和交互需求的提升，很多領(lǐng)域?qū)拥臉I(yè)務(wù)邏輯反而是在客戶端進(jìn)行處理的。舉個(gè)簡單的例子就是各種表單填寫時(shí)的字段校驗(yàn)，在過去是需要提交到后端進(jìn)行的，現(xiàn)在則有很多是監(jiān)聽用戶焦點(diǎn)離開當(dāng)前輸入框就進(jìn)行了。

因此，在確定各層的運(yùn)行環(huán)境的時(shí)候，核心是根據(jù)應(yīng)用本身的特點(diǎn)，考慮不同的運(yùn)行環(huán)境的優(yōu)劣點(diǎn)安排：運(yùn)行在客戶的機(jī)器上，好處是響應(yīng)性能和不依賴網(wǎng)絡(luò)；缺點(diǎn)是如何把變更同步到各個(gè)客戶的機(jī)器并且讓它有效（想想不同瀏覽器的兼容性）。

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

再比如表現(xiàn)層，我們希望給用戶很良好的響應(yīng)速度和用戶體驗(yàn)，所以可以在后端根據(jù)用戶畫像進(jìn)行千人千面的數(shù)據(jù)組織來給不同用戶組合不同的操作界面。同時(shí)我們又希望能夠?qū)蛻舳四軌蛴懈玫目刂屏?#xff0c;所以會打造客戶端的各種框架和組件。

架構(gòu)的核心難點(diǎn)

進(jìn)行了層次劃分和運(yùn)行環(huán)境的選擇之后，架構(gòu)的核心難點(diǎn)就在于如何抽象出：

標(biāo)準(zhǔn)的協(xié)議和運(yùn)行機(jī)制。

滿足標(biāo)準(zhǔn)的分布式執(zhí)行單元。

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

正是在這樣的抽象過程中，行業(yè)里提出了 SOA，微服務(wù)，服務(wù)網(wǎng)格等服務(wù)化到平臺化的解決方案（SOA 和微服務(wù)的一個(gè)很重要的區(qū)別是執(zhí)行單元和控制單元和通信方式，SOA 是有總線的）。而在三層里，如何對控制和處理復(fù)雜業(yè)務(wù)邏輯的領(lǐng)域?qū)舆M(jìn)行架構(gòu)是關(guān)鍵中的關(guān)鍵，它既是公司業(yè)務(wù)生態(tài)的基礎(chǔ)，也直接決定了業(yè)務(wù)探索的速度和業(yè)務(wù)創(chuàng)新的成本。

所以我們以領(lǐng)域?qū)訛槔?#xff0c;看看為什么需要業(yè)務(wù)平臺，它又如何演化到業(yè)務(wù)中臺。

業(yè)務(wù)中臺是什么

建設(shè)敏捷的前臺+強(qiáng)大的中臺，絕不是因?yàn)榘⒗锘蛘呔〇|做了，所以貨車幫要趕這個(gè)時(shí)髦。而是貨車幫本身的業(yè)務(wù)不斷發(fā)展下，技術(shù)體系的正確應(yīng)對策略。

子系統(tǒng)時(shí)期

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

最多的時(shí)候我們技術(shù)體系有 13 個(gè)中心組成，除開包括了用戶中心、活動中心等在內(nèi)的基礎(chǔ)服務(wù)中心，還有包括平臺業(yè)務(wù)中心（車貨匹配業(yè)務(wù)），車后業(yè)務(wù)中心等在內(nèi)的各個(gè)業(yè)務(wù)系統(tǒng)中心，以及大數(shù)據(jù)中心，運(yùn)維中心等。

這個(gè)階段的核心工作實(shí)際上是把數(shù)百人的團(tuán)隊(duì)拆分成了功能相對比較集中的小團(tuán)隊(duì)。每個(gè)獨(dú)立的系統(tǒng)可以獨(dú)立設(shè)計(jì)、獨(dú)立接需求、獨(dú)立發(fā)布，整個(gè)研發(fā)交付速度和系統(tǒng)穩(wěn)定性扛住了業(yè)務(wù)高速發(fā)展的需要。

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

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

平臺化時(shí)期

從一個(gè)個(gè)的中心到平臺化，核心是業(yè)務(wù)抽象建模和保持系統(tǒng)架構(gòu)的開放性：

• 拉通考慮各個(gè)業(yè)務(wù)的邏輯，把基礎(chǔ)能力抽象出來，解決共性的 80%問題。

• 系統(tǒng)架構(gòu)上保持開放性可擴(kuò)展性，把業(yè)務(wù)和業(yè)務(wù)之間不同的邏輯隔離并進(jìn)行封裝，解決 20%的個(gè)性化問題。

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

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

圖1 子系統(tǒng)到平臺化的架構(gòu)升級

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

• 抽象共性，減少重復(fù)建設(shè)投入的人力和時(shí)間成本。

• 快速支撐，提高需求到研發(fā)上線到效果復(fù)盤各環(huán)節(jié)效率。

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

那么我們?yōu)槭裁从忠浦信_戰(zhàn)略了呢？

中臺解決的問題

我們以一個(gè)新業(yè)務(wù)負(fù)責(zé)人的視角就很容易想通平臺化的問題了。

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

首先，平臺是提供抽象出來的共性功能，每個(gè)團(tuán)隊(duì)專注自己的事情，提升效率。但這樣雖然帶來了專業(yè)，卻很容易導(dǎo)致「各家自掃門前雪」，對于創(chuàng)新業(yè)務(wù)的支持力度不足。

所以，就會出現(xiàn)類似下圖的問題：當(dāng)公司的保險(xiǎn)業(yè)務(wù)負(fù)責(zé)人想要進(jìn)行某個(gè)新功能的開發(fā)時(shí)，經(jīng)過反復(fù)溝通，發(fā)現(xiàn)自己的團(tuán)隊(duì)承擔(dān)的部分可以在兩天之類完成開發(fā)，但是依賴的團(tuán)隊(duì)對這相關(guān)功能的排期可能排到了兩三周后面。

圖2 業(yè)務(wù)平臺帶來的「各家自掃門前雪」

最后也是最大的問題是，領(lǐng)域的平臺化解決了領(lǐng)域?qū)觾?nèi)部的問題，但業(yè)務(wù)的執(zhí)行都是跨領(lǐng)域的。涉及用戶、商品、交易、營銷、支付、服務(wù)等等環(huán)節(jié)，橫跨多個(gè)系統(tǒng)。如何把多個(gè)平臺的數(shù)據(jù)集成到一起并加工分析而產(chǎn)生新的支持到業(yè)務(wù)的價(jià)值，變得非常困難。從當(dāng)時(shí)的實(shí)際情況看，按照平臺化的架構(gòu)方式，基本上是沒有辦法做數(shù)據(jù)驅(qū)動運(yùn)營的。

因此，平臺化之后雖然解決了煙囪式架構(gòu)的很多問題，但是隨著公司的發(fā)展，整個(gè)組織的效率仍然會逐漸降低。這不是一個(gè)技術(shù)問題，而是一個(gè)復(fù)雜生態(tài)下的協(xié)作問題。要解決這樣的問題，就要通過打造中臺來解決前面說的企業(yè)級應(yīng)用架構(gòu)的三個(gè)核心難點(diǎn)：

標(biāo)準(zhǔn)的協(xié)議和運(yùn)行機(jī)制。

滿足標(biāo)準(zhǔn)的分布式執(zhí)行單元。

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

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

• 提供完整解決方案而不是暴露 API，給業(yè)務(wù)帶來的快速創(chuàng)新和試錯(cuò)能力的提升。

• 通過數(shù)據(jù)統(tǒng)一治理和應(yīng)用，給業(yè)務(wù)帶來數(shù)據(jù)驅(qū)動的運(yùn)營能力的提升。

• 通過解決信息獲取成本高，系統(tǒng)互聯(lián)互通成本高的問題，給企業(yè)帶來組織效率的提升。

中臺建設(shè)的前提和難點(diǎn)

中臺建設(shè)的前提也是難點(diǎn)有兩個(gè)。

第一個(gè)是要需要有穩(wěn)健的基礎(chǔ)設(shè)施：

系統(tǒng)性解決復(fù)雜度。

系統(tǒng)性解決高可用，高并發(fā)。

系統(tǒng)性解決開發(fā)測試環(huán)境一致性和便利性。

能夠做好具備這三個(gè)能力的基礎(chǔ)設(shè)施，要求公司具備較強(qiáng)的 IaaS/PaaS 層的建設(shè)能力。

第二個(gè)難點(diǎn)，在于中臺本身的建設(shè)過程中，如何進(jìn)行抽象和劃分邊界。

但從技術(shù)架構(gòu)上來說，常見的抽象方式有兩種：

按照信息流、資金流、數(shù)據(jù)流等等的構(gòu)成 element 和 process，自上而下進(jìn)行抽象。

按照對應(yīng)一個(gè)個(gè)數(shù)據(jù)單元的 entity 以及這些 entity 的狀態(tài)和轉(zhuǎn)移，進(jìn)行自下而上的抽象。

前者是更加常見也容易入手的方式，但是擴(kuò)展性較差。后者則更加面向領(lǐng)域內(nèi)的模型³，具有更好的健壯性，能夠支撐更多的業(yè)務(wù)場景。

但需要注意的是，對系統(tǒng)邊界的劃分，通常不是一個(gè)簡單的技術(shù)架構(gòu)的問題，而是牽扯到流程設(shè)計(jì)、組織架構(gòu)、業(yè)務(wù)歸屬等在內(nèi)的極其復(fù)雜的挑戰(zhàn)。

因此，進(jìn)行中臺建設(shè)一個(gè)隱含的前提，是公司的文化有一定成熟度，并且核心管理團(tuán)隊(duì)和骨干成員有一致的目標(biāo)。摩擦在所難免，解決的辦法更多不是靠的技術(shù)。

做什么？

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

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

別人做了什么？

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

核心三大部分：

• 基礎(chǔ)設(shè)施：一套支撐分布式服務(wù)研發(fā)、上線和運(yùn)營的基礎(chǔ)設(shè)施⁴。

• 業(yè)務(wù)中臺：包括了用戶中心、交易中心、搜索中心、營銷中心等在內(nèi)的業(yè)務(wù)中臺

• 數(shù)據(jù)中臺：包括了數(shù)據(jù)技術(shù)，數(shù)據(jù)資產(chǎn)管理，數(shù)據(jù)服務(wù)等各個(gè)層次的數(shù)據(jù)中臺。

我們的總體架構(gòu)

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

• 前端和接入層

• 前臺業(yè)務(wù)

• 業(yè)務(wù)中臺和數(shù)據(jù)中臺

• 基礎(chǔ)設(shè)施

• 企業(yè)效能和運(yùn)維保障體系

圖4 整體系統(tǒng)架構(gòu)：前臺/中臺/后臺

這套架構(gòu)的核心目的，是在更快更好的支撐公司進(jìn)行業(yè)務(wù)創(chuàng)新的同時(shí)，賦予業(yè)務(wù)真正的數(shù)據(jù)驅(qū)動運(yùn)營的能力，從而在提升組織效率的同時(shí)，為發(fā)揮大數(shù)據(jù)的威力奠定基礎(chǔ)。

基礎(chǔ)設(shè)施

圖5 貨車幫面向云原生的基礎(chǔ)設(shè)施

包括云原生平臺 Newton 在內(nèi)的基礎(chǔ)設(shè)施的設(shè)計(jì)和開發(fā)，以及統(tǒng)一規(guī)劃和提供的企業(yè)效能和運(yùn)維保障能力，過去已經(jīng)有過不少分享，這里就不再贅述。

但需要再次強(qiáng)調(diào)的是，如果沒有一套足夠好的基礎(chǔ)設(shè)施，最好先不要開始進(jìn)行中臺的建設(shè)。

業(yè)務(wù)中臺

業(yè)務(wù)中臺的核心建設(shè)步驟是：

從業(yè)務(wù)領(lǐng)域的邊界是什么，提供的基礎(chǔ)服務(wù)是什么，領(lǐng)域服務(wù)和領(lǐng)域服務(wù)之間的流程鏈接標(biāo)準(zhǔn)是什么等角度，抽象出模型、規(guī)則和協(xié)議

基于這些模型、規(guī)則和協(xié)議，建立業(yè)務(wù)實(shí)施標(biāo)準(zhǔn)和管控標(biāo)準(zhǔn)。

根據(jù)實(shí)施和管控標(biāo)準(zhǔn)，提供權(quán)限集中管理、流程靈活可配的工具和引擎。

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

以中臺化之后的用戶中心為例，它將不再只是提供用戶注冊審核相關(guān)的 API 或者類庫，而是需要站在公司業(yè)務(wù)特點(diǎn)上建立物流領(lǐng)域的包括用戶認(rèn)證，用戶審核，用戶評價(jià)，用戶等級，用戶畫像等在內(nèi)的用戶標(biāo)準(zhǔn)體系，并且負(fù)責(zé)所有相關(guān)的系統(tǒng)開發(fā)、業(yè)務(wù)協(xié)同和評價(jià)機(jī)制搭建，最終形成完整的能力地圖，通過工具和協(xié)議開放。

再比如，以訂單的創(chuàng)建過程為例，我們傳統(tǒng)的做法。需要梳理從能力規(guī)范、運(yùn)行機(jī)制到配置管理和執(zhí)行系統(tǒng)以及運(yùn)營服務(wù)團(tuán)隊(duì)構(gòu)成的整套標(biāo)準(zhǔn)，才能真正為各業(yè)務(wù)方提供快速、低成本的創(chuàng)新能力。

圖6 通過業(yè)務(wù)中臺，為各個(gè)前臺業(yè)務(wù)提供統(tǒng)一的訂單處理能力

最終，業(yè)務(wù)中臺將通過各種層面的產(chǎn)品和服務(wù)來落地：

• 業(yè)務(wù)能力圖譜。

• 業(yè)務(wù)需求分解和配置的工具。

• 業(yè)務(wù)流程設(shè)計(jì)和配置的工具。

• 業(yè)務(wù)指標(biāo)度量和跟蹤的工具。

基于這些產(chǎn)品，把每個(gè)業(yè)務(wù)它是怎么出來的，出來之后做了哪些業(yè)務(wù)需求和業(yè)務(wù)活動，每個(gè)業(yè)務(wù)活動的效果是怎么樣的，都沉淀下來。在此基礎(chǔ)上，通過統(tǒng)一的運(yùn)營平臺作為中控單元，把整個(gè)業(yè)務(wù)中臺串起來，將業(yè)務(wù)邏輯與具體實(shí)現(xiàn)的分離。

數(shù)據(jù)中臺

數(shù)據(jù)中臺的核心在于從數(shù)據(jù)技術(shù)、數(shù)據(jù)資產(chǎn)、數(shù)據(jù)服務(wù)等各個(gè)層次，進(jìn)行規(guī)范和標(biāo)準(zhǔn)化：

• 數(shù)據(jù)技術(shù)：數(shù)據(jù)如何采集，如何存儲，如何進(jìn)行離線和實(shí)時(shí)計(jì)算。

• 數(shù)據(jù)資產(chǎn)：全域的數(shù)據(jù)治理，包括建模，數(shù)倉，數(shù)據(jù)集市等。

• 數(shù)據(jù)服務(wù)：包括對外和對內(nèi)以產(chǎn)品，接口或者中間件形式提供的各種數(shù)據(jù)服務(wù)。

圖7 數(shù)據(jù)中臺實(shí)現(xiàn)真正的數(shù)據(jù)統(tǒng)一、實(shí)時(shí)、在線

因此，數(shù)據(jù)中臺將通過下面這些產(chǎn)品落地：

• 統(tǒng)一的數(shù)據(jù)采集、存儲、計(jì)算平臺。

• 統(tǒng)一的數(shù)據(jù)資產(chǎn)管理平臺。

• 統(tǒng)一的數(shù)據(jù)研發(fā)工具平臺。

• 豐富的數(shù)據(jù)服務(wù)，完備的數(shù)據(jù)集市和統(tǒng)一的接口/中間件。

業(yè)務(wù)中臺與數(shù)據(jù)中臺的關(guān)系

業(yè)務(wù)中臺和數(shù)據(jù)中臺是相互促進(jìn)的關(guān)系：

• 業(yè)務(wù)中臺數(shù)據(jù)同步到數(shù)據(jù)中臺，結(jié)合外部生態(tài)數(shù)據(jù)，面向場景要求選擇(或設(shè)計(jì))合適的算法，進(jìn)行數(shù)據(jù)的計(jì)算，實(shí)現(xiàn)數(shù)據(jù)在洞察和預(yù)測方面的價(jià)值。

• 大數(shù)據(jù)分析的結(jié)果要能反饋到業(yè)務(wù)生產(chǎn)系統(tǒng)中，實(shí)現(xiàn)對外提供數(shù)據(jù)服務(wù)，對內(nèi)提供數(shù)據(jù)驅(qū)動業(yè)務(wù)運(yùn)營。

• 數(shù)據(jù)服務(wù)中心在這個(gè)架構(gòu)中，肩負(fù)起業(yè)務(wù)中臺和數(shù)據(jù)中臺的雙向交互職能：一是通過數(shù)據(jù)中臺的能力負(fù)責(zé)業(yè)務(wù)中臺各中心對跨中心或業(yè)務(wù)場景下數(shù)據(jù)需求的收集、反饋和實(shí)現(xiàn)；另一方面負(fù)責(zé)將數(shù)據(jù)中臺的數(shù)據(jù)分析后的價(jià)值輻射給業(yè)務(wù)中臺其他中心。

總結(jié)

關(guān)于中臺的文章已經(jīng)有很多了，本文主要是討論之前在負(fù)責(zé)貨車幫時(shí)的一些思路。總得來說，我認(rèn)為：

中臺不是目的是手段，需要根據(jù)各個(gè)公司自己業(yè)務(wù)和團(tuán)隊(duì)的情況來量身打造。

中臺建設(shè)需要強(qiáng)健的基礎(chǔ)設(shè)施，還需要組織架構(gòu)、企業(yè)文化、流程制度等各個(gè)緯度的支撐。

負(fù)責(zé)建設(shè)中臺的團(tuán)隊(duì)要有很強(qiáng)的業(yè)務(wù)抽象能力和很好的服務(wù)精神。

Footnotes

《企業(yè)IT架構(gòu)轉(zhuǎn)型之道》

《企業(yè)應(yīng)用架構(gòu)模式》

《領(lǐng)域驅(qū)動設(shè)計(jì)》

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

作者介紹：

李昊，西瓜創(chuàng)客 CTO，曾在 IBM，Ericsson，Myriad 等公司從事嵌入式、服務(wù)器端和客戶端系統(tǒng)的開發(fā)和團(tuán)隊(duì)管理工作。2013 年開始創(chuàng)業(yè)，后加入 TestBird 擔(dān)任副總裁；2016 年加入貨車幫，負(fù)責(zé)云原生平臺、中間件、業(yè)務(wù)中臺、公共服務(wù)、運(yùn)維安全等方面的工作。2018年起擔(dān)任貨車幫技術(shù)負(fù)責(zé)人，同時(shí)分管平臺產(chǎn)品和運(yùn)營部門。

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

?-END-?

關(guān)注“技術(shù)領(lǐng)導(dǎo)力”公眾號

用故事講技術(shù)，有趣，有料！

想加入社區(qū)，跟100位互聯(lián)網(wǎng)大咖學(xué)習(xí)？

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

技術(shù)領(lǐng)導(dǎo)力社群

---

大家在看：

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

2.微信架構(gòu)總監(jiān)：10億日活場景下的微服務(wù)架構(gòu)

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

4.阿里VP李飛飛：下一代云原生數(shù)據(jù)庫技術(shù)

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

6.京東商城，超大型電商系統(tǒng)架構(gòu)實(shí)踐！

喜歡就點(diǎn)在看！

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。