例舉典型的需要建設(shè)中臺(tái)的場(chǎng)景，供參考判斷要不要建中臺(tái)。建設(shè)中臺(tái)需要考慮組織、技術(shù)支撐和方法論，往往還需要咨詢(xún)服務(wù)的幫助，本文可以作為思考中臺(tái)建設(shè)的大框架。

這是中臺(tái)系列的第二篇。上一篇什么是中臺(tái)，什么不是中臺(tái)闡釋清楚了中臺(tái)的概念，這一篇說(shuō)明什么情況下可以考慮建中臺(tái)，如果要建要怎么建的問(wèn)題。

要建設(shè)中臺(tái)，首先要考慮要不要建設(shè)中臺(tái)。話(huà)說(shuō)的這么繞是因?yàn)楝F(xiàn)在有很多不明就理就想建中臺(tái)的。這個(gè)問(wèn)題先做個(gè)初略的判斷。

1 要不要建設(shè)中臺(tái)

對(duì)業(yè)務(wù)中臺(tái)來(lái)說(shuō)，比較符合的場(chǎng)景主要有：

• 業(yè)務(wù)系統(tǒng)研發(fā)團(tuán)隊(duì)至少大幾十人以上（含外包的），需求多變化快，系統(tǒng)又涉及多個(gè)領(lǐng)域（比如做ERP、電商的），業(yè)務(wù)邏輯比較復(fù)雜。這時(shí)業(yè)務(wù)中臺(tái)可以把系統(tǒng)和業(yè)務(wù)領(lǐng)域劃分清楚，提高研發(fā)效率。

• 做相似行業(yè)的外包項(xiàng)目為主，業(yè)務(wù)規(guī)模也做的比較大的（一年有兩位數(shù)的項(xiàng)目）。這時(shí)業(yè)務(wù)中臺(tái)可以提升軟件復(fù)用，降低定制化成本，提高研發(fā)效率。如果你做外包，每個(gè)項(xiàng)目都完全不一樣，那中臺(tái)也救不了你。

此外還有以下場(chǎng)景可能不需要建設(shè)完整的中臺(tái)，但適合落地與中臺(tái)相關(guān)的微服務(wù)技術(shù)的：

• 大規(guī)模互聯(lián)網(wǎng)式在線(xiàn)系統(tǒng)，對(duì)穩(wěn)定性和彈性要求高當(dāng)前搞不定的。微服務(wù)或業(yè)務(wù)中臺(tái)可以比較好的解決這些問(wèn)題。

• 掉到IT豎井的坑里想爬出來(lái)的，通過(guò)項(xiàng)目外包做的系統(tǒng)無(wú)法管理和維護(hù)的。微服務(wù)或業(yè)務(wù)中臺(tái)可以對(duì)系統(tǒng)的API、文檔等進(jìn)行有效管理，也能實(shí)現(xiàn)系統(tǒng)間的打通。

對(duì)數(shù)據(jù)中臺(tái)來(lái)說(shuō)，比較符合的場(chǎng)景主要是數(shù)據(jù)產(chǎn)品比較多，每天要看數(shù)據(jù)如果沒(méi)數(shù)據(jù)就不知道怎么工作的運(yùn)營(yíng)人員比較多的業(yè)務(wù)。比如電商就是典型。如果這些數(shù)據(jù)產(chǎn)品和運(yùn)營(yíng)人員還在多個(gè)團(tuán)隊(duì)，那基本上數(shù)據(jù)中臺(tái)沒(méi)跑了。如果經(jīng)常出現(xiàn)指標(biāo)不一致、數(shù)據(jù)出錯(cuò)、想要的數(shù)據(jù)不知道哪里有等問(wèn)題，那基本上數(shù)據(jù)中臺(tái)也沒(méi)跑了。

并不是數(shù)據(jù)量大就需要建中臺(tái)，主要還是看用數(shù)據(jù)的姿勢(shì)是不是比較復(fù)雜，當(dāng)前問(wèn)題是不是比較多。對(duì)于這類(lèi)符合的業(yè)務(wù)，數(shù)據(jù)中臺(tái)能把層層數(shù)據(jù)直到最上層的指標(biāo)梳理清楚，提升數(shù)據(jù)質(zhì)量，從而提升運(yùn)營(yíng)效率。把數(shù)據(jù)理清楚了，往往還能降低數(shù)據(jù)存儲(chǔ)和數(shù)據(jù)開(kāi)發(fā)人員的成本。

除了上述判斷，還有一條是同行對(duì)比。如果一個(gè)行業(yè)大家都有點(diǎn)躍躍欲試想弄中臺(tái)，那領(lǐng)先者一定要想辦法搶先（既然是領(lǐng)先者了，往往也符合上述標(biāo)準(zhǔn)），不然就可能被顛覆。跟隨者要不要想辦法搶先從而超越領(lǐng)先者呢？可能不好說(shuō)吧，但如果領(lǐng)先者已經(jīng)建了，跟隨者一般得緊跟，否則真可能被甩開(kāi)了。

如果根據(jù)上述邏輯覺(jué)得大致要考慮去搞一把中臺(tái)的話(huà)，那請(qǐng)繼續(xù)讀本文以下內(nèi)容，讀完本文后續(xù)內(nèi)容然后更具體的看看問(wèn)題存不存在，條件是否具備。

要建設(shè)中臺(tái)，需要考慮組織、支撐技術(shù)、方法論這三個(gè)方面，往往還需要咨詢(xún)服務(wù)。

2 組織

中臺(tái)作為一種有業(yè)務(wù)屬性的共性能力，首先就需要一個(gè)懂業(yè)務(wù)、承擔(dān)業(yè)務(wù)職責(zé)的專(zhuān)職的組織機(jī)構(gòu)來(lái)負(fù)責(zé)。要不要建中臺(tái)，首先要看領(lǐng)導(dǎo)有沒(méi)有魄力去整合建立一個(gè)中臺(tái)組織。因?yàn)樵瓉?lái)的平臺(tái)部通常不懂業(yè)務(wù)，懂業(yè)務(wù)的人各自分散在前臺(tái)業(yè)務(wù)部門(mén)，所以建立中臺(tái)組織往往涉及人員、組織架構(gòu)和部門(mén)職責(zé)的調(diào)整。正因?yàn)槿绱?，中臺(tái)的建設(shè)往往需要作為一把手工程才能成功。

中臺(tái)組織關(guān)鍵要懂業(yè)務(wù)和承擔(dān)業(yè)務(wù)職責(zé)。舉個(gè)例子，一個(gè)大數(shù)據(jù)平臺(tái)的建設(shè)運(yùn)維團(tuán)隊(duì)不是一個(gè)中臺(tái)組織。一個(gè)團(tuán)隊(duì)如果做了非常完善的中臺(tái)產(chǎn)品（如開(kāi)發(fā)了數(shù)據(jù)中臺(tái)所需要的指標(biāo)管理系統(tǒng)、數(shù)據(jù)倉(cāng)庫(kù)開(kāi)發(fā)系統(tǒng)、數(shù)據(jù)質(zhì)量管理系統(tǒng)等等），但只是把產(chǎn)品提供給業(yè)務(wù)方使用，這個(gè)團(tuán)隊(duì)仍然不能說(shuō)是中臺(tái)組織。只有當(dāng)這個(gè)團(tuán)隊(duì)承擔(dān)起指標(biāo)體系的建設(shè)和管理、數(shù)據(jù)倉(cāng)庫(kù)的設(shè)計(jì)和實(shí)施、數(shù)據(jù)質(zhì)量的保障等工作時(shí)，才可以說(shuō)是中臺(tái)組織。而要做到這一點(diǎn)，這個(gè)組織肯定是比較了解業(yè)務(wù)的，它的目標(biāo)和考核也一定與業(yè)務(wù)有相關(guān)性（肯定不只是平臺(tái)穩(wěn)定性這樣的非業(yè)務(wù)指標(biāo)）。

中臺(tái)組織的層次與中臺(tái)的層次最好是對(duì)應(yīng)的，BU級(jí)的中臺(tái)組織最好直接向BU老大或分管的CXO匯報(bào)，企業(yè)的中臺(tái)組織最好直接向CEO或分管的CXO匯報(bào)。

這里特別說(shuō)明一點(diǎn)的是如果不建設(shè)在線(xiàn)業(yè)務(wù)中臺(tái)，而只是采用微服務(wù)、云原生這些敏捷研發(fā)技術(shù)的話(huà)，可以不涉及組織方面的變動(dòng)，就在原來(lái)的研發(fā)部實(shí)現(xiàn)轉(zhuǎn)型。通常來(lái)說(shuō)也可以實(shí)現(xiàn)一定的系統(tǒng)可用率、彈性和研發(fā)效率方面的提升。

3 支撐技術(shù)

建設(shè)中臺(tái)一般需要一套支撐技術(shù)。

3.1、在線(xiàn)業(yè)務(wù)中臺(tái)支撐技術(shù)

建設(shè)在線(xiàn)業(yè)務(wù)中臺(tái)一般需要云原生、DevOps、微服務(wù)技術(shù)體系的支撐，這是因?yàn)椋?/p>

• 微服務(wù)技術(shù)：中臺(tái)是一個(gè)獨(dú)立的組織負(fù)責(zé)并為多個(gè)前臺(tái)業(yè)務(wù)服務(wù)，因此需要一個(gè)標(biāo)準(zhǔn)的服務(wù)接口、成熟的服務(wù)治理能力和高效的敏捷研發(fā)技術(shù)。在當(dāng)前的技術(shù)環(huán)境下，采用地球人都熟悉的REST風(fēng)格的同步API、消息隊(duì)列異步通信作為標(biāo)準(zhǔn)的服務(wù)接口技術(shù)，采用服務(wù)框架（如Spring Cloud等）、API網(wǎng)關(guān)、APM等作為標(biāo)準(zhǔn)的服務(wù)治理和敏捷研發(fā)技術(shù)是最合適的選擇。不再建議采用傳統(tǒng)的基于ESB的服務(wù)化（SOA）技術(shù)，因?yàn)镋SB產(chǎn)品過(guò)多的介入到業(yè)務(wù)邏輯中，導(dǎo)致前臺(tái)業(yè)務(wù)的變更往往需要中臺(tái)團(tuán)隊(duì)的配合才能完成，這樣就失去了建設(shè)好中臺(tái)，支撐前臺(tái)高效創(chuàng)新的意義。此外，中心化的ESB軟件和復(fù)雜的基于XML的WS-xxx等協(xié)議也影響到系統(tǒng)的可用性和性能。可以參見(jiàn)Martin Fowler在P of EAA中的評(píng)價(jià)，Web Services是應(yīng)用集成而非應(yīng)用開(kāi)發(fā)的技術(shù)。

• DevOps技術(shù)：如果不通過(guò)DevOps使得各微服務(wù)都能自助式的部署更新，則微服務(wù)帶來(lái)的敏捷性就無(wú)從發(fā)揮，反而因?yàn)榉?wù)數(shù)量的增加導(dǎo)致研發(fā)效率的下降，因此持續(xù)集成、持續(xù)發(fā)布等DevOps技術(shù)一般是實(shí)現(xiàn)微服務(wù)的必備。

• 云原生技術(shù)：微服務(wù)和DevOps要求底層的基礎(chǔ)設(shè)施是靈活可編程的，否則根據(jù)Amdahl定律，只要有一個(gè)必須的環(huán)節(jié)是低效的，整體的效能也提不上去。需要強(qiáng)調(diào)的是中臺(tái)要敏捷，這一方面是因?yàn)橹信_(tái)具備業(yè)務(wù)屬性，且支撐了非常豐富的前臺(tái)業(yè)務(wù)，前臺(tái)業(yè)務(wù)的敏捷性要求有一部分就會(huì)傳導(dǎo)的中臺(tái)層；另一方面是中臺(tái)的重要性使得其需要持續(xù)不斷的優(yōu)化，即便對(duì)外提供的服務(wù)不變，內(nèi)部實(shí)現(xiàn)也會(huì)經(jīng)常變。

• 分布式事務(wù)技術(shù)：實(shí)施微服務(wù)拆分后，復(fù)雜的業(yè)務(wù)流程不再能通過(guò)數(shù)據(jù)庫(kù)的事務(wù)機(jī)制來(lái)實(shí)現(xiàn)ACID特性，為此還需要服務(wù)層面的分布式事務(wù)處理技術(shù)。典型的分布式事務(wù)處理模型包括TCC、Saga、FMT等。其中TCC和Saga需要各服務(wù)實(shí)現(xiàn)定制化回滾邏輯，侵入性比較嚴(yán)重，用起來(lái)門(mén)檻比較高。FMT模式對(duì)于Java可以做到加一行注解（如@GlobalTransaction）即可實(shí)現(xiàn)分布式事務(wù)，剩下的由框架自動(dòng)處理，用起來(lái)方便的多。Saga模式是Princeton的兩位研究者在1987年提出的，靈活性和并發(fā)度最好，但需要通過(guò)語(yǔ)義鎖等精細(xì)的設(shè)計(jì)才能發(fā)揮出來(lái)。

由此可見(jiàn)，在線(xiàn)業(yè)務(wù)中臺(tái)的技術(shù)支撐體系是相當(dāng)復(fù)雜的，所幸的是Netflix、Google等世界領(lǐng)先的互聯(lián)網(wǎng)企業(yè)由于自身業(yè)務(wù)需要打造了很多實(shí)用的技術(shù)模塊，開(kāi)源社區(qū)也貢獻(xiàn)了不少力量，CNCF組織又做了很好的匯集和標(biāo)準(zhǔn)化。通過(guò)將相關(guān)技術(shù)加以整合，已經(jīng)有了不錯(cuò)的產(chǎn)品可用，如網(wǎng)易輕舟微服務(wù)就是一套產(chǎn)品化設(shè)計(jì)良好、功能豐富的在線(xiàn)業(yè)務(wù)中臺(tái)支撐技術(shù)產(chǎn)品。

一般而言，前臺(tái)也會(huì)和在線(xiàn)業(yè)務(wù)中臺(tái)一樣采用云原生等同樣的技術(shù)體系，這是因?yàn)榍芭_(tái)更需要敏捷性。在完善的中臺(tái)支撐之下，前臺(tái)會(huì)比較輕，還可以考慮采用FaaS Serverless技術(shù)，不過(guò)目前這方面的實(shí)踐還不多（特別在中國(guó)），相關(guān)的支撐技術(shù)也不是很成熟。

3.2、數(shù)據(jù)中臺(tái)支撐技術(shù)

建設(shè)數(shù)據(jù)中臺(tái)一般需要一整套如下典型的支撐技術(shù)：

• 指標(biāo)管理系統(tǒng)：指標(biāo)是中臺(tái)與前臺(tái)之間最關(guān)鍵的接口，也是建設(shè)數(shù)據(jù)中臺(tái)的牛鼻子，因?yàn)樗亲詈诵牡臉I(yè)務(wù)語(yǔ)言，且指標(biāo)不一致、數(shù)據(jù)常出錯(cuò)是建設(shè)數(shù)據(jù)中臺(tái)最常見(jiàn)的出發(fā)點(diǎn)。如果指標(biāo)體系沒(méi)有統(tǒng)一的方法論，進(jìn)行統(tǒng)一建設(shè)，那么就很難說(shuō)是數(shù)據(jù)中臺(tái)。指標(biāo)管理系統(tǒng)一般要實(shí)現(xiàn)一套一致的方法論（如原子 / 派生 / 復(fù)合指標(biāo)、維度、修飾詞等），做好指標(biāo)的業(yè)務(wù)和技術(shù)口徑管理，還需要支持指標(biāo)的審批管理。數(shù)據(jù)中臺(tái)的指標(biāo)無(wú)法交給各前臺(tái)業(yè)務(wù)自助式的建設(shè)。

• 數(shù)據(jù)服務(wù)系統(tǒng)：類(lèi)似于在線(xiàn)業(yè)務(wù)中臺(tái)需要通過(guò)API網(wǎng)關(guān)提供標(biāo)準(zhǔn)化的服務(wù)，數(shù)據(jù)中臺(tái)也需要一個(gè)標(biāo)準(zhǔn)化的服務(wù)方式，通常稱(chēng)為數(shù)據(jù)服務(wù)系統(tǒng)，也可以說(shuō)是數(shù)據(jù)網(wǎng)關(guān)或數(shù)據(jù)門(mén)戶(hù)。類(lèi)似于別的網(wǎng)關(guān)類(lèi)產(chǎn)品，數(shù)據(jù)服務(wù)系統(tǒng)需要提供鑒權(quán)、日志審計(jì)、流控、協(xié)議轉(zhuǎn)換（如SQL Dialect之間的轉(zhuǎn)換）等功能，也應(yīng)該發(fā)展多引擎融合查詢(xún)、邏輯模型等擴(kuò)展功能以提高服務(wù)接口的穩(wěn)定性和實(shí)現(xiàn)的靈活性。

• 元數(shù)據(jù)管理系統(tǒng)：元數(shù)據(jù)管理是整個(gè)數(shù)據(jù)中臺(tái)的基礎(chǔ)和中心，所有的其他系統(tǒng)都依賴(lài)元數(shù)據(jù)管理。元數(shù)據(jù)管理首先要做好的當(dāng)然是數(shù)據(jù)模式或目錄（catalog）的管理，至少要知道中臺(tái)里都有什么數(shù)據(jù)。對(duì)復(fù)雜的數(shù)據(jù)中臺(tái)來(lái)說(shuō)，數(shù)據(jù)血緣也很重要。沒(méi)有血緣信息，不知道數(shù)據(jù)間的依賴(lài)關(guān)系，數(shù)據(jù)質(zhì)量肯定管不好，因?yàn)椴恢酪粋€(gè)數(shù)據(jù)的質(zhì)量問(wèn)題怎么來(lái)，又進(jìn)而會(huì)影響什么。同樣的如果沒(méi)有血緣，數(shù)據(jù)資產(chǎn)也肯定管不好，因?yàn)椴恢朗裁磾?shù)據(jù)有價(jià)值什么沒(méi)價(jià)值，這就像如果你不知道一個(gè)函數(shù)被誰(shuí)調(diào)用，你就不知道它是不是死代碼一樣。元數(shù)據(jù)管理系統(tǒng)往往也需要提供一個(gè)基礎(chǔ)的訪(fǎng)問(wèn)界面，通常稱(chēng)之為數(shù)據(jù)地圖。

• 數(shù)據(jù)倉(cāng)庫(kù)開(kāi)發(fā)與管理系統(tǒng)：除了指標(biāo)管理，數(shù)據(jù)倉(cāng)庫(kù)的開(kāi)發(fā)是將一大堆初始數(shù)據(jù)建設(shè)梳理成一個(gè)漂亮的數(shù)據(jù)中臺(tái)的核心過(guò)程。一般來(lái)講數(shù)據(jù)中臺(tái)更適合用Kimball的維度建模方法而非數(shù)據(jù)倉(cāng)庫(kù)之父Bill Inmon所提倡的方法，這是因?yàn)镮nmon強(qiáng)調(diào)頂層設(shè)計(jì)，而Kimball強(qiáng)調(diào)至下而上。如果要建設(shè)數(shù)據(jù)中臺(tái)，肯定是因?yàn)榍芭_(tái)業(yè)務(wù)復(fù)雜多變，這時(shí)強(qiáng)調(diào)頂層設(shè)計(jì)會(huì)導(dǎo)致中臺(tái)建設(shè)緩慢、僵化。因?yàn)橹信_(tái)雖然應(yīng)該是由組織高層決策，但目的卻是為了支持前臺(tái)業(yè)務(wù)，而不是為了控制。*支持而不是控制*，這一點(diǎn)絕不能本末倒置。

• 數(shù)據(jù)質(zhì)量管理系統(tǒng)：所有復(fù)雜的系統(tǒng)都需要專(zhuān)業(yè)的質(zhì)量管理，在線(xiàn)業(yè)務(wù)系統(tǒng)有一系列的彈力設(shè)計(jì)和APM等監(jiān)控運(yùn)維工具，數(shù)據(jù)中臺(tái)也需要專(zhuān)業(yè)的質(zhì)量管理。數(shù)據(jù)質(zhì)量管理系統(tǒng)通常設(shè)計(jì)為支持豐富的稽核 / 校驗(yàn) / 比對(duì)規(guī)則，監(jiān)控?cái)?shù)據(jù)是否準(zhǔn)確、實(shí)時(shí)、一致，還要做到及時(shí)的報(bào)警，分析影響面，提供快速修復(fù)的手段等。但這些手段只能發(fā)現(xiàn)和補(bǔ)救問(wèn)題，不能預(yù)防問(wèn)題，要預(yù)防問(wèn)題，還要通過(guò)測(cè)試工具減少代碼bug、通過(guò)資源彈性應(yīng)對(duì)性能波動(dòng)、通過(guò)優(yōu)先級(jí)調(diào)度優(yōu)先滿(mǎn)足重要業(yè)務(wù)需求等。相對(duì)來(lái)說(shuō)，當(dāng)前數(shù)據(jù)中臺(tái)領(lǐng)域的質(zhì)量管理沒(méi)有在線(xiàn)業(yè)務(wù)領(lǐng)域的成熟，如在線(xiàn)業(yè)務(wù)領(lǐng)域的測(cè)試手段遠(yuǎn)比數(shù)據(jù)領(lǐng)域的精細(xì)，在線(xiàn)業(yè)務(wù)領(lǐng)域很常見(jiàn)的熔斷、限流、服務(wù)降級(jí)等模式在數(shù)據(jù)領(lǐng)域都沒(méi)有成熟的實(shí)踐方法（優(yōu)先級(jí)調(diào)度可以說(shuō)是實(shí)現(xiàn)了部分的服務(wù)降級(jí)功能），隨著數(shù)據(jù)中臺(tái)越來(lái)越廣泛和重要，這些技術(shù)應(yīng)該也需要持續(xù)發(fā)展，但技術(shù)上的挑戰(zhàn)不小。

• 數(shù)據(jù)安全管理系統(tǒng)：數(shù)據(jù)中臺(tái)因?yàn)閰R集了組織所有有價(jià)值的數(shù)據(jù)資產(chǎn)，因此良好的安全管理是必須的。細(xì)粒度的權(quán)限和審計(jì)是基礎(chǔ)，一般的還需要隱私 / 敏感數(shù)據(jù)的脫敏處理、數(shù)據(jù)加密（特別是將數(shù)據(jù)托管在第三方平臺(tái)之上時(shí)）、數(shù)據(jù)泄漏防護(hù)（比方說(shuō)一種常見(jiàn)的方法是限制將數(shù)據(jù)下載到本地的數(shù)據(jù)量）等技術(shù)。發(fā)展到高級(jí)階段甚至可能還需要聯(lián)邦學(xué)習(xí)、數(shù)據(jù)沙盒等技術(shù)。

• 數(shù)據(jù)資產(chǎn)管理系統(tǒng)：在數(shù)據(jù)質(zhì)量和安全單列的情況下，數(shù)據(jù)資產(chǎn)管理主要負(fù)責(zé)的是數(shù)據(jù)的生命周期管理、成本的統(tǒng)計(jì)分析與優(yōu)化等工作。

同時(shí)，數(shù)據(jù)中臺(tái)還需要強(qiáng)大的大數(shù)據(jù)計(jì)算引擎、數(shù)據(jù)集成 / 同步 / 交換引擎，還往往需要一套敏捷BI系統(tǒng)：

• 大數(shù)據(jù)計(jì)算引擎：數(shù)據(jù)中臺(tái)要管理的數(shù)據(jù)規(guī)模和復(fù)雜度往往都很高（否則搞中臺(tái)屬于為賦新詞強(qiáng)說(shuō)愁），所以傳統(tǒng)的數(shù)據(jù)庫(kù)和數(shù)據(jù)倉(cāng)庫(kù)基本上支撐不了。當(dāng)前的技術(shù)環(huán)境下，基于Hadoop MapReduce或Spark幾乎是唯二的選擇，當(dāng)然這也包括了這兩者之上的Hive和Spark SQL。能有SQL就用SQL，易于維護(hù)，也易于數(shù)據(jù)血緣的收集。除此之外，流處理可能還需要Flink，交互式查詢(xún)可能要引入Impala或GreenPlum。

• 數(shù)據(jù)集成 / 同步 / 交換引擎：一方面數(shù)據(jù)中臺(tái)需要強(qiáng)大的數(shù)據(jù)集成和同步能力才能吸納各方數(shù)據(jù)。集成和同步的概念相近，同步更強(qiáng)調(diào)實(shí)時(shí)性。另一方面，數(shù)據(jù)中臺(tái)往往由多種數(shù)據(jù)計(jì)算引擎構(gòu)成，就需要同步或交換引擎實(shí)現(xiàn)不同引擎見(jiàn)的數(shù)據(jù)交換。

• 敏捷BI系統(tǒng)：建設(shè)數(shù)據(jù)中臺(tái)通常最重要的目的是為了支持業(yè)務(wù)運(yùn)營(yíng)和決策，為此需要基于數(shù)據(jù)中臺(tái)進(jìn)一步開(kāi)發(fā)數(shù)據(jù)產(chǎn)品。敏捷BI系統(tǒng)是開(kāi)發(fā)數(shù)據(jù)產(chǎn)品快速、輕型的手段，能夠盡快盡早的發(fā)揮數(shù)據(jù)中臺(tái)的價(jià)值。

此外，對(duì)于互聯(lián)網(wǎng)業(yè)務(wù)，統(tǒng)一的埋點(diǎn)引擎往往也是數(shù)據(jù)中臺(tái)所需要的。如果埋點(diǎn)的邏輯都不統(tǒng)一的話(huà)，建數(shù)據(jù)中臺(tái)的時(shí)候會(huì)發(fā)現(xiàn)數(shù)據(jù)的源頭就是亂的，后續(xù)也都沒(méi)法做。其他行業(yè)業(yè)務(wù)，數(shù)據(jù)采集也屬于基礎(chǔ)工作，也是要先做好的。

由此可見(jiàn)，建設(shè)數(shù)據(jù)中臺(tái)需要的技術(shù)支撐體系也是相當(dāng)?shù)凝嫶?，?fù)雜。所幸的是這十年來(lái)Google等領(lǐng)先的企業(yè)、Hadoop / Spark等開(kāi)源社區(qū)以及大量的產(chǎn)商大致聯(lián)合探索出了一條可行的路徑，方法論和技術(shù)路線(xiàn)都比較統(tǒng)一了。以此為基礎(chǔ)，就可以提供較成熟的數(shù)據(jù)中臺(tái)技術(shù)支撐產(chǎn)品，如網(wǎng)易杭研研發(fā)的“網(wǎng)易猛犸V6.0 + 網(wǎng)易有數(shù)”就是一套較完整的數(shù)據(jù)中臺(tái)產(chǎn)品。

 4 方法論

復(fù)雜事務(wù)都需要方法論的指導(dǎo)（和約束），組織管理有虛虛實(shí)實(shí)的一大套各種理論，研發(fā)有敏捷方法或IPD流程，中臺(tái)是復(fù)雜事務(wù)，所以也需要方法論。因?yàn)橹信_(tái)建設(shè)涉及組織和技術(shù)兩個(gè)維度，所以中臺(tái)的方法論也應(yīng)該要覆蓋這兩個(gè)維度。目前而言，技術(shù)維度的方法論相對(duì)成熟，因?yàn)閺?fù)用了很多原有的方法論。

4.1、在線(xiàn)業(yè)務(wù)中臺(tái)方法論

對(duì)于業(yè)務(wù)中臺(tái)，微服務(wù)、網(wǎng)關(guān)、REST API及語(yǔ)義化版本控制、六邊形架構(gòu)是側(cè)重于技術(shù)架構(gòu)的方法論，DevOps、敏捷項(xiàng)目管理是側(cè)重于流程層面的方法論，領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)（DDD）是側(cè)重于業(yè)務(wù)架構(gòu)的方法論。要做好業(yè)務(wù)中臺(tái)，以上方法論大概都不可或缺。

大家可以看到，除了微服務(wù)跟中臺(tái)大致是同步發(fā)展的之外，其他方法論都是早前就存在的東西。正因?yàn)橛羞@么多合適的方法論存在，中臺(tái)才變得可行，無(wú)論如何在短期內(nèi)要發(fā)展出這么多方法論是不現(xiàn)實(shí)的，因?yàn)榉椒ㄕ摰耐Σ粌H在于它要好，還在于它要流行。

技術(shù)架構(gòu)和流程方面的方法論已經(jīng)很流行，無(wú)需多說(shuō)（六邊形架構(gòu)放在和DDD一起介紹）。值得關(guān)注的是領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)這么一個(gè)10多年前就被提出，這么多年一直不溫不火的方法論，突然在中臺(tái)領(lǐng)域似乎找到了它的最佳安身之所（也可以說(shuō)中臺(tái)找到了DDD這么一根救命稻草？）。這樣的現(xiàn)象是會(huì)曇花一現(xiàn)，還是會(huì)長(zhǎng)期持續(xù)，值得思考。

DDD的核心概念是通用語(yǔ)言和限界上下文。通用語(yǔ)言指的是在一個(gè)業(yè)務(wù)領(lǐng)域內(nèi)通用（但不是在更大的領(lǐng)域內(nèi)也完全通用的）的概念、術(shù)語(yǔ)等語(yǔ)言，限界上下文指的是相鄰?fù)ㄓ谜Z(yǔ)言之間“翻譯”的邊界，比如前臺(tái)業(yè)務(wù)的用戶(hù)可能要變成后臺(tái)清算的客戶(hù)。

我覺(jué)得DDD的通用語(yǔ)言和一直以來(lái)的領(lǐng)域建模是比較相似的，更具創(chuàng)新意義的是限界上下文。在架構(gòu)設(shè)計(jì)中，我們要不要構(gòu)造那種擁有非常多屬性，但每個(gè)使用者只使用少量屬性，或者屬性的名稱(chēng)和含義對(duì)使用者來(lái)說(shuō)不貼切的對(duì)象？如果沒(méi)有限界上下文的約束，可能會(huì)認(rèn)為這樣畢竟實(shí)現(xiàn)了更多的復(fù)用，是好的，但用限界上下文的理念來(lái)看，這樣很可能是不好的。每個(gè)領(lǐng)域應(yīng)該專(zhuān)注于自己領(lǐng)域的語(yǔ)言，領(lǐng)域之間要交互怎么辦？加一種翻譯機(jī)制，也就是限界上下文解決。

領(lǐng)域驅(qū)動(dòng)和限界上下文的理念會(huì)自然延伸出六邊形架構(gòu)的設(shè)計(jì)。所謂六邊形架構(gòu)指的是一個(gè)程序的內(nèi)部只需要處理業(yè)務(wù)邏輯，他的數(shù)據(jù) / 請(qǐng)求從哪里來(lái)，數(shù)據(jù)要存儲(chǔ)到哪里去（或者領(lǐng)域事件要發(fā)布），都通過(guò)各種適配器完成。因?yàn)檫@樣的適配器可能較多，就不再像傳統(tǒng)的三層（三明治）架構(gòu)。不過(guò)如果六邊形只有一個(gè)Input和一個(gè)Output適配器的話(huà)，和三層架構(gòu)就還是差不多的。我想從三層架構(gòu)進(jìn)化到六邊形架構(gòu)的主要原因還是因?yàn)楝F(xiàn)在的環(huán)境已經(jīng)從傳統(tǒng)的C / S或B / S這樣只有一個(gè)前端，也只有RDBMS這樣的一個(gè)后端發(fā)展到前面有Web / 移動(dòng)等多個(gè)端，向后也有RDBMS / NoSQL等多個(gè)端，橫向也有服務(wù)化 / MQ等多個(gè)端的多端環(huán)境。我不知道哪天會(huì)不會(huì)發(fā)展出一個(gè)十面埋伏架構(gòu)出來(lái)。

4.2、數(shù)據(jù)中臺(tái)方法論

數(shù)據(jù)中臺(tái)的方法論也是博采眾長(zhǎng)，最核心的來(lái)自于數(shù)據(jù)倉(cāng)庫(kù)領(lǐng)域關(guān)于數(shù)據(jù)倉(cāng)庫(kù)規(guī)劃實(shí)施和指標(biāo)體系建設(shè)的方法。在數(shù)據(jù)倉(cāng)庫(kù)領(lǐng)域，有兩套截然不同的方法之前一直是較勁的，一個(gè)是數(shù)據(jù)倉(cāng)庫(kù)之父Bill Inmon所倡導(dǎo)的至上而下的方法，另一個(gè)是另一位大師級(jí)人物Kimball所倡導(dǎo)的至下而上的方法。在我理解，所謂Kimball的模式之所以說(shuō)是至下而上，是因?yàn)榛旧现信_(tái)團(tuán)隊(duì)只負(fù)責(zé)從ODS到DWD到DWS就完了，往上就是所謂的ADS，其實(shí)已經(jīng)是面向各個(gè)業(yè)務(wù)（或者數(shù)據(jù)產(chǎn)品）了。你都可以說(shuō)ADS層不屬于數(shù)倉(cāng)。這樣的方法在中臺(tái)作為一種新生事務(wù)沒(méi)法有很強(qiáng)的話(huà)語(yǔ)權(quán)時(shí)顯然是更容易做出的選擇，可能未來(lái)中臺(tái)概念深入人心，集團(tuán)高度重視，說(shuō)不定Inmon方法又會(huì)重新流行？但也可以思考這種細(xì)節(jié)上都體現(xiàn)了領(lǐng)導(dǎo)的管理意志的中臺(tái)還是中臺(tái)嗎。指標(biāo)設(shè)計(jì)的方法論基于Kimball方法中的粒度建模的方法，做了比較大的細(xì)化和改進(jìn)。

劃分主題域是建數(shù)據(jù)中臺(tái)的常見(jiàn)實(shí)踐，不過(guò)主題域劃分與行業(yè)強(qiáng)相關(guān)，比如對(duì)零售業(yè)常見(jiàn)的有商品、交易、流量、用戶(hù)、營(yíng)銷(xiāo)等域。

數(shù)據(jù)中臺(tái)統(tǒng)一通過(guò)數(shù)據(jù)服務(wù)系統(tǒng)實(shí)現(xiàn)OneService的設(shè)計(jì)，不清楚有什么來(lái)源，不過(guò)類(lèi)似于在業(yè)務(wù)架構(gòu)中很常見(jiàn)的網(wǎng)關(guān)模式。數(shù)據(jù)質(zhì)量、數(shù)據(jù)安全、元數(shù)據(jù)、生命周期管理也都是數(shù)據(jù)治理領(lǐng)域比較常見(jiàn)的概念，但一方面要實(shí)現(xiàn)針對(duì)大數(shù)據(jù)技術(shù)環(huán)境的落地，另一方面更面向業(yè)務(wù)支持而非管控來(lái)設(shè)計(jì)。

實(shí)施數(shù)據(jù)中臺(tái)通常還需要制定很多規(guī)范或標(biāo)準(zhǔn)，這也可以說(shuō)是方法論的一方面。有很多規(guī)范是命名規(guī)范，其中數(shù)量最大的往往是數(shù)據(jù)倉(cāng)庫(kù)中的表，上萬(wàn)張表甚至更多都是很常見(jiàn)的，所以表的規(guī)范命名非常必要。一種好的表的命名規(guī)范，要反映其所在數(shù)倉(cāng)分層、主題域、業(yè)務(wù)過(guò)程、時(shí)間周期等信息。計(jì)算任務(wù)也需要一定的命名規(guī)范。數(shù)據(jù)埋點(diǎn)也需要規(guī)范性的編碼位置信息、內(nèi)容信息和事件信息。

4.3、組織維度的方法論及其他

其他類(lèi)型的中臺(tái)也都有各自的方法論。如搜索中臺(tái)，百度有比較詳細(xì)的對(duì)外分享的資料，其方法論主要體現(xiàn)在規(guī)范了搜索系統(tǒng)的關(guān)鍵流程，如內(nèi)容引入和加工、離線(xiàn)訓(xùn)練、在線(xiàn)召回和排序等，還會(huì)涉及到查詢(xún)改寫(xiě)、展示設(shè)計(jì)等要點(diǎn)。

以上說(shuō)的都是中臺(tái)技術(shù)維度的方法論，組織維度的方法論目前還沒(méi)有看到好的系統(tǒng)性分析成果。在阿里中臺(tái)藍(lán)寶書(shū)（《企業(yè)IT架構(gòu)轉(zhuǎn)型之道》）中只有很少的篇幅介紹中臺(tái)組織維度的方法論，在另一本阿里講數(shù)據(jù)中臺(tái)的書(shū)中，干脆就只字沒(méi)提組織方面的內(nèi)容。阿里關(guān)于中臺(tái)組織的方法論，主要包括多職能小微團(tuán)隊(duì)、業(yè)務(wù)架構(gòu)師主導(dǎo)、協(xié)作溝通機(jī)制、輪崗、共建、考核機(jī)制等。業(yè)界也有從一般性的組織管理維度（如垂直型組織、矩陣型組織等等）分析，過(guò)于寬泛，說(shuō)了等于沒(méi)說(shuō)。

中臺(tái)組織層面的方法論可能是相對(duì)不成熟的，比如中臺(tái)和前臺(tái)、平臺(tái)之間的邊界和動(dòng)向問(wèn)題，似乎沒(méi)有明確的方法。我認(rèn)為可能主流會(huì)符合“前臺(tái)->中臺(tái)->平臺(tái)“單向流動(dòng)的中心法則?？赡苤信_(tái)組織的終極目標(biāo)是發(fā)展為平臺(tái)，因?yàn)檫€是要追求把能力做成熟和標(biāo)準(zhǔn)，我這也可能是很反動(dòng)的說(shuō)法。

作為集團(tuán)的創(chuàng)新業(yè)務(wù)孵化中心，網(wǎng)易杭研每時(shí)每刻都針對(duì)很多業(yè)務(wù)線(xiàn)要并行發(fā)展，為此打造了一個(gè)又一個(gè)共享能力中心，千方百計(jì)提升創(chuàng)新效率。12年來(lái)感覺(jué)摸索了一些關(guān)于中臺(tái)的建設(shè)經(jīng)驗(yàn)，當(dāng)然可能更多的是教訓(xùn)，這段經(jīng)歷的體會(huì)后續(xù)我將會(huì)做個(gè)梳理，發(fā)出來(lái)供大家討論。

5 咨詢(xún)

說(shuō)到咨詢(xún)，我首先想到的是技術(shù)進(jìn)步的驅(qū)動(dòng)力發(fā)生了很大的變化，從產(chǎn)商和咨詢(xún)公司驅(qū)動(dòng)變成了領(lǐng)先客戶(hù)驅(qū)動(dòng)。以在線(xiàn)業(yè)務(wù)為例，傳統(tǒng)的SOA和Web Services技術(shù)是IBM、BEA等產(chǎn)商驅(qū)動(dòng)的。產(chǎn)商自己不用產(chǎn)品但要賣(mài)產(chǎn)品，所以一不小心就把產(chǎn)品搞的不必要的復(fù)雜。另外產(chǎn)商和咨詢(xún)公司本來(lái)就是共生共榮的關(guān)系（像IBM咨詢(xún)和產(chǎn)品都做），所以也得把產(chǎn)品搞的復(fù)雜一點(diǎn)吧，不然咨詢(xún)公司就沒(méi)生意了。新生代的微服務(wù)技術(shù)主要是領(lǐng)先的互聯(lián)網(wǎng)企業(yè)驅(qū)動(dòng)的，自己造產(chǎn)品自己用，能簡(jiǎn)單一點(diǎn)就簡(jiǎn)單一點(diǎn)，最好是做成各個(gè)業(yè)務(wù)部門(mén)自己就能用。

所以新生代的中臺(tái)技術(shù)是盡力將咨詢(xún)的必要性盡量降低的，但是因?yàn)楫?dāng)前實(shí)踐中臺(tái)的都是很大的互聯(lián)網(wǎng)企業(yè)，業(yè)務(wù)復(fù)雜度不可避免的很高，對(duì)于大多數(shù)想要實(shí)踐中臺(tái)的非互聯(lián)網(wǎng)企業(yè)來(lái)說(shuō)，仍然是需要咨詢(xún)服務(wù)。

現(xiàn)狀是，當(dāng)前中臺(tái)的咨詢(xún)非常欠缺。因?yàn)檫@些中臺(tái)都是互聯(lián)網(wǎng)企業(yè)搞的，當(dāng)前的產(chǎn)商和咨詢(xún)公司都沒(méi)什么能力做這塊的咨詢(xún)。我們可以看到正是這些咨詢(xún)公司，還是在軟件咨詢(xún)領(lǐng)域很知名的，不懂中臺(tái)，把什么都往中臺(tái)的概念上湊。所以這樣的咨詢(xún)公司能做咨詢(xún)嗎？自己沒(méi)做過(guò)業(yè)務(wù)的產(chǎn)商那就更不用提了。當(dāng)前也就互聯(lián)網(wǎng)企業(yè)或有很強(qiáng)互聯(lián)網(wǎng)企業(yè)背景的團(tuán)隊(duì)才有能力做咨詢(xún)，但資源很有限。希望咨詢(xún)公司們能夠聚焦于真正的中臺(tái)，透徹理解什么是中臺(tái)，提升自己的咨詢(xún)能力。