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