導讀：2015年阿里巴巴提出“大中臺，小前臺”的中臺戰略，透過實施中臺戰略找到能夠快速應對外界變化，整合阿里各種基礎能力，高效支撐業務創新的機制。

阿里巴巴中臺戰略最早從業務中臺和資料中臺建設開始，採用了雙中臺的建設模式，到後來發展出了移動中臺、技術中臺和研發中臺等，這些中臺的能力綜合在一起就構成了阿里巴巴企業級數字化能力。

傳統企業在技術能力、組織架構和商業模式等方面與阿里巴巴存在非常大的差異，在實施中臺戰略時是否可以照搬阿里巴巴中臺建設模式？傳統企業中臺數字化轉型需要提升哪些方面的基本能力呢？

下面我們一起來分析分析。

00 中臺能力總體框架

中臺建設過程從根本上講是企業自身綜合能力持續最佳化和提升的過程，最終目標是實現企業級業務能力複用和不同業務板塊能力的聯通和融合。

企業級的綜合能力，一般包含以下四種：業務能力、資料能力、技術能力和組織能力，如圖2-1所示。

▲圖2-1 企業中臺數字化轉型基本能力框架

業務能力主要體現為對中臺領域模型的構建能力，對領域模型的持續演進能力，企業級業務能力的複用、融合和產品化運營能力，以及快速響應市場的商業模式創新能力。資料能力主要體現為企業級的資料融合能力、資料服務能力以及對商業模式創新和企業數字化運營的支撐能力。技術能力主要體現為對裝置、網路等基礎資源的自動化運維和管理能力，對微服務等分散式技術架構體系化的設計、開發和架構演進能力。組織能力主要體現為一體化的研發運營能力和敏捷的中臺產品化運營能力，還體現為快速建設自適應的組織架構和中臺建設方法體系等方面的能力。這些能力相輔相成，融合在一起為企業中臺數字化轉型發揮最大效能。接下來，我們一起來看看在不同的領域應該如何實現這些能力。01 業務中臺

企業所有能力建設都是服務於前臺一線業務的。從這個角度來講，所有中臺應該都可以稱為業務中臺。但我們所說的業務中臺一般是指支援企業線上核心業務的中臺。

業務中臺承載了企業核心關鍵業務，是企業的核心業務能力，也是企業數字化轉型的重點。業務中臺的建設目標是：“將可複用的業務能力沉澱到業務中臺，實現企業級業務能力複用和各業務板塊之間的聯通和協同，確保關鍵業務鏈路的穩定高效，提升業務創新效能。”

業務中臺的主要目標是實現企業級業務能力的複用，所以業務中臺建設需優先解決業務能力重複建設和複用的問題。透過重構業務模型，將分散在不同渠道和業務場景（例如：網際網路應用和傳統核心應用）重複建設的業務能力，沉澱到企業級中臺業務模型，面向企業所有業務場景和領域，實現能力複用和流程融合。

圖2-2是一個業務中臺示例。在業務中臺設計時，我們可以將使用者管理、訂單管理、商品管理和支付等這些通用的能力，透過業務領域邊界劃分和領域建模，沉澱到使用者中心、訂單中心、商品中心和支付中心等業務中臺，然後基於分散式微服務技術體系完成微服務建設，形成企業級解決方案，面向前臺應用提供可複用的業務能力。

▲圖2-2 業務中臺示例

在技術實現上，中臺的系統落地可以採用微服務架構。微服務是目前公認的業務中臺技術最佳實現，可以有效提升業務擴充套件能力，實現業務能力複用。

在業務建模上，中臺領域建模可以採用領域驅動設計（DDD）方法，透過劃分業務限界上下文邊界，構建中臺領域模型，根據領域模型完成微服務拆分和設計。

業務中臺可以面向前臺應用提供基於API介面級的業務服務能力，也可以將領域模型所在的微服務和微前端組合為業務單元，以元件的形式面向前臺應用，提供基於微前端的頁面級服務能力。

業務中臺建設完成後，前臺應用就可以聯通和組裝各個不同中臺業務板塊，既提供企業級一體化業務能力支撐，又可以提供靈活的場景化銷售能力支撐。

02 資料中臺

資料中臺與業務中臺相輔相成，共同支援前臺一線業務。資料中臺除了擁有傳統資料平臺的統計分析和決策支援功能外，會更多聚焦於為前臺一線交易類業務提供智慧化的資料服務，支援企業流程智慧化、運營智慧化和商業模式創新，實現“業務資料化和資料業務化”。

最近幾年，資料應用領域出現了很多新的趨勢。資料中臺建設模式也隨著這些趨勢在發生變化，主要體現在以下幾點。

第一，資料應用技術發展迅猛。近幾年湧現出了大量新的資料應用技術，如NoSQL、NewSQL和分散式資料庫等，以及與資料採集、資料儲存、資料建模和資料探勘等大資料相關的技術。這些技術解決業務問題的能力越來越強，但同時也增加了技術實現的複雜度。

第二，資料架構更加靈活。在從單體向微服務架構轉型後，企業業務和資料形態也發生了很大的變化，資料架構已經從集中式架構向分散式架構轉變。

第四，資料智慧化應用將會越來越廣泛。在數字新基建的大背景下，未來企業將彙集多種模式下的資料，藉助深度學習和人工智慧等智慧技術，最佳化業務流程，實現業務流程的智慧化，透過使用者行為分析提升使用者體驗，實現精準營銷、反欺詐和風險管控，實現數字化和智慧化的產品運營以及AIOps等，提升企業數字智慧化水平。

面對複雜的資料領域，如何建設資料中臺管理並利用好這些資料？

這對企業來說是一個非常重要的課題。

資料中臺一般包括資料採集、資料整合、資料治理、資料應用和資料資產管理，另外還有諸如資料標準和指標建設，以及資料倉庫或大資料等技術應用。圖2-3是2017年阿里雲棲大會上的一個數據中臺示例。

▲圖2-3 資料中臺示例（圖參考：2017年阿里雲棲大會）

綜上所述，資料中臺建設需要做好以下三方面的工作。

一是建立統一的企業級資料標準指標體系，解決資料來源多元化和標準不統一的問題。企業在統一的資料標準下，規範有序地完成資料採集、資料建模、資料分析、資料整合、資料應用和資料資產管理。二是建立與企業能力相適應的資料研發、分析、應用和資產管理技術體系。結合企業自身技術能力和資料應用場景，選擇合適的技術體系構建資料中臺。三是構建支援前臺一線業務的資料中臺。業務中臺微服務化後，雖然提升了應用的高可用能力，但是隨著資料和應用的拆分，會形成更多的資料孤島，會增加應用和資料整合的難度。在業務中臺建設的同時，需要同步啟動資料中臺建設，整合業務中臺資料，消除不同業務板塊核心業務鏈條之間的資料孤島，對外提供統一的一致的資料服務。用“業務+資料”雙中臺模式，支援業務、資料和流程的融合。

資料中臺投入相對較大，收益週期較長，但會給企業帶來巨大的潛在商業價值，也是企業未來數字化運營的重要基礎。企業可以根據業務發展需求，制定好階段性目標，分步驟、有計劃地整合好現有資料平臺，演進式推進資料中臺建設。

03 技術中臺

業務中臺落地時需要有很多的技術元件支撐，這些不同技術領域的技術元件就組成了技術中臺。業務中臺大多采用微服務架構，以保障系統高可用性，有效應對高頻海量業務訪問場景，所以技術中臺會有比較多的微服務相關的技術元件。

一般來說，技術中臺會有以下幾類關鍵技術領域的元件，如API閘道器、前端開發框架、微服務開發框架、微服務治理元件、分散式資料庫以及分散式架構下諸如複製、同步等資料處理相關的關鍵技術元件，如圖2-4所示。

1. API閘道器

微服務架構一般採用前後端分離設計，前端頁面邏輯和後端微服務業務邏輯獨立開發、獨立部署，透過閘道器實現前後端整合。

前臺應用接入中臺微服務的技術元件一般是API閘道器。

API閘道器主要包括：鑑權、降級限流、流量分析、負載均衡、服務路由和訪問日誌等功能。API閘道器可以幫助使用者，方便地管理微服務API介面，實現安全的前後端分離，實現高效的系統整合和精細的服務監控。

2. 開發框架

開發框架主要包括前端開發框架和後端微服務開發框架。基於前、後端開發框架，分別完成前端頁面邏輯和後端業務邏輯的開發。

前端開發框架主要是面向PC端或者移動端應用，用於構建系統表示層，規範前後端互動，降低前端開發成本。

▲圖2-4 技術中臺關鍵技術領域

微服務開發框架用於構建企業級微服務應用。一般具備自動化配置、快速開發、方便除錯及部署等特性，提供微服務註冊、發現、通訊、容錯和監控等服務治理基礎類庫，幫助開發人員快速構建產品級的微服務應用。

開發框架一般都支援程式碼自動生成、本地除錯和依賴管理等功能。

3. 微服務治理

微服務治理是在微服務的執行過程中，針對微服務的執行狀況採取的動態治理策略，如服務註冊、發現、限流、熔斷和降級等，以保障微服務能夠持續穩定執行。

微服務治理主要應用於微服務執行中的狀態監控、微服務執行異常時的治理策略配置等場景，保障微服務在常見異常場景下的自恢復能力。

微服務治理技術元件一般包括服務註冊、服務發現、服務通訊、配置中心、服務熔斷、容錯和微服務監控等元件。

常見的微服務治理有Dubbo、Spring Cloud和Service Mesh等技術體系。

4. 分散式資料庫

分散式資料庫一般都具有較強的資料線性擴充套件能力，它們大多采用資料多副本機制實現資料庫高可用，具有可擴充套件和低成本等技術優勢。

分散式資料庫一般包括三類：交易型分散式資料庫、分析型分散式資料庫和交易分析混合型分散式資料庫。

交易型分散式資料庫用於解決交易型業務的資料庫計算能力，它支援資料分庫、分片、資料多副本，具有高可用的特性，提供統一的運維介面，具備高效能的交易型業務資料處理能力。主要應用於具有跨區域部署和高可用需求，需支援高併發和高頻訪問的核心交易類業務場景。分析型分散式資料庫透過橫向擴充套件能力和平行計算能力，提升資料整體計算能力和吞吐量，支援海量資料的分析。主要應用於大規模結構化資料的統計分析、高效能互動式分析等場景，如資料倉庫、資料集市等。交易分析混合型分散式資料庫透過資源隔離、分時和資料多副本等技術手段，基於不同的資料儲存、訪問效能和容量等需求，使用不同的儲存介質和分散式計算引擎，同時滿足業務交易和分析需求。主要應用於資料規模大和訪問併發量大，需要解決交易型資料同步到分析型資料庫時成本高的問題，需要解決資料庫入口統一的問題，需要支援高可用和高擴充套件性等資料處理業務場景。

5. 資料處理元件

為了提高應用效能和業務承載能力，降低微服務的耦合度，實現分散式架構下的分散式事務等要求，技術中臺還有很多資料處理相關的基礎技術元件。如：分散式快取、搜尋引擎、資料複製、訊息中介軟體和分散式事務等技術元件。

分散式快取是將高頻熱點資料集分佈於多個記憶體叢集節點，以複製、分發、分割槽和失效相結合的方式進行維護，解決高併發熱點資料訪問效能問題，降低後臺資料庫訪問壓力，提升系統吞吐能力。典型的開源分散式快取技術元件有Redis。搜尋引擎主要解決大資料量的快速搜尋和分析等需求。將業務、日誌類等不同型別的資料，載入到搜尋引擎，提供可擴充套件和近實時的搜尋能力。資料複製主要解決資料同步需求，實現同構、異構資料庫間以及跨資料中心的資料複製，滿足資料多級儲存、交換和整合需求。主要應用於基於表或庫的業務資料遷移、業務資料向資料倉庫複製等資料遷移場景。資料複製技術元件大多采用資料庫日誌捕獲和解析技術，在技術選型時需考慮資料複製技術元件與源端資料庫的適配能力。訊息中介軟體主要適用於資料最終一致性的業務場景，它採用非同步化的設計，實現資料同步轉非同步操作，支援海量非同步資料呼叫，並透過削峰填谷設計提高業務吞吐量和承載能力。它被廣泛用於微服務之間的資料非同步傳輸、大資料日誌採集和流計算等場景。另外，在領域驅動設計的領域事件驅動模型中，訊息中介軟體是實現領域事件資料最終一致性的非常關鍵的技術元件，可以實現微服務之間的解耦，滿足“高內聚，松耦合”設計原則。典型的開源訊息中介軟體有Kafka等。

分散式事務主要是解決分散式架構下事務一致性的問題。單體應用被拆分成微服務後，原來單體應用大量的內部呼叫會變成跨微服務訪問，業務呼叫鏈路中任意一個節點出現問題，都可能造成資料不一致。分散式事務是基於分散式事務模型，保證跨資料庫或跨微服務呼叫場景下的資料一致性。

分散式事務雖然可以實時保證資料的一致性，但過多的分散式事務設計會導致系統性能下降。因此微服務設計時應優先採用基於訊息中介軟體的最終資料一致性機制，儘量避免使用分散式事務。

技術中臺是業務中臺建設的關鍵技術基礎。在中臺建設過程中，可以根據業務需要不斷更新和吸納新的技術元件，也可以考慮將一些不具有明顯業務含義的通用元件（如認證等），透過抽象和標準化設計後納入技術中臺統一管理。為了保證業務中臺的高效能和穩定性，在技術元件選型時一定要記住：儘可能選用成熟的技術元件。

關於作者：歐創新，某大型保險公司架構師，擁有十多年的軟體架構設計經驗。熱衷於DDD、中臺和分散式微服務架構設計。在DDD、中臺和分散式微服務架構設計方面有深厚的積累，擅長分散式微服務架構設計。鄧頔，某大型保險公司高階工程師，全國青年崗位能手。致力於基於DDD的企業級中臺微服務架構改造實踐，精通前端開發相關技術棧，擁有豐富的企業級微前端實戰經驗。

本文摘編自《中臺架構與實現：基於DDD和微服務》，經出版方授權釋出。

延伸閱讀《中臺架構與實現》

推薦語：資深架構師撰寫，系統闡述基於DDD的中臺和微服務建設方法論，深刻揭示中臺從領域建模到微服務落地完整過程。