某獨(dú)角獸公司的業(yè)務(wù)中臺(tái)：打鐵硬,不跟風(fēng)

某獨(dú)角獸公司的業(yè)務(wù)中臺(tái)：打鐵硬，不跟風(fēng)概述中臺(tái)這個(gè)詞火爆挺久了。但從阿里2015年提出并開始實(shí)施，發(fā)展到目前為止，并沒有「標(biāo)準(zhǔn)化」：換句話說，它跟「人工智能」，「大數(shù)據(jù)」，「微服務(wù)」一樣，具體的含義在不同公司不同時(shí)期的不同上下文里，有著千差萬別的含義。并且和這些詞不太一樣的是，它是一個(gè)在中文技術(shù)圈被頻繁使用，但在其他語言環(huán)境下幾乎找不到的詞。所以我常跟身邊的朋友說，關(guān)于它的爭(zhēng)議特別多，大家不用感覺奇怪，可以參考中醫(yī)。本文的主要目的，是總結(jié)一下過去在中臺(tái)架構(gòu)和建設(shè)的過程中的思路和方法，方便大家對(duì)「中臺(tái)」有一個(gè)相對(duì)一致的概念和邊界，從而在后續(xù)的工作中更好地進(jìn)行思考、討論和選擇。因此內(nèi)容主要集中在：中臺(tái)是什么：我們對(duì)中臺(tái)的理解是怎樣的。中臺(tái)做什么：我們做出判斷和選擇的思路是怎樣的。一旦進(jìn)入具體實(shí)現(xiàn)的細(xì)節(jié)，各個(gè)公司的技術(shù)棧、上下文和團(tuán)隊(duì)發(fā)展階段各不一樣，往往沒有太大的參考意義，故本文不做過多討論。是什么？中臺(tái)的起源中國有個(gè)好習(xí)慣是「治學(xué)先治史」，我們要了解中臺(tái)究竟是什么，可以看看它發(fā)展的歷史。行業(yè)里面最早提出并實(shí)施「中臺(tái)戰(zhàn)略」的阿里內(nèi)部，關(guān)于它的起源有兩種說法：一個(gè)是馬老師2015年年中參觀supercell之后提出的1；一個(gè)是阿里的工程師們針對(duì)業(yè)務(wù)上的挑戰(zhàn)參考美軍的發(fā)展提出的。supercell是一家人數(shù)只有不到百人，卻連續(xù)推出了《部落戰(zhàn)爭(zhēng)》等多款爆款游戲，先后被軟銀和騰訊投資數(shù)十億美金的游戲行業(yè)的傳奇公司。它最大的特色就是內(nèi)部以小團(tuán)隊(duì)（cell）形式作戰(zhàn)，每個(gè)cell最多不超過7人。這些小團(tuán)隊(duì)依靠公司提供的公共的后端架構(gòu)、引擎、算法、美術(shù)等中臺(tái)資源，按照幾周的時(shí)間周期推出大量新游戲，快速試錯(cuò)。美軍則是從一戰(zhàn)時(shí)的按「軍」為單位作戰(zhàn)，到越戰(zhàn)時(shí)按「營」為單位作戰(zhàn)，逐步演進(jìn)為「突擊隊(duì)+航母」的方式進(jìn)行作戰(zhàn)。前線突擊隊(duì)通常7到11人，有著中后臺(tái)的強(qiáng)大支持（包括各種資源上的保障支持，衛(wèi)星和無人機(jī)提供的偵查能力，高精度導(dǎo)彈的炮火支持等等），可以靈活選擇戰(zhàn)術(shù)并引領(lǐng)整個(gè)進(jìn)攻高效完成?？梢姡瑹o論這兩種說法哪種準(zhǔn)確，中臺(tái)戰(zhàn)略主要都是指通過「小前臺(tái)，大中臺(tái)」的架構(gòu)方式，降低試錯(cuò)成本，加快響應(yīng)速度，從而真正做到「降本增效」?！钢信_(tái)」和「平臺(tái)」的關(guān)系中臺(tái)既然是一種架構(gòu)方式，那么看到「小前臺(tái)，大中臺(tái)」的時(shí)候，最容易有的困惑就是這跟以前行業(yè)里流行過的「厚平臺(tái)，薄應(yīng)用」的架構(gòu)方式有什么區(qū)別。實(shí)際上，如果理解了企業(yè)級(jí)應(yīng)用的架構(gòu)難點(diǎn)，以及從服務(wù)化到平臺(tái)化再到中臺(tái)化的演變過程，就能非常清楚中臺(tái)架構(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ì)方案和抉擇。要想對(duì)系統(tǒng)進(jìn)行分解和抽象，找到不易改變的部分，主要的方法是分層。在計(jì)算機(jī)本身的架構(gòu)中，到處都有分層的例子：?系統(tǒng)：硬件層->HAL層->OS層->應(yīng)用組件或平臺(tái)->各種應(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)相對(duì)自治，就容易形成每一層的和網(wǎng)絡(luò)這樣體系架構(gòu)已經(jīng)非常成熟的系統(tǒng)相比，互聯(lián)網(wǎng)公司構(gòu)建的「企業(yè)級(jí)應(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ī)則，還會(huì)隨時(shí)變化，軟件里沒有比業(yè)務(wù)邏輯更沒有邏輯的東西了因?yàn)檫@兩方面的復(fù)雜性，對(duì)企業(yè)級(jí)應(yīng)用分層時(shí)最困難的問題就是究竟有哪些層次，每一層的職責(zé)和邊界是什么。到目前為止，最流行的做法是按照Brown的建議2把它分為三層。?表現(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)層直接對(duì)應(yīng)到前端應(yīng)用，領(lǐng)域?qū)又苯訉?duì)應(yīng)到后端應(yīng)用。實(shí)際上表現(xiàn)層的大量邏輯有可能是在我們的服務(wù)器上渲染的。而隨著桌面電腦或者手機(jī)的處理能力和交互需求的提升，很多領(lǐng)域?qū)拥臉I(yè)務(wù)邏輯反而是在客戶端進(jìn)行處理的。舉個(gè)簡(jiǎn)單的例子就是各種表單填寫時(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)，所以我們各級(jí)的緩存里有不少是部署在客戶端的。再比如表現(xiàn)層，我們希望給用戶很良好的響應(yīng)速度和用戶體驗(yàn)，所以可以在后端根據(jù)用戶畫像進(jìn)行千人千面的數(shù)據(jù)組織來給不同用戶組合不同的操作界面。同時(shí)我們又希望能夠?qū)蛻舳四軌蛴懈玫目刂屏Γ詴?huì)打造客戶端的各種框架和組件。架構(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ù)化到平臺(tái)化的解決方案（SOA和微服務(wù)的一個(gè)很重要的區(qū)別是執(zhí)行單元和控制單元和通信方式，SOA是有總線的）。而在三層里，如何對(duì)控制和處理復(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ū)訛槔?，看看為什么需要業(yè)務(wù)平臺(tái)，它又如何演化到業(yè)務(wù)中臺(tái)。業(yè)務(wù)中臺(tái)是什么建設(shè)敏捷的前臺(tái)+強(qiáng)大的中臺(tái)，絕不是因?yàn)榘⒗锘蛘呔〇|做了，所以貨車幫要趕這個(gè)時(shí)髦。而是貨車幫本身的業(yè)務(wù)不斷發(fā)展下，技術(shù)體系的正確應(yīng)對(duì)策略。子系統(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è)中心組成，除開包括了用戶中心、活動(dòng)中心等在內(nèi)的基礎(chǔ)服務(wù)中心，還有包括平臺(tái)業(yè)務(wù)中心（車貨匹配業(yè)務(wù)），車后業(yè)務(wù)中心等在內(nèi)的各個(gè)業(yè)務(wù)系統(tǒng)中心，以及大數(shù)據(jù)中心，運(yùn)維中心等。這個(gè)階段的核心工作實(shí)際上是把數(shù)百人的團(tuán)隊(duì)拆分成了功能相對(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)對(duì)每天的業(yè)務(wù)需求變更，所有的員工都在加班加點(diǎn)，但由于在業(yè)務(wù)抽象建模，系統(tǒng)架構(gòu)的開放性等方面考慮不足，導(dǎo)致業(yè)務(wù)邏輯之間的耦合和相互影響，研發(fā)質(zhì)量和效率大幅下降。這種見招拆招，垂直發(fā)展，未做足夠抽象通用的架構(gòu)行業(yè)里稱之為「煙囪型架構(gòu)」，解決這種問題通常就需要平臺(tái)化了。從一個(gè)個(gè)的中心到平臺(tái)化，核心是業(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ù)都需要用戶注冊(cè)和審核的功能，所以我們通過用戶平臺(tái)來提供統(tǒng)一的接口。而不同業(yè)務(wù)比如車貨匹配業(yè)務(wù)和車油業(yè)務(wù)對(duì)司機(jī)審核的力度要求是不同的，前者需要司機(jī)提供駕照等證件，后者可能就寬松很多。平臺(tái)要把不同業(yè)務(wù)的邏輯隔離開進(jìn)行封裝，對(duì)外提供一致的接口。再比如營銷活動(dòng)，各個(gè)業(yè)務(wù)都要做。我們就可以抽象出一個(gè)從設(shè)計(jì)，上線，到數(shù)據(jù)收集全生命周期管理的活動(dòng)平臺(tái)，提供給各個(gè)業(yè)務(wù)使用。但是各個(gè)業(yè)務(wù)具體的活動(dòng)邏輯要做到很好的封裝，就需要建立元數(shù)據(jù)中心、規(guī)則中心、活動(dòng)界面自動(dòng)生成、活動(dòng)數(shù)

據(jù)自動(dòng)埋點(diǎn)等等。車副臨據(jù)自動(dòng)埋點(diǎn)等等。車副臨圖1子系統(tǒng)到平臺(tái)化的架構(gòu)升級(jí)平臺(tái)化的核心收益其實(shí)就是降本增效:?抽象共性，減少重復(fù)建設(shè)投入的人力和時(shí)間成本。?快速支撐，提高需求到研發(fā)上線到效果復(fù)盤各環(huán)節(jié)效率。平臺(tái)化的過程一般都會(huì)經(jīng)歷從API治理和提供，到服務(wù)化，到最終形成平臺(tái)的過程，所以各個(gè)平臺(tái)并不會(huì)在同一天完成。實(shí)際上，一直到貨車幫開始建設(shè)中臺(tái)的時(shí)候，仍然有很多平臺(tái)正在建設(shè)中。那么我們?yōu)槭裁从忠浦信_(tái)戰(zhàn)略了呢？我們以一個(gè)新業(yè)務(wù)負(fù)責(zé)人的視角就很容易想通平臺(tái)化的問題了。首先，作為各個(gè)業(yè)務(wù)的負(fù)責(zé)人，要了解各個(gè)平臺(tái)的功能和職責(zé)并且推動(dòng)合作很困難。做一個(gè)新功能的MVP究竟需要多少人多少時(shí)間甚至都算不出來。首先，平臺(tái)是提供抽象出來的共性功能，每個(gè)團(tuán)隊(duì)專注自己的事情，提升效率。但這樣雖然帶來了專業(yè)，卻很容易導(dǎo)致「各家自掃門前雪」，對(duì)于創(chuàng)新業(yè)務(wù)的支持力度不足。所以，就會(huì)出現(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ì)對(duì)這相關(guān)功能的排期可能排到了兩三周后面。

業(yè)務(wù)單元車油業(yè)務(wù) 新車業(yè)務(wù)保險(xiǎn)業(yè)務(wù)輪胎業(yè)務(wù)小貸業(yè)務(wù) 白條業(yè)務(wù)用掛業(yè)務(wù)集卡業(yè)務(wù)工作量三天!::工作量三天：:

割嘲二周后！工作量兩天：:排期三周后''排期二周后!基礎(chǔ)設(shè)施工作量三天!::工作量三天：:

割嘲二周后！工作量兩天：:排期三周后''排期二周后!基礎(chǔ)服務(wù)（短信/定位/推送/對(duì)象存儲(chǔ)/即時(shí)通信/…）基她設(shè)施（前后端框架/統(tǒng)一監(jiān)控/服務(wù)治理/中間件服勞/容器平臺(tái)/…）:工作量兩天！■ J:排期三周后！圖2業(yè)務(wù)平臺(tái)帶來的「各家自掃門前雪」工作量三天;排期二周后!最后也是最大的問題是，領(lǐng)域的平臺(tái)化解決了領(lǐng)域?qū)觾?nèi)部的問題，但業(yè)務(wù)的執(zhí)行都是跨領(lǐng)域的。涉及用戶、商品、交易、營銷、支付、服務(wù)等等環(huán)節(jié)，橫跨多個(gè)系統(tǒng)。如何把多個(gè)平臺(tái)的數(shù)據(jù)集成到一起并加工分析而產(chǎn)生新的支持到業(yè)務(wù)的價(jià)值，變得非常困難。從當(dāng)時(shí)的實(shí)際情況看，按照平臺(tái)化的架構(gòu)方式，基本上是沒有辦法做數(shù)據(jù)驅(qū)動(dòng)運(yùn)營的。因此，平臺(tái)化之后雖然解決了煙囪式架構(gòu)的很多問題，但是隨著公司的發(fā)展，整個(gè)組織的效率仍然會(huì)逐漸降低。這不是一個(gè)技術(shù)問題，而是一個(gè)復(fù)雜生態(tài)下的協(xié)作問題。要解決這樣的問題，就要通過打造中臺(tái)來解決前面說的企業(yè)級(jí)應(yīng)用架構(gòu)的三個(gè)核心難點(diǎn):標(biāo)準(zhǔn)的協(xié)議和運(yùn)行機(jī)制。滿足標(biāo)準(zhǔn)的分布式執(zhí)行單元。去中心化或中心化的控制單元。所以，中臺(tái)化其實(shí)是平臺(tái)化之后的自然階段，它主要是帶來了：?提供完整解決方案而不是暴露API，給業(yè)務(wù)帶來的快速創(chuàng)新和試錯(cuò)能力的提升。?通過數(shù)據(jù)統(tǒng)一治理和應(yīng)用，給業(yè)務(wù)帶來數(shù)據(jù)驅(qū)動(dòng)的運(yùn)營能力的提升。?通過解決信息獲取成本高，系統(tǒng)互聯(lián)互通成本高的問題，給企業(yè)帶來組織效率的提升。中臺(tái)建設(shè)的前提也是難點(diǎn)有兩個(gè)：第一個(gè)是要需要有穩(wěn)健的基礎(chǔ)設(shè)施：系統(tǒng)性解決復(fù)雜度。系統(tǒng)性解決高可用，高并發(fā)。系統(tǒng)性解決開發(fā)測(cè)試環(huán)境一致性和便利性。能夠做好具備這三個(gè)能力的基礎(chǔ)設(shè)施，要求公司具備較強(qiáng)的IaaS/PaaS層的建設(shè)能力。第二個(gè)難點(diǎn)，在于中臺(tái)本身的建設(shè)過程中，如何進(jìn)行抽象和劃分邊界。但從技術(shù)架構(gòu)上來說，常見的抽象方式有兩種：按照信息流、資金流、數(shù)據(jù)流等等的構(gòu)成element和process，自上而下進(jìn)行抽象。

2.按照對(duì)應(yīng)一個(gè)個(gè)數(shù)據(jù)單元的 entity以及這些entity的狀態(tài)和轉(zhuǎn)移，進(jìn)行自下而上的抽象。前者是更加常見也容易入手的方式，但是擴(kuò)展性較差。后者則更加面向領(lǐng)域內(nèi)的模型3,具有更好的健壯性，能夠支撐更多的業(yè)務(wù)場(chǎng)景。但需要注意的是，對(duì)系統(tǒng)邊界的劃分，通常不是一個(gè)簡(jiǎn)單的技術(shù)架構(gòu)的問題，而是牽扯到流程設(shè)計(jì)、組織架構(gòu)、業(yè)務(wù)歸屬等在內(nèi)的極其復(fù)雜的挑戰(zhàn)。因此，進(jìn)行中臺(tái)建設(shè)一個(gè)隱含的前提，是公司的文化有一定成熟度，并且核心管理團(tuán)隊(duì)和骨干成員有一致的目標(biāo)。摩擦在所難免，解決的辦法更多不是靠的技術(shù)。做什么？理解了中臺(tái)是什么，我們來看看做什么。一個(gè)很好的做法是，先看看別人做了什么。別人做了什么？AliEKpreu阿里田巴集團(tuán)天琳蛔算「商品中心交易中心AliEKpreu阿里田巴集團(tuán)天琳蛔算「商品中心交易中心圖3阿里中臺(tái)架構(gòu)圖-摘自云棲大會(huì)分享核心三大部分：基礎(chǔ)設(shè)施：一套支撐分布式服務(wù)研發(fā)、上線和運(yùn)營的基礎(chǔ)設(shè)施4。?業(yè)務(wù)中臺(tái)：包括了用戶中心、交易中心、搜索中心、營銷中心等在內(nèi)的業(yè)務(wù)中臺(tái)?數(shù)據(jù)中臺(tái)：包括了數(shù)據(jù)技術(shù)，數(shù)據(jù)資產(chǎn)管理，數(shù)據(jù)服務(wù)等各個(gè)層次的數(shù)據(jù)中臺(tái)。根據(jù)我們對(duì)中臺(tái)的理解，并參考其他公司的做法，貨車幫的總體架構(gòu)是：?前端和接入層?前臺(tái)業(yè)務(wù)?業(yè)務(wù)中臺(tái)和數(shù)據(jù)中臺(tái)?基礎(chǔ)設(shè)施?企業(yè)效能和運(yùn)維保障體系

圖4圖4整體系統(tǒng)架構(gòu)：前臺(tái)/中臺(tái)/后臺(tái)這套架構(gòu)的核心目的，是在更快更好的支撐公司進(jìn)行業(yè)務(wù)創(chuàng)新的同時(shí)，賦予業(yè)務(wù)真正的數(shù)據(jù)驅(qū)動(dòng)運(yùn)營的能力，從而在提升組織效率的同時(shí)，為發(fā)揮大數(shù)據(jù)的威力奠定基礎(chǔ)?；A(chǔ)設(shè)施華構(gòu)協(xié)云原生平臺(tái)圖5貨車幫面向云原生的基礎(chǔ)設(shè)施圖5貨車幫面向云原生的基礎(chǔ)設(shè)施包括云原生平臺(tái)Newton在內(nèi)的基礎(chǔ)設(shè)施的設(shè)計(jì)和開發(fā)，以及統(tǒng)一規(guī)劃和提供的企業(yè)效能和運(yùn)維保障能力，過去已經(jīng)有過不少分享，這里就不再贅述。但需要再次強(qiáng)調(diào)的是，如果沒有一套足夠好的基礎(chǔ)設(shè)施，最好先不要開始進(jìn)行中臺(tái)的建設(shè)。業(yè)務(wù)中臺(tái)業(yè)務(wù)中臺(tái)的核心建設(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)限集中管理、流程靈活可配的工具和引擎。也就是說，如果還是像平臺(tái)化階段，通過一堆API來暴露能力，那就不是「中臺(tái)」。以中臺(tái)化之后的用戶中心為例，它將不再只是提供用戶注冊(cè)審核相關(guān)的API或者類庫，而是需要站在公司業(yè)務(wù)特點(diǎn)上建立物流領(lǐng)域的包括用戶認(rèn)證，用戶審核，用戶評(píng)價(jià)，用戶等級(jí)，用戶畫像等在內(nèi)的用戶標(biāo)準(zhǔn)體系，并且負(fù)責(zé)所有相關(guān)的系統(tǒng)開發(fā)、業(yè)務(wù)協(xié)同和評(píng)價(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ù)中臺(tái)，為各個(gè)前臺(tái)業(yè)務(wù)提供統(tǒng)一的訂單處理能力最終，業(yè)務(wù)中臺(tái)將通過各種層面的產(chǎn)品和服務(wù)來落地:?業(yè)務(wù)能力圖譜。?業(yè)務(wù)需求分解和配置的工具。?業(yè)務(wù)流程設(shè)計(jì)和配置的工具。?業(yè)務(wù)指標(biāo)度量和跟蹤的工具?；谶@些產(chǎn)品，把每個(gè)業(yè)務(wù)它是怎么出來的，出來之后做了哪些業(yè)務(wù)需求和業(yè)務(wù)活動(dòng)，每個(gè)業(yè)務(wù)活動(dòng)的效果是怎么樣的，都沉淀下來。在此基礎(chǔ)上，通過統(tǒng)一的運(yùn)營平臺(tái)作為中控單元，把整個(gè)業(yè)務(wù)中臺(tái)串起來，將業(yè)務(wù)邏輯與具體實(shí)現(xiàn)的分離。 數(shù)據(jù)中臺(tái)的核心在于從數(shù)據(jù)技術(shù)、數(shù)據(jù)資產(chǎn)、數(shù)據(jù)服務(wù)等各個(gè)層次，進(jìn)行規(guī)范和標(biāo)準(zhǔn)化：?數(shù)據(jù)技術(shù)：數(shù)據(jù)如何采集，如何存儲(chǔ)，如何進(jìn)