作者 | 耿立超
責編 | 晉兆雨
來源 | 《大數據平台架構與原型實現：數據中台建設實戰》
中台打破了應用系統的壁壘，從企業全局梳理和規劃業務程，重構了組織架構、業務架構與IT 架構。
在梳理了企業的IT 現狀並回顧了SOA 的歷史之後，我們需要對中台架構進行一番詳細的介紹，阿里巴巴的Aliware 團隊曾經給中台下過這樣的定義：
將企業的核心能力隨著業務不斷發展以數字化形式沉澱到平台，形成以服務為中心，由業務中台和數據中台構建起數據閉環運轉的運營體系，供企業更高效地進行業務探索和創新，實現以數字化資產的形態構建企業核心差異化競爭力。
現在中台戰略常被簡單地概括為「大中台，小前台」，意思是說將企業的核心業務能力沉澱和聚集到由業務中心組成的中台層上，前台應用以中台為支撐，向輕量化、敏捷化轉變。本文核心觀點援引自作者所著的《大數據平台架構與原型實現：數據中台建設實戰》一書，全書對數據中台的理念、架構和具體實現做了詳細論述。
圖1 戰場中的中台陣型
圖1 是《企業IT 架構轉型之道：阿里巴巴中台戰略思想與架構實戰》一書中給出的關於中台戰略非常形象的描述。這張圖描述的是美軍現行的作戰模式，在一線戰場，美軍通常以班為單位組織軍事行動，這種極小型團隊行動敏捷，容易捕獲戰機，一旦發現敵情就通過指揮系統呼叫強大的炮火和空中支援給敵軍以重創。美軍的這種戰場組織陣型與中台架構的思想是一致的，戰鬥小組就是「小前台」，強大的炮火群和空中力量是「大中台」。在強大中台的有力支撐下，前端在進行業務運營和創新時會變得非常高效且靈活，企業可以根據最新的市場動態展開各種嘗試和調整，一旦發現並驗證了新的市場機遇，就可以調集中台的強大能力迅速跟進，搶占市場。
中台作為面向網際網路時代的企業新一代IT架構最大的威力不在於解決眼前的問題，而是系統性、結構性地重組企業的IT 生態系統、業務架構及組織架構，它能幫助企業從本質上提升競爭力，降低成本。它將帶給企業如下的能力與收益：
-
應對未來所需的更快的業務創新和成本更低的業務探索；
-
給企業帶來核心競爭力的提升，提質轉型、降本增效；
-
給業務快速響應和創新帶來的業務價值；
-
給信息中心帶來組織職能轉變的機會；
-
共享服務架構能提升企業整體效能。
中台架構概述
以中台的視角看待企業的整個IT 生態，可以將其分成前台、中台及後台三大組成部分，三者的定位如下：
-
前台：由直接面向市場和終端用戶的業務應用組成，負責支撐企業的前端業務；
-
中台：由按業務領域細分的服務中心組成，負責支撐企業的共享業務；
-
後台：由企業內部業務系統組成，如生產、庫存、物流等管理系統。
前台與中台的關係是：業務中台負責提供企業範圍內共享的基礎業務服務，前台應用會對這些基礎業務服務進行組織編排，快速地在前端以產品形式將業務能力展開，以適應日新月異的市場變化。
中台與後台的關係並不像前台與中台的關係那樣緊密，中台架構是為了讓企業擁有開放、創新和靈活的市場應變能力而提出的，這對於生產、庫存、物流等後端系統的影響並不大，並且這些系統需要嚴謹和規範的組織與管理，因而會保持相對傳統的組織架構與生態。
由此可見，中台在企業的整體業務體系中起著核心作用，而建設中台的最大挑戰也來自對中台層各服務中心業務能力的提煉和萃取。
以零售和消費品行業的企業為例，往往會有如下一些面向市場和終端消費者的服務中心：
-
用戶中心：負責用戶信息的全面管理，建設和維護會員體系，制定並推行會員運營策略；
-
商品中心：負責商品的全面管理，包括SKU、品類及商品相關的各種屬性、標籤的管理；
-
交易中心：負責統一管理線上和線下所有的購物車、訂單及交易數據，並提供交易相關的各種服務；
-
營銷中心：負責全渠道的營銷，對營銷活動的全過程進行管理。
以上四個是比較有代表性的業務中心，每一家企業還可能會基於自己的業務模式組織其他諸如支付、門店、內容、促銷等中心。從服務中心的職責和定位我們也可以發現中台的一個重要特徵，那就是應用系統的邊界被徹底地打破了，不會再有CRM 和OMS 這樣的孤立業務系統了，而是將它們所承載的共享業務能力分拆並重組到了各個業務中心，每個業務中心對接和服務的是來自企業全渠道的需求，如何能支撐這些複雜多變的前端需求是建設中台的挑戰之一。針對每個業務中心，在業務和技術上都必須要有專業的架構師帶領團隊來統一梳理這些需求，識別哪些需求應該由中台實現，哪些需求應該由前台實現，這是確保中台架構能夠合理存在並穩定發揮作用的重要前提，這個過程不會一蹴而就，而需要在不斷的疊代和試錯中逐漸明了。不難想像，如果這種切分不夠合理就會出現如下兩種結果：
-
如果本應屬於共享的服務與邏輯切分到前台，就會導致前台應用過「重」，且不可避免地會出現重複建設問題，因為前台應用無法從中台獲得相關支持；
-
如果過多的非共享服務與邏輯切分到中台，就會導致中台服務的復用性變差，前台應用無法直接調用，因此會產生很多「副作用」和「連帶後果」。
以上兩種情形在現實里時有發生，這是企業打磨中台的一個必經階段，也是團隊磨鍊對業務認知和對技術把控能力的一場「修行」。
就「服務」這個概念而言，中台對外提供的「服務」與SOA 中倡導的「服務」並沒有本質上的差別。在某種程度上，中台的定位會更加有助於實現真正可重用的「服務」，因為中台不再局限於某一個應用上，而是超脫於應用之上，宏觀地看待一個「服務」如何能支持不同場景下的共性需求。因此，那些在SOA 中對服務粒度進行界定和組織的方法依然是值得借鑑的，特別是對基礎服務、複合服務及業務流程服務這三個服務層次的劃分是非常實用的。
作為一個呼應，我們來看一下中台架構下「會員管理」是如何進行的：原有的CRM 系統將不復存在，取而代之的是「用戶中心」，用戶中心沉澱了與用戶相關的共享服務，會員註冊就是其中之一，前台應用系統進行會員註冊時會調用用戶中心上的會員註冊API 來實現，當然，前台應用可能需要對用戶數據進行一定的處理、轉換以適配統一的API 規範，這樣前台各個應用不再維護自己的「用戶模塊」，因此也不再需要同步會員數據。
前面我們討論的「中台」更具體地說是指業務中台，對於中台的另一個組成部分「數據中台」來說，它更側重於企業數據的統一收集和處理。相對於應用系統而言，數據的平台化要相對容易一些，這也是很多企業早期就能建立數倉這種中心化、平台化的系統，而在應用系統上卻陷入煙囪式的生態的原因之一。不過數據中台並不是傳統數倉升級換代那麼簡單，從技術上講，數據中台完全構建在大數據平台上，數倉是數據中台的重要組成部分，但遠遠不是全部。數據中台通常還要具備實時的數據處理能力和高級的算法分析能力，當數據處理完成後，數據中台還要提供強大的「數據服務」，能將結果數據通過各種協議以實時或批量的方式提供給業務中台或應用前台。
此外，業務中台的建立也會對數據中台的建設起到很大的促進作用。一方面由於業務的梳理和中心化，使採集業務數據變得相對簡單，業務中心的後台資料庫將是數據中台主要的外圍數據源；另一方面，業務中台對業務的切分和領域建模將對構建數據中台上的數倉和數據服務有很大的指導意義，例如，每個業務中心天然就是一個大的數據主題，相應地，也有會有一個獨立的API 的namespace 等。
下面我們把業務中台和數據中台放在一起，結合前面舉例的零售和消費品行業來看看一個完整的中台架構，如圖2 所示。
圖2 中台邏輯架構示意圖
這是一張混合了技術和業務的中台邏輯架構示意圖，前台應用部分我們將零售和消費品行業需要對接消費者的若干應用系統一一列舉了出來，但是在中台架構下它們已經和傳統的「應用系統」有了很大的差別，變得非常「輕量」。過去很多自行實現的業務功能都通過調用業務中台的各個業務中心完成了，如前面列舉的會員註冊功能，在中台架構下都是調用會員中心上的統一接口完成的。與此同時，各業務中心的數據都將通過數據中台上的數據採集組件採集到大數據平台上，然後通過批處理和實時處理機制構建出企業的數倉體系和高級數據分析能力，最後通過構建數據API （Web 服務）、OLAP 及專有的報表資料庫等手段，將結果數據以Restful API、JDBC/ODBC 或FTP 等形式提供給外部使用。
中台的技術體系
中台由阿里巴巴提出並在業界獲得廣泛認可之後，阿里巴巴就一直希望通過阿里雲平台向企業用戶推廣一整套的中台技術解決方案，這套方案就是Aliware——面向企業級網際網路架構的PaaS 服務。Aliware 包含了企業級分布式應用服務（EDAS）、消息隊列（MQ）、全局事務服務（GTS）等，這些服務涵蓋了企業應用開發涉及的各個方面。但是中台並非必須構建在阿里雲的這些PaaS 服務上，實際上，Aliware 是將當前企業級應用開發的主流技術和框架封裝成PaaS 服務供開發者直接使用，所以本質上Aliware 與中台架構並沒有必然的關係。
中台作為一種生態系統級的架構，不會受底層技術的制約，反而倚重和遵循業界主流的技術體系，特別是開源的技術平台與框架。簡單地說：
-
業務中台的主要技術體系是：微服務；
-
數據中台的主要技術體系是：大數據。
與技術相配套的是設計思想和方法論，現在微服務的主流設計思想是領域驅動設計，大數據的主要設計思想是數據倉庫理論。我們來分別介紹一下這兩種技術與它們使用的設計理論。
2.1 業務中台技術體系
微服務
微服務架構最大的特徵是解構了過去的單體應用，按照業務功能對系統進行了更細粒度的切分，每一個微服務都是一個可獨立部署的單元，微服務內部高內聚，微服務之間低耦合。系統被微服務化之後會在很多方面得到提升和改善，過去在單一應用伺服器和資料庫伺服器上部署的系統將轉變為純正的分布式系統，部署於多台伺服器上，這相當於賦予了系統水平伸縮能力，同時局部節點的失效也不會再導致整個系統宕機，而是可以被限制在有限影響範圍之內。
微服務的這些優勢使其在最近幾年幾乎成了企業級應用的架構標準，與之相配套的是一系列基礎設施服務和支撐技術。
-
服務註冊與發現；
-
服務配置管理；
-
服務網關（API Gateway）；
-
事件/消息總線；
-
負載均衡；
-
容錯與熔斷；
-
監控與報警；
-
安全和訪問控制；
-
日誌收集與處理。
經過多年的沉澱和積累，業界在上述領域有很多成熟工具和框架，其中最主流的一站式方案非Spring Cloud 莫屬。
在微服務架構逐漸形成規模之後，就會對硬體資源虛擬化和自動化部署提出要求，與此同時，伴隨著Docker 的崛起，人們發現容器化與微服務是一組絕佳搭檔，再配合DevOps 技術的推動，最終在業界形成了「微服務 + 容器技術（Dockers + Kubernetes）+ DevOps」三位一體的微服務生態體系，這些技術匯集在一起為微服務的落地和持續演進鋪平了道路。
領域驅動設計
恰到好處的微服務設計是一項很有挑戰性的工作，識別、界定與設計微服務考驗的是開發人員對業務的理解和設計能力，這需要對業務反覆梳理和提煉，再經過仔細地斟酌和拿捏才能有一個比較好的方案。這與技術框架沒有太大的關係，考驗的是設計人員的「內功心法」，也就是設計能力和對業務理解的透徹程度。以往諸多項目的經驗表明，糟糕的設計會極大地削弱微服務的作用，讓其變得粗糙、難以被復用。過去，開發人員一直使用一些常規的方法論來設計微服務，如面向對象（OOD）的設計思想，但是取得的效果並不理想，直到後來領域驅動設計（Domain-DrivenDesign，也被簡稱為DDD）被社區發掘出來，逐漸成了微服務事實上的設計理論。
領域驅動設計最早起源於Eric Evans 在2003 年撰寫的一本名為Domain-Driven Design: Tackling Complexity in the Heart of Software 的著作，這本書全面系統地闡述了領域驅動設計的思想和方法論。早年間DDD 還較為小眾，沒有在業界得到推廣，但是伴隨著微服務的崛起，人們意識到領域驅動設計的諸多思想對於設計微服務有莫大的幫助，一個特別典型的例子就是根據限界上下文（Bounded Context）來劃定微服務邊界。
簡單總結一下，在技術上微服務是實現業務中台的最佳技術方案，再藉助領域驅動設計，中台的業務中心可以構建得足夠靈活和強大。
2.2 數據中台技術體系
在數據中台上，目前的技術選型也是非常統一的，基於Hadoop、Spark的大數據技術是當前構建數據中台的主流方案，本系列也是以大數據技術為基礎來討論如何建設數據中台的。
大數據涉及的技術非常多，在數據採集、存儲、消息隊列、批處理、實時處理、作業調度等諸多環節上都有對應的技術和工具來完成相關工作，在後續的章節里我們會逐一討論它們，但通常人們會用Hadoop、Spark 來指代大數據技術，因為兩者不單單是技術，更代表著一個技術生態圈，在它們背後有一組相關的配套工具。
對於建設數據中台的方法論（確切地說是數據中台的批處理部分），傳統的數據倉庫理論依然是主要的方法論。數據中台的使命是將企業的全域數據收集起來，然後規範地處理它們，最後給到前端應用。對於如何規範地處理數據，目前業界最為成熟的理論是數據倉庫（數倉）。在經過數倉體系的治理之後，最終會在數倉的最上層得到高質量的數據集，然後通過Web Service、ODBC、JDBC等多種數據服務對外發布出去。
簡單總結一下，在技術上Hadoop、Spark 是實現數據中台的主要技術方案，遵循數據倉庫理論對數據進行組織和處理，在最上層封裝為數據服務的形式去支持前台和業務中台對數據的需求。
關於作者：
個人技術博客：
https://laurence.blog.csdn.net/