[[359073]]

00 中臺能力總體框架

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

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

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

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

01 業務中臺

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

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

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

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

▲圖2-2 業務中臺示例

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

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

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

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

02 數據中臺

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

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

第一，數據應用技術發展迅猛。近幾年涌現出了大量新的數據應用技術，如NoSQL、NewSQL和分布式數據庫等，以及與數據采集、數據存儲、數據建模和數據挖掘等大數據相關的技術。這些技術解決業務問題的能力越來越強，但同時也增加了技術實現的復雜度。

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

第三，數據來源更加多元化，數據格式更加多樣化。隨著車聯網、物聯網、LBS和社交媒體等數據的引入，數據來源已從單一的業務數據向復雜的多源數據轉變，數據格式也已經從以結構化為主向結構化與非結構化多種模式混合的方向轉變。

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

面對復雜的數據領域，如何建設數據中臺管理并利用好這些數據？

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

數據中臺的大部分數據來源于業務中臺，經過數據建模和數據分析等操作后，將加工后的數據，返回業務中臺為前臺應用提供數據服務，或直接以數據類應用的方式面向前臺應用提供API數據服務。

數據中臺一般包括數據采集、數據集成、數據治理、數據應用和數據資產管理，另外還有諸如數據標準和指標建設，以及數據倉庫或大數據等技術應用。圖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和微服務》，經出版方授權發布。