如何建設中台？中台建設的組織、支撐技術和方法論

編者按：本文轉載自網易副總裁，網易杭州研究院執行院長汪源的個人公衆号“冷技術熱思考”（歡迎搜尋關注）。上一篇中台系列的文章重點闡述了中台的概念，本文是系列文章的第二篇，目的是說明什麼情況下可以考慮建設中台，如果要建怎麼建的問題，可以作為企業思考中台建設的大架構。以下為原文（有少量改動）：

本文将例舉典型的需要建設中台的場景，供參考判斷要不要建中台。建設中台需要考慮組織、技術支撐和方法論，往往還需要咨詢服務的幫助，本文也可以作為思考中台建設的大架構。

要建設中台，首先要考慮要不要建設中台。話說的這麼繞是因為現在有很多不明就理就想建中台的。這個問題先做個初略的判斷。

對業務中台來說，比較符合的場景主要有： 

· 業務系統研發團隊至少大幾十人（含外包的），需求多變化快，系統又涉及多個領域（比如做ERP、電商的），業務邏輯比較複雜。這時業務中台可以把系統和業務領域劃厘清楚，提高研發效率。 

· 做相似行業的外包項目為主，業務規模也做的比較大的（一年有兩位數的項目）。這時業務中台可以提升軟體複用，降低定制化成本，提高研發效率。如果你做外包，每個項目都完全不一樣，那中台也救不了你。 

此外還有以下場景可能不需要建設完整的中台，但适合落地與中台相關的微服務技術的： 

·  大規模網際網路式線上系統，對穩定性和彈性要求高目前搞不定的。微服務或業務中台可以比較好的解決這些問題。 

·  掉到IT豎井的坑裡想爬出來的，通過項目外包做的系統無法管理和維護的。微服務或業務中台可以對系統的API、文檔等進行有效管理，也能實作系統間的打通。 

對資料中台來說，比較符合的場景主要是資料産品比較多，每天要看資料如果沒資料就不知道怎麼工作的營運人員比較多的業務。比如電商就是典型。如果這些資料産品和營運人員還在多個團隊，那基本上資料中台沒跑了。如果經常出現名額不一緻、資料出錯、想要的資料不知道哪裡有等問題，那基本上資料中台也沒跑了。

并不是資料量大就需要建中台，主要還是看用資料的姿勢是不是比較複雜，目前問題是不是比較多。對于這類符合的業務，資料中台能把層層資料直到最上層的名額梳理清楚，提升資料品質，進而提升營運效率。把資料理清楚了，往往還能降低資料存儲和資料開發人員的成本。

除了上述判斷，還有一條是同行對比。如果一個行業大家都有點躍躍欲試想弄中台，那領先者一定要想辦法搶先（既然是領先者了，往往也符合上述标準），不然就可能被颠覆。跟随者要不要想辦法搶先進而超越領先者呢？可能不好說吧，但如果領先者已經建了，跟随者一般得緊跟，否則真可能被甩開了。

如果根據上述邏輯覺得大緻要考慮去搞一把中台的話，那請繼續讀本文以下内容，讀完本文後續内容然後更具體的看看問題存不存在，條件是否具備。要建設中台，需要考慮組織、支撐技術、方法論這三個方面，往往還需要咨詢服務。

中台作為一種有業務屬性的共性能力，首先就需要一個懂業務、承擔業務職責的專職的組織機構來負責。要不要建中台，首先要看上司有沒有魄力去整合建立一個中台組織。因為原來的平台部通常不懂業務，懂業務的人各自分散在前台業務部門，是以建立中台組織往往涉及人員、組織架構和部門職責的調整。 正因為如此，中台的建設往往需要作為一把手工程才能成功。

中台組織關鍵要懂業務和承擔業務職責。舉個例子，一個大資料平台的建設運維團隊不是一個中台組織。一個團隊如果做了非常完善的中台産品（如開發了資料中台所需要的名額管理系統、資料倉庫開發系統、資料品質管理系統等等），但隻是把産品提供給業務方使用，這個團隊仍然不能說是中台組織。隻有當這個團隊承擔起名額體系的建設和管理、資料倉庫的設計和實施、資料品質的保障等工作時，才可以說是中台組織。而要做到這一點，這個組織肯定是比較了解業務的，它的目标和考核也一定與業務有相關性（肯定不隻是平台穩定性這樣的非業務名額）。

中台組織的層次與中台的層次最好是對應的，BU級的中台組織最好直接向BU老大或分管的CXO彙報，企業的中台組織最好直接向CEO或分管的CXO彙報。

這裡特别說明一點的是如果不建設線上業務中台，而隻是采用微服務、雲原生等技術的話，可以不涉及組織方面的大規模變動，就在原來的研發部實作轉型。通常來說也可以實作一定的系統可用率、彈性和研發效率方面的提升。

建設中台一般需要一套支撐技術。 

建設線上業務中台一般需要雲原生、DevOps、微服務技術體系的支撐，這是因為： 

· 微服務技術：中台是一個獨立的組織負責并為多個前台業務服務，是以需要一個标準的服務接口、成熟的服務治理能力和高效的靈活研發技術。在目前的技術環境下，采用地球人都熟悉的REST風格的同步API、消息隊列異步通信作為标準的服務接口技術，采用服務架構（如Spring Cloud等）、API網關、APM等作為标準的服務治理和靈活研發技術是最合适的選擇。不再建議采用傳統的基于ESB的服務化（SOA）技術，因為ESB産品過多的介入到業務邏輯中，導緻前台業務的變更往往需要中台團隊的配合才能完成，這樣就失去了建設好中台，支撐前台高效創新的意義。此外，中心化的ESB軟體和複雜的基于XML的WS-xxx等協定也影響到系統的可用性和性能。可以參見Martin Fowler在P of EAA中的評價，Web Services是應用內建而非應用開發的技術。 

· DevOps技術：如果不通過DevOps使得各微服務都能自助式的部署更新，則微服務帶來的靈活性就無從發揮，反而因為服務數量的增加導緻研發效率的下降，是以持續內建、持續釋出等DevOps技術一般是實作微服務的必備。 

· 雲原生技術：微服務和DevOps要求底層的基礎設施是靈活可程式設計的，否則根據Amdahl定律，隻要有一個必須的環節是低效的，整體的效能也提不上去。 

需要強調的是中台要靈活，這一方面是因為中台具備業務屬性，且支撐了非常豐富的前台業務，前台業務的靈活性要求有一部分就會傳導的中台層；另一方面是中台的重要性使得其需要持續不斷的優化，即便對外提供的服務不變，内部實作也會經常變。 

· 分布式事務技術：實施微服務拆分後，複雜的業務流程不再能通過資料庫的事務機制來實作ACID特性，為此還需要服務層面的分布式事務處理技術。典型的分布式事務處理模型包括TCC、Saga、FMT等。其中TCC和Saga需要各服務實作定制化復原邏輯，侵入性比較嚴重，用起來門檻比較高。FMT模式對于Java可以做到加一行注解（如@GlobalTransaction）即可實作分布式事務，剩下的由架構自動處理，用起來友善的多。Saga模式是Princeton的兩位研究者在1987年提出的，靈活性和并發度最好，但需要通過語義鎖等精細的設計才能發揮出來。 

由此可見，線上業務中台的技術支撐體系是相當複雜的，所幸的是Netflix、Google等世界領先的網際網路企業由于自身業務需要打造了很多實用的技術子產品，開源社群也貢獻了不少力量，CNCF組織又做了很好的彙集和标準化。 通過将相關技術加以整合，已經有了不錯的産品可用，如網易輕舟微服務就是一套産品化設計良好、功能豐富的線上業務中台支撐技術産品。

一般而言，前台也會和線上業務中台一樣采用雲原生等同樣的技術體系，這是因為前台更需要靈活性。在完善的中台支撐之下，前台會比較輕，還可以考慮采用FaaS Serverless技術，不過目前這方面的實踐還不多（特别在中國），相關的支撐技術也不是很成熟。 

建設資料中台一般需要一整套如下典型的支撐技術： 

· 名額管理系統：名額是中台與前台之間最關鍵的接口，也是建設資料中台的牛鼻子，因為它是最核心的業務語言，且名額不一緻、資料常出錯是建設資料中台最常見的出發點。如果名額體系沒有統一的方法論，進行統一建設，那麼就很難說是資料中台。名額管理系統一般要實作一套一緻的方法論（如原子 / 派生 / 複合名額、次元、修飾詞等），做好名額的業務和技術口徑管理，還需要支援名額的審批管理。資料中台的名額無法交給各前台業務自助式的建設。 

· 資料服務系統：類似于線上業務中台需要通過API網關提供标準化的服務，資料中台也需要一個标準化的服務方式，通常稱為資料服務系統，也可以說是資料網關或資料門戶。類似于别的網關類産品，資料服務系統需要提供鑒權、日志審計、流控、協定轉換（如SQL Dialect之間的轉換）等功能，也應該發展多引擎融合查詢、邏輯模型等擴充功能以提高服務接口的穩定性和實作的靈活性。 

· 中繼資料管理系統：中繼資料管理是整個資料中台的基礎和中心，所有的其他系統都依賴中繼資料管理。中繼資料管理首先要做好的當然是資料模式或目錄（catalog）的管理，至少要知道中台裡都有什麼資料。對複雜的資料中台來說，資料血緣也很重要。沒有血緣資訊，不知道資料間的依賴關系，資料品質肯定管不好，因為不知道一個資料的品質問題怎麼來，又進而會影響什麼。同樣的如果沒有血緣，資料資産也肯定管不好，因為不知道什麼資料有價值什麼沒價值，這就像如果你不知道一個函數被誰調用，你就不知道它是不是死代碼一樣。中繼資料管理系統往往也需要提供一個基礎的通路界面，通常稱之為資料地圖。 

· 資料倉庫開發與管理系統：除了名額管理，資料倉庫的開發是将一大堆初始資料建設梳理成一個漂亮的資料中台的核心過程。一般來講資料中台更适合用Kimball的次元模組化方法而非資料倉庫之父Bill Inmon所提倡的方法，這是因為Inmon強調頂層設計，而Kimball強調至下而上。如果要建設資料中台，肯定是因為前台業務複雜多變，這時強調頂層設計會導緻中台建設緩慢、僵化。因為中台雖然應該是由組織高層決策，但目的卻是為了支援前台業務，而不是為了控制。 支援而不是控制，這一點絕不能本末倒置。 

· 資料品質管理系統：所有複雜的系統都需要專業的品質管理，線上業務系統有一系列的彈力設計和APM等監控運維工具，資料中台也需要專業的品質管理。資料品質管理系統通常設計為支援豐富的稽核 / 校驗 / 比對規則，監控資料是否準确、實時、一緻，還要做到及時的報警，分析影響面，提供快速修複的手段等。但這些手段隻能發現和補救問題，不能預防問題，要預防問題，還要通過測試工具減少代碼bug、通過資源彈性應對性能波動、通過優先級排程優先滿足重要業務需求等。相對來說，目前資料中台領域的品質管理沒有線上業務領域的成熟，如線上業務領域的測試手段遠比資料領域的精細，線上業務領域很常見的熔斷、限流、服務降級等模式在資料領域都沒有成熟的實踐方法（優先級排程可以說是實作了部分的服務降級功能），随着資料中台越來越廣泛和重要，這些技術應該也需要持續發展，但技術上的挑戰不小。 

· 資料安全管理系統：資料中台因為彙集了組織所有有價值的資料資産，是以良好的安全管理是必須的。細粒度的權限和審計是基礎，一般的還需要隐私 / 敏感資料的脫敏處理、資料加密（特别是将資料托管在第三方平台之上時）、資料洩漏防護（比方說一種常見的方法是限制将資料下載下傳到本地的資料量）等技術。發展到進階階段甚至可能還需要聯邦學習、資料沙盒等技術。 

· 資料資産管理系統：在資料品質和安全單列的情況下，資料資産管理主要負責的是資料的生命周期管理、成本的統計分析與優化等工作。

同時，資料中台還需要強大的大資料計算引擎、資料內建 / 同步 / 交換引擎，還往往需要一套靈活BI系統：

· 大資料計算引擎：資料中台要管理的資料規模和複雜度往往都很高（否則搞中台屬于為賦新詞強說愁），是以傳統的資料庫和資料倉庫基本上支撐不了。目前的技術環境下，基于Hadoop MapReduce或Spark幾乎是唯二的選擇，當然這也包括了這兩者之上的Hive和Spark SQL。能用SQL就用SQL，易于維護，也易于資料血緣的收集。除此之外，流處理可能還需要Flink，互動式查詢可能要引入Impala或GreenPlum。

· 資料內建 / 同步 / 交換引擎：一方面資料中台需要強大的資料內建和同步能力才能吸納各方資料。內建和同步的概念相近，同步更強調實時性。另一方面，資料中台往往由多種資料計算引擎構成，就需要同步或交換引擎實作不同引擎見的資料交換。

· 靈活BI系統：建設資料中台通常最重要的目的是為了支援業務營運和決策，為此需要基于資料中台進一步開發資料産品。靈活BI系統是開發資料産品快速、輕型的手段，能夠盡快盡早的發揮資料中台的價值。

此外，對于網際網路業務，統一的埋點引擎往往也是資料中台所需要的。如果埋點的邏輯都不統一的話，建資料中台的時候會發現資料的源頭就是亂的，後續也都沒法做。其他行業業務，資料采集也屬于基礎工作，也是要先做好的。

由此可見，建設資料中台需要的技術支撐體系也是相當的龐大，複雜。所幸的是這十年來Google等領先的企業、Hadoop / Spark等開源社群以及大量的廠商大緻聯合探索出了一條可行的路徑，方法論和技術路線都比較統一了。以此為基礎，就可以提供較成熟的資料中台技術支撐産品，如網易杭研研發的“網易猛犸V6.0 + 網易有數”就是一套較完整的資料中台産品。

複雜事務都需要方法論的指導（和限制），組織管理有虛虛實實的一大套各種理論，研發有靈活方法或IPD流程，中台是複雜事務，是以也需要方法論。因為中台建設涉及組織和技術兩個次元，是以中台的方法論也應該要覆寫這兩個次元。目前而言，技術次元的方法論相對成熟，因為複用了很多原有的方法論。 

對于業務中台，微服務、網關、REST API及語義化版本控制、六邊形架構是側重于技術架構的方法論，DevOps、靈活項目管理是側重于流程層面的方法論，領域驅動設計（DDD）是側重于業務架構的方法論。要做好業務中台，以上方法論大概都不可或缺。 

大家可以看到，除了微服務跟中台大緻是同步發展的之外，其他方法論都是早前就存在的東西。正因為有這麼多合适的方法論存在，中台才變得可行，無論如何在短期内要發展出這麼多方法論是不現實的，因為方法論的威力不僅在于它要好，還在于它要流行。 

技術架構和流程方面的方法論已經很流行，無需多說（六邊形架構放在和DDD一起介紹）。值得關注的是領域驅動設計這麼一個10多年前就被提出，這麼多年一直不溫不火的方法論，突然在中台領域似乎找到了它的最佳安身之所。這樣的現象是會昙花一現，還是會長期持續，值得思考。 

DDD的核心概念是通用語言和限界上下文。通用語言指的是在一個業務領域内通用（但不是在更大的領域内也完全通用的）的概念、術語等語言，限界上下文指的是相鄰通用語言之間“翻譯”的邊界，比如前台業務的使用者可能要變成背景清算的客戶。 

我覺得DDD的通用語言和一直以來的領域模組化是比較相似的，更具創新意義的是限界上下文。在架構設計中，我們要不要構造那種擁有非常多屬性，但每個使用者隻使用少量屬性，或者屬性的名稱和含義對使用者來說不貼切的對象？如果沒有限界上下文的限制，可能會認為這樣畢竟實作了更多的複用，是好的，但用限界上下文的理念來看，這樣很可能是不好的。每個領域應該專注于自己領域的語言，領域之間要互動怎麼辦？加一種翻譯機制，也就是限界上下文解決。 

領域驅動和限界上下文的理念會自然延伸出六邊形架構的設計。所謂六邊形架構指的是一個程式的内部隻需要處理業務邏輯，他的資料 / 請求從哪裡來，資料要存儲到哪裡去（或者領域事件要釋出），都通過各種擴充卡完成。因為這樣的擴充卡可能較多，就不再像傳統的三層（三明治）架構。不過如果六邊形隻有一個Input和一個Output擴充卡的話，和三層架構就還是差不多的。我想從三層架構進化到六邊形架構的主要原因還是因為現在的環境已經從傳統的C / S或B / S這樣隻有一個前端，也隻有RDBMS這樣的一個後端發展到前面有Web / 移動等多個端，向後也有RDBMS / NoSQL等多個端，橫向也有服務化 / MQ等多個端的多端環境。我不知道哪天會不會發展出一個十面埋伏架構出來。 

資料中台的方法論也是博采衆長，最核心的來自于資料倉庫領域關于資料倉庫規劃實施和名額體系建設的方法。在資料倉庫領域，有兩套截然不同的方法之前一直是較勁的，一個是資料倉庫之父Bill Inmon所倡導的至上而下的方法，另一個是另一位大師級人物Kimball所倡導的至下而上的方法。在我了解，所謂Kimball的模式之是以說是至下而上，是因為基本上中台團隊隻負責從ODS到DWD到DWS就完了，往上就是所謂的ADS，其實已經是面向各個業務（或者資料産品）了。你都可以說ADS層不屬于數倉。這樣的方法在中台作為一種新生事務沒法有很強的話語權時顯然是更容易做出的選擇，可能未來中台概念深入人心，集團高度重視，說不定Inmon方法又會重新流行？但也可以思考這種細節上都展現了上司的管理意志的中台還是中台嗎。名額設計的方法論基于Kimball方法中的粒度模組化的方法，做了比較大的細化和改進。 

劃分主題域是建資料中台的常見實踐，不過主題域劃分與行業強相關，比如對零售業常見的有商品、交易、流量、使用者、營銷等域。 

資料中台統一通過資料服務系統實作OneService的設計，不清楚有什麼來源，不過類似于在業務架構中很常見的網關模式。資料品質、資料安全、中繼資料、生命周期管理也都是資料治理領域比較常見的概念，但一方面要實作針對大資料技術環境的落地，另一方面更面向業務支援而非管控來設計。 

實施資料中台通常還需要制定很多規範或标準，這也可以說是方法論的一方面。有很多規範是命名規範，其中數量最大的往往是資料倉庫中的表，上萬張表甚至更多都是很常見的，是以表的規範命名非常必要。一種好的表的命名規範，要反映其所在數倉分層、主題域、業務過程、時間周期等資訊。計算任務也需要一定的命名規範。資料埋點也需要規範性的編碼位置資訊、内容資訊和事件資訊。 

其他類型的中台也都有各自的方法論。如搜尋中台，B公司有比較詳細的對外分享的資料，其方法論主要展現在規範了搜尋系統的關鍵流程，如内容引入和加工、離線訓練、線上召回和排序等，還會涉及到查詢改寫、展示設計等要點。 

以上說的都是中台技術次元的方法論，組織次元的方法論目前還沒有看到好的系統性分析成果。在《企業IT架構轉型之道》中隻有很少的篇幅介紹中台組織次元的方法論，在另一本講資料中台的書中，幹脆就隻字沒提組織方面的内容。業界關于中台組織的方法論，主要包括多職能小微團隊、業務架構師主導、協作溝通機制、輪崗、共建、考核機制等。業界也有從一般性的組織管理次元（如垂直型組織、矩陣型組織等等）分析，過于寬泛，說了等于沒說。 

中台組織層面的方法論可能是相對不成熟的，比如中台和前台、平台之間的邊界和動向問題，似乎沒有明确的方法。我認為可能主流會符合“前台->中台->平台“單向流動的中心法則。可能中台組織的終極目标是發展為平台，因為還是要追求把能力做成熟和标準，我這也可能是很反動的說法。 

作為集團的創新業務孵化中心，網易杭研每時每刻都針對很多業務線要并行發展，為此打造了一個又一個共享能力中心，千方百計提升創新效率。12年來感覺摸索了一些關于中台的建設經驗，當然可能更多的是教訓，這段經曆的體會後續我将會做個梳理，發出來供大家讨論。 

說到咨詢，我首先想到的是技術進步的驅動力發生了很大的變化，從廠商和咨詢公司驅動變成了領先客戶驅動。以線上業務為例，傳統的SOA和Web Services技術是傳統廠商驅動的。這些廠商自己不用産品但要賣産品，是以一不小心就把産品搞的不必要的複雜。另外這些廠商和咨詢公司本來就是共生共榮的關系，是以也得把産品搞的複雜一點吧，不然咨詢公司就沒生意了。新生代的微服務技術主要是領先的網際網路企業驅動的，自己造産品自己用，能簡單一點就簡單一點，最好是做成各個業務部門自己就能用。 

是以新生代的中台技術是盡力将咨詢的必要性盡量降低的，但是因為目前實踐中台的都是很大的網際網路企業，業務複雜度不可避免的很高，對于大多數想要實踐中台的非網際網路企業來說，仍然是需要咨詢服務。 

現狀是，目前中台的咨詢非常欠缺。因為這些中台都是網際網路企業搞的，目前的廠商和咨詢公司都沒什麼能力做這塊的咨詢。我們可以看到一些咨詢公司，不懂中台，把什麼都往中台的概念上湊。目前也就網際網路企業或有很強網際網路企業背景的團隊才有能力做咨詢，但資源很有限。希望咨詢公司們能夠聚焦于真正的中台，透徹了解什麼是中台，提升自己的咨詢能力。 

網易副總裁，網易杭州研究院執行院長 汪源 

2006年獲浙江大學計算機專業博士學位，之後加入網易公司。現作為網易杭州研究院執行院長，全面負責網易集團公共技術支撐工作與雲計算、大資料業務，主要包括雲計算與服務端架構、前端技術、大資料挖掘分析、資訊安全、多媒體、運維、品質保障等方向。

點選連結更多關于網易資料中台