1、分布式數據庫單元業務應用研究報告北京金融科技產業聯盟2022 年 12 月版權聲明本報告版權屬于北京金融科技產業聯盟，并受法律保護。轉載、編摘或利用其他方式使用本白皮書文字或觀點的，應注明來源。違反上述聲明者，將被追究相關法律責任。編制委員會主任：潘潤紅編委會成員：聶麗琴王志剛李曉棟邢磊胡捷編寫組成員：王莉莉杜蓉李蕭蕭王鵬沖李中原夏文勇王輝李曉歡林海高孝鑫張楠盧道和胡盼盼王楓王栩楊詳合江智睿王睿操蘇強張曉陸天煒戴扶申立軍周日明明玉琢蘇德財黃元霞張積斌黃小慧主審：黃本濤彭衛華統稿：張蕾參編單位：北京金融科技產業聯盟秘書處中國光大銀行股份有限公司中國工商銀行股份有限公司中國平安銀行股份有限公司中國

2、華夏銀行股份有限公司中國建設銀行股份有限公司北京萬里開源有限公司中興通訊股份有限公司深圳前海微眾銀行股份有限公司北京奧星貝斯科技有限公司騰訊云計算（北京）有限責任公司成都虛谷偉業科技有限公司北京百度網訊科技有限公司廣州巨杉數據庫軟件有限公司上海熱璞網絡有限公司摘要摘要在銀行業客戶體驗和數字科技創新雙輪驅動推進下，微服務、單元化架構、分布式數據庫技術的融合已經成為傳統銀行基礎架構演進的一個重要技術趨勢。作為一個新興的技術架構，微服務結合單元化架構與分布式數據庫技術的融合也伴隨著眾多的難點與挑戰，包括但不限于高可靠與容災、單元拆分以及整體運維體系復雜度的提升。本報告將整理金融機構分布式數據庫在單元

3、化場景部署實施需求以及特性需求，并從單元化拆分、單元與分布式數據庫部署對應、單元擴容、高可靠、灰度發布、數據同步、以及運維解決方案等多方面闡述分布式數據庫在單元化業務場景下的部署思路，最后提供金融行業典型試點案例，為金融機構在單元化業務應用場景中使用分布式數據庫提供參考。目錄目錄一、研究背景一、研究背景.1 1（一）單元化概念及架構.1（二）單元類型.3（三）分布式數據庫與單元化.5二、場景分析二、場景分析.8 8（一）單元化場景分析.8（二）分布式數據庫分析.9（三）部署難點與要求.12三、應用方案三、應用方案.1616（一）單元業務拆分.16（二）業務拆分數據庫設計.26（三）數據庫部署方

4、案.31（四）數據庫運維要求.47四、典型案例四、典型案例.5555（一）建設銀行試點案例.55（二）平安銀行試點案例.62（二）華夏銀行試點案例.71（三）微眾銀行試點案例.76（四）支付寶試點案例.86-1-一、研究背景（一）單元化概念及架構1、單元化概念1、單元化概念單元是指一個能完成特定業務操作的自閉環集合，在這個集合中包含了特定業務所需的關鍵服務，以及分配給這個單元的數據。一個單元是可以獨立運行特定業務的最小集合；單元化架構就是把單元作為部署的基本單位，在全棧所有機房中部署若干單元，每個機房里的單元數目不定，任意一個單元都部署了系統所需的特定應用，數據則是全量數據按照某種維度劃分后的

5、一部分。單元是一個縮小版整站，部署了特定業務應用，但他不是全量的數據，因為一個單元只能操作部分數據。以銀行賬戶核心的存貸款服務為例，單元化架構之后，一個單元可以只存儲個人存款服務這個特定業務應用的部分客戶號相關的數據，但這些客戶號所有或絕大部分的個人存款服務都可以在這個單元中完成。2、單元化架構2、單元化架構單元化架構是從并行計算領域發展而來。在分布式服務設計領域，一個單元（Cell）就是滿足某個分區所有業務操作的自包含集合。而一個分區（Shard），則是整體數據集的一個子集，如果你用賬號來劃分用戶，那同樣尾號的那部分用戶就可以認為是一個分區。單元化就是將一個服務設計改造讓其符合單元特征-2-

6、的過程。能夠單元化的系統，很容易在多機房中擴展，且不受機房建設上限限制，因為可以輕易地把幾個單元部署在一個機房，而把另外幾個部署在其他機房。如圖 1 所示，通過在業務入口處設置一個流量調配器，可以調整業務流量在單元之間的比例。圖 1 業務單元化示意圖單元化架構要求系統須具備數據分區能力，數據分區承載了各個單元的業務流量比例。數據分區即是把全局數據按照某一個維度水平劃分開來，每個分區的數據內容互不重疊，每個數據節點有自己應用系統、數據庫。從全行系統的角度看，單元化按照技術或者業務等一定方式-3-將系統拆分到不同的機房里面去，使業務鏈路盡可能在單機房內完成，其效果是既降低了鏈路耗時，又實現了多機房

7、多活且為多機房擴展提供基礎。從技術拆分的角度來看，單元可以分成可拆分和不可拆分兩類，如賬務、存款、貸款、資產交換等絕大多數銀行業務是按照人維度可以進行拆分的，如客戶、限額等存在多個維度或者非人的維度，因此不可拆分；客戶登錄可存在身份證號、銀行卡號、手機號、郵箱等多個維度。（二）單元類型目前業內對于單元的命名方式有多種，例如郵儲銀行分區單元（DUS）、民生銀行分區單元（DUS/U Zone）、網商銀行分區單元（G/R/C Zone）、微眾銀行標準化部署節點（DCN）、光大銀行分區單元（DUS）及其他企業分區單元（SET）。不同的金融機構實際的 DUS 劃分方式可能會有些不同，但基本思想大體一致，

8、本文為了方便論述，統一使用分區單元（DUS）來表述。-4-圖 2 常見 DUS 劃分示意圖如上圖 2 所示，常見的 DUS 劃分主要如下：1.全局路由單元（G-DUS）1.全局路由單元（G-DUS）包含網關服務，處理外聯系統的服務請求，提供服務路由，將外部請求轉發到內部的業務單元的應用服務實例。典型的應用服務為聯機網關服務、文件網關服務、外呼等。2.業務服務單元（B-DUS）2.業務服務單元（B-DUS）包含多個客戶的業務數據以及為此類客戶提供服務支持的應用實例，負責完成客戶的業務處理。典型的應用服務為聯機服務、批量主控服務、批量處理服務、批量轉聯機服務。-5-3.序號管理單元（S-DUS）3

9、.序號管理單元（S-DUS）為全部服務處理單元提供系統服務支持，如賬號等序列號生產服務，該單元的特點是在核心系統內以單點方式提供服務。典型的應用服務為全局序列號管理服務。4.公共服務單元（C-DUS）4.公共服務單元（C-DUS）為全部業務處理單元提供支撐的應用服務，以及與自動化運維管理平臺相對接的相關數據，包括批量調度服務、日志聚合信息、監控數據等。典型的應用服務為分布式批量調度服務。5.本地資源管理單元（L-DUS）5.本地資源管理單元（L-DUS）包括針對單個數據中心內的業務處理單元所提供的公共數據以及該數據的管理服務，包括映射數據、非客戶維度的參數（業務、技術參數）以及此類數據的管理服

10、務。典型的應用服務為參數管理服務、服務注冊管理服務、映射關系管理服務、配置信息管理服務。本課題更多關注單元化與分布式數據庫的結合，所以后續對于單元拆分方式將聚焦在業務服務單元（B-DUS）的拆分方案。（三）分布式數據庫與單元化分布式數據庫系統通常使用較小的計算機系統，每臺計算機可單獨放在一個地方，每臺計算機中都可能有 DBMS 的一份完整拷貝副本，或者部分拷貝副本，并具有自己局部的數據庫，位于不同地點的許多計算機通過網絡互相連接，共同組成一個完整-6-的、邏輯上集中、物理上分布的大型數據庫。典型通用的分布式數據庫架構如圖 3 所示，分為計算層和存儲層。計算層包含多個計算節點，存儲層包含眾多數據

11、節點。計算節點的作用不同分布式數據庫略有些差異，本文不展開論述；而作為各個分布式數據庫的共性點，數據節點負責存儲業務單元數據，數據節點將以多副本數據冗余的方式提供業務數據的高可靠，用于存儲一份數據多個副本的數據節點我們稱為節點組或數據節點組，本文的后續部分將會多次提及節點組或數據節點組。圖 3 典型分布式數據庫架構示意圖分布式數據庫在單元業務下部署有助于保障線上系統日常業務的高效能、高安全、高迭代的平穩運行，同時有助于金融機構、金融企業提升信息化綜合能力，此外還有助于提升國產數據庫領域的支撐能力。對于金融機構、金融企業完善技術平臺、逐步實現基礎軟件自主可控有重要的現實意義。單元化架構與分布式數

12、據庫技術的融合作為一個新興的技-7-術架構，也伴隨著眾多的難點與挑戰，包括但不限于鏈路延遲、高可靠與容災、單元拆分以及整體運維體系復雜度的提升，而這些也是本課題需要進一步研究和討論的。在銀行業客戶體驗和數字科技創新雙輪驅動推進下，傳統銀行基礎架構加速向微服務與單元化轉型，向支撐更加開放與靈活的業務架構演進。同時隨著國家基礎軟件自主可控浪潮的推進，分布式數據庫技術也越來越多地應用在了銀行業各類重要/核心系統中。微服務、單元化架構與分布式數據庫技術的融合成為一個重要的技術趨勢。為此，北京金融科技產業聯盟在分布式數據庫專委會內開展了單元業務下應用場景的調研，并組織編寫了分布式數據庫單元業務應用場景研

13、究報告，為各金融機構與分布式數據庫廠商提供參考。二、場景分析-8-（一）單元化場景分析1.應用需求簡述1.應用需求簡述對本課題相關參與單位反饋的調研結果進行分析研究，發現單元化架構與分布式數據庫技術融合的技術路線已作為主要 IT基礎架構在部分金融機構中進行試點或落地；同時有大量金融機構正在調研中，并且將單元化和分布式數據庫的結合作為重要的技術選型架構方向之一；整理金融機構分布式數據庫在單元化業務應用場景部署實施需求及特性需求，對于各金融機構與分布式數據庫廠商均具有參考價值。本報告分析的分布式數據庫在單元業務中的應用場景需求匯總如下表 1 所示：表 1 分布式數據庫在單元業務場景中應用技術需求匯

14、總編號需求1典型單元化架構業務拆分方式2單元與分布式數據庫分片的部署對應關系3單元調整過程中業務服務單元與分布式數據庫配合的典型實施方案，包括橫向與縱向擴容、單元拆分與合并。4進行單位化拆分后，分布式數據庫的本地高可靠、同城雙活或多活、異地災備等部署的典型方案，總結分布式數據庫多副本的高可靠性技術。5單元化架構下業務的灰度發布過程與分布式數據庫的灰度發布過程6單元化架構下分布式數據庫對外提供數據同步匯總的典型技術方案7研究整理單元化架構下分布式數據庫應用的典型運維解決方案，包含該場景下全鏈路性能檢測、備份恢復等技術方案。-9-2.單元化場景應用痛點2.單元化場景應用痛點本課題在實際調研過程中，

15、針對國內多家銀行、金融機構的應用情況總結得到在生產應用中需要采用單元化方式解決的痛點有：跨異地跨機房多活容災?？绠惖乜鐧C房多活容災。類似兩地三中心、三地五中心部署架構，通過架構單元化改造實現業務全局的異地多活。業務地域拆分與負載均衡。業務地域拆分與負載均衡。通過單元化架構、將業務按照地域進行單元拆分、實現有效的負載拆分、多地多活、業務高可靠與負載均衡。隔離故障提升系統整體穩定性。隔離故障提升系統整體穩定性。單元化本身就有一定的隔離性，這樣在單一業務或系統出現故障時不會影響其他的業務、系統或數據，最小范圍的系統風險。同時多個或者所有單元同時出現故障的可能性大大降低，另外也減少了故障的排查、恢復時

16、間。通過靈活的橫向擴展能力滿足業務發展要求。通過靈活的橫向擴展能力滿足業務發展要求。針對現有業務，原有系統的在性能、擴展性、可用性、安全性等方面的問題，通過單元化的重構改造進行改進，以實現高性能、高可用、高安全、高可擴展的目標。（二）分布式數據庫分析1.應用場景1.應用場景分布式數據庫是為單元化業務改造提供重要支撐的核心技-10-術和產品，本文針對“分布式單元化場景在銀行內部是否需要”、“分布式單元化場景在銀行內部是否有場景”、“分布式單元化場景是否是銀行關心或迫切需要改進的問題”等進行了調研。經過與多家銀行、金融機構溝通，目前銀行、金融機構采用或有意向在單元化業務中下采用分布式數據庫的比較有

17、代表性的應用場景包括：聯機交易、批量處理、前置系統和客戶服務系統這四個場景：聯機交易是系統對外直接提供的交易，該類交易具有以下特征：事務性事務性分布式強一致讀寫；實時性實時性交易有生命周期，并有超時機制等，調用方需實時等待被調方的反饋，成功或失敗皆有反饋；并發性并發性同一類甚至同一個交易可同時被多個線程調用，相互間有鎖處理機制?？蓪⑼活惢蛘咄粋€交易類型進行單元化處理，將其整個流程封裝成一個閉環單元，供多個線程調用，保證單元之間相互隔離。批量處理時該交易相關的參數、系統狀態已經鎖定，系統需要進行的操作具有統一性，使用相同的規則處理大量數據；批量交易具有串行性，并不是說批量交易中不能有并發，而

18、是有固定的步驟逐步操作，每一步都有對某些條件的依賴?？蓪⒁巹t封裝成單元化，每個規則相對獨立，同時在做批量交易時可按照一定-11-的步驟，逐個執行單元，類似面向對象或面向組件的思路。前置系統是處理銀行和銀聯之前的交換業務的系統，主要負責行內系統（如行內渠道前置、行內交換平臺、行內 ESB 系統）、CUPS（銀聯交換系統）間的報文格式轉換，同時對交易異常做處理以保證聯機交易的完整性和數據一致性。將前置系統單元化，形成統一的報文格式轉換，可保證整個聯機交易的事務完整性和數據一致性?？蛻舴障到y：將銀行內流程進行梳理和統一，并將其單元化，形成獨立的個體，將具體的業務辦理系統（自動或人工）與客戶服務系統

19、形成接口對接，便于以后的更新、升級和遷移等操作。2.架構分析2.架構分析通過調研分析，單元化業務場景中分布式數據庫的典型部署場景見圖 4。-12-圖 4 單元化業務場景中分布式數據庫的典型部署場景示意圖單元化業務的單元內數據存儲在分布式數據庫集群的 1 組存儲層節點中，不同的單元存儲在不同的存儲層節點組中，但他們都屬于同一個分布式數據庫集群，共享調度/計算層。如圖 4所示。每個單元存儲所用的 1 組存儲層節點可以是分布式數據庫的 1 個帶數據高可靠的數據分片；同時針對較大的業務單元（例如按地域劃分單元后的熱點地域），1 組存儲節點也可以是多個帶數據高可靠的數據分片。單元與單元間通過使用物理上隔

20、離的存儲層節點，實現單元間數據的隔離。（三）部署難點與要求-13-1.部署難點1.部署難點基于本次調研表的反饋信息整理，單元化業務場景中與分布式數據庫部署結合時有如下部署實施難點或需求：單元化拆分與分布式數據庫分片技術的融合。單元化拆分與分布式數據庫分片技術的融合。單位化架構需要業務方按照業務單位化進行拆分。單元化架構需與分布式數據庫的分片技術相結合，進行單位化拆分處理。單元的拆分需要做好事前預估測試與后期監測工作。目前調研反饋主要的單元拆分方式包括：地域（含分行）、客戶信息（含編號、賬號等）等。單元與分布式數據庫分片的部署對應關系也是下一步的研究整理內容。例如一個單元對應一個分片或一個單元對

21、應多個分片，也有分庫分表分集群的部署方案。單元化架構的單元調整與分布式數據庫技術的融合。單元化架構的單元調整與分布式數據庫技術的融合。隨著業務規模的擴展，初始劃分的單元無法繼續長期支撐，就需要進行單元擴容，增加新的單元。擴展單元的過程除了單元業務的擴展外，也涉及分布式數據庫的擴展。存在業務復雜度增加導致的單元內負載增加的情形。這種場景下常見的方法是進行單元縱向擴容，例如增加機器配置；同時如果主要是數據庫側負載的增加，也可能存在分布式數據庫層擴容的需求，包括橫向擴容和縱向擴容。單元化架構高可靠與容災與分布式數據庫技術的融合。單元化架構高可靠與容災與分布式數據庫技術的融合。單元化架構增加了由于單個

22、單元出現故障對整體可用性影響的概率，-14-但是由于多個單元同時不可用的概率降低，因此系統整體的可用指標大大提高。以分布式數據庫為例，數據庫每個分片的數據副本數與數據副本的部署方式，以及不同部署方式與業務重要度的對應關系。每個單元內分布式數據庫本身的數據高可靠技術是單元化高可靠的基礎，原則上，數據庫 RPO 必須為 0，RTO 時間需可控。單元化架構灰度發布過程與分布式數據庫技術的融合。單元化架構灰度發布過程與分布式數據庫技術的融合?；叶劝l布是在線業務持續運行的基本要求之一?？鐔卧獢祿絽R總與分布式數據庫技術融合?？鐔卧獢祿絽R總與分布式數據庫技術融合。對于單元化架構下，對跨單元的數據進行

23、同步匯總，以支持將部分批量或分析處理的業務需求可以在線下其他的技術架構中進行支撐。這個過程涉及從單元化下數據存儲的分布式數據庫的數據抽取、同步、驗證等技術。2.能力要求2.能力要求本次調研“單元化業務場景下是否有對分布式數據庫操作需求”，從單元內、跨單元以及數據同步匯三個維度進行了收集。其中數據匯總部分已經在“單元化場景與分布式數據庫結合的部署實施需求”章節中進行了覆蓋，而跨單元操作的需求普遍較少，所以重點關注單元內的數據庫特性需求：單元化后單元內數據存取性能與監測。單元化后單元內數據存取性能與監測。單元化改造，特別是基于微服務改造后，服務模塊間調度鏈路增加，SQL 語句交互次-15-數也增加

24、?？煽啃耘c容災?？煽啃耘c容災。參見“單元化場景與分布式數據庫結合的部署實施需求”章節中相關內容。擴展性。擴展性。參見“單元化場景與分布式數據庫結合的部署實施需求”章節中相關內容。易用易維護。易用易維護。單元化架構改造后，從運維角度，由于機器與節點數的增加，整體運維復雜度也大幅增強。如何確保多個單元之間的運維一致性對運維能力提出更高的要求。-16-三、應用方案以下方案描述中使用的術語及定義參考表 2。表 2術語定義關鍵術語關鍵術語定義解釋定義解釋單元指一個能完成特定業務操作的自閉環集合，在這個集合中包含了特定業務所需的關鍵服務，以及分配給這個單元的數據。業務服務單元（B-DUS）包含多個客戶的業

25、務數據以及為此類客戶提供服務支持的應用實例，負責完成客戶的業務處理。節點組（或數據節點組）用于存儲一份數據多個副本的數據節點我們稱為節點組。小單元一個單元部署在分布式數據庫的一個數據節點組上。大單元一個單元部署在一整套分布式數據庫集群上。CMDB配置管理數據庫。（一）單元業務拆分1.拆分策略1.拆分策略業務服務單元的拆分策略主要分為兩大類：垂直拆分與水平拆分。1)垂直拆分。垂直拆分。垂直拆分指業務單元按照產品領域維度進行切分，形成不同的產品單元。以核心系統為例，一個可能的垂直拆分方式為個人存款、個人貸款、對公存款、對公貸款、現金以及內部賬。2)水平拆分。水平拆分。水平拆分指業務單元按照地區、客

26、戶號（或-17-賬戶號）進行切分，每個單元只包含一個產品/業務的部分數據。常見的拆分策略包括：按照地區，例如按照分行進行拆分，通常拆分的單元比較大；按照客戶號進行切分，包括 range 切分和hash 切分。Range 切分就是每個單元固定一個客戶號范圍；Hash切分就是將業務數據基于用戶號進行 hash 散列，一個單元存儲hash 結果的一個或多個分片；按照地區與客戶號切分的混合切分，例如先按照地區分，然后在地區內再按照客戶號切分；除了上述常見的水平拆分方式外，還有一種基于時間的 range 拆分方法在相關機構的實際業務系統中落地的實踐，即：按照時間進行切分，例如按訂單生成的時間，每個月做一

27、次且切分。2.典型方案2.典型方案基于上一節“業務服務單元拆分策略”的內容，這里集中介紹如下 6 類典型垂直拆分產品后的業務單元拆分方案：1）水平按照客戶號的 range 做拆分1）水平按照客戶號的 range 做拆分?？蛇x的將不同的產品線拆分到不同的單元，每個單元會包含 1 個產品或多個產品的一個固定 range 范圍的客戶號，這是小單元設計，如果未進行產品線拆分，則每個單元包含所有的產品；單元客戶容量上限固定，容量超出時新客戶號進新的單元；一個客戶號原則上固定屬于某一個單元，不會出現客戶號在單元間的挪動。圖 5 是一個每單元200 個客戶號的拆分示例。-18-圖 5 客戶號 range 拆

28、分示例圖2）水平按照客戶號的 hash 拆分，2）水平按照客戶號的 hash 拆分，每個單元包含多個 shard分片?？蛇x的將不同的產品拆分到不同的單元，客戶數據按照客戶號進行散列，存儲到一個給定數量的單元集合中，每個單元存儲多個 hash 散列后的 shard 分片，是小單元設計，如果未進行產品線拆分，則每個單元包含所有的產品；單元客戶容量過多時將新增單元并挪動已有單元的 shard 分片到新的單元，所以shard 是擴容的最小粒度，shard 的數量一定程度上決定了架構的擴容上限，擴容時將出現客戶號在單元間的挪動，如圖 6 所示。-19-圖 6 客戶號 hash 拆分示例圖3）先水平拆分區

29、域，再按照客戶號的 hash 拆分，每個單元包含多個 shard 分片。3）先水平拆分區域，再按照客戶號的 hash 拆分，每個單元包含多個 shard 分片?？蛇x的將不同的產品拆分到不同的單元，數據先按照地域進行拆分，然后對于一個地域的數據再通過客戶號 hash 散列存儲到一個給定數量的單元集合中，每個單元存儲多個 hash 散列后的 shard 分片，是小單元設計，如果未進行產品線拆分，則每個單元包含所有的產品。單元的管理與方案 2“先垂直拆產品、然后水平按照客戶號的 hash 拆分，每個單元包含多個 shard 分片”相同，如圖 7 所示。圖 7 水平拆分區域后客戶號 hash 拆分示例

30、圖-20-4）先垂直拆產品然后水平拆分區域。4）先垂直拆產品然后水平拆分區域。不同的產品線使用不同的單元，產品線的數據先按照地域進行拆分；由于一個區域的數據通常會較大，所以是大單元設計；同時單元與單元的容量可能存在較大差異，單元的擴容也更多基于單元內的擴容手段，新增單元操作較重，如圖 8 所示。圖 8 垂直拆產品后水平拆分區域示例圖5）直接按區域拆分，大單元設計。5）直接按區域拆分，大單元設計。類似方案 4 先垂直拆產品然后水平拆分區域，不同的是多個產品會對單元進行共用，同樣是大單元設計，若圖 9 所示。-21-圖 9 水平拆分區域示例圖6）按時間進行切分，循環使用現有單元。6）按時間進行切分

31、，循環使用現有單元。針對類似于訂單等特定業務模塊，數據按時間進行切分，粒度通常到月或季度；訂單類數據是一個持續增長值，有明顯的時效性，因此基于時間進行拆分后，所有單元都會呈現一個有規律的替換的情況，例如需要定期新建未來單元，并定期歸檔歷史單元數據，這要求系統有極好的單元調度能力，如圖 10 所示。圖 10 時間進行拆分示例圖-22-對于不含拆分字段的數據，無法按客戶維度進行切分，如定價、機構信息等，這些數據可以考慮的存儲方案主要有 2 種：以副本形式保留在每個業務單元中以提高訪問性能。通常要求這類數據變更頻率低且數據量不大。另一種是單獨部署一個單元，稱為全局數據單元。3.方案對比3.方案對比針

32、對上文提到的 6 個典型業務單元拆分方案，本小節將從擴展性、故障可用性、降低跨單元操作比重、降低運維復雜度、降低建設成本等幾個維度進行對比，如表 3 所示。對于擴展性，小單元設計更便于架構未來新單元的擴展。方案 1、6 的擴展性最好，理論無上限，新單元擴容方式也輕量；方案2和3存在理論擴容上限，擴容過程也涉及用戶數據的挪動；方案 4 和 5 擴容代價大，通常只是有限數量的單元。對于故障可用性，方案 1 基于客戶號 range 的切分方案隔離性是最好的，可用性影響最小，一個客戶號原則上固定屬于某一個單元，不會出現客戶號在單元間的挪動，某個單元故障也不會影響其他單元。方案 2 和方案 3 基于客戶

33、號 hash 進行切分，存在單元挪動的可能，同時單元規模相比方案 1 也通常會更大一些，但從故障隔離的角度，方案 2/3 與方案 1 的效果基本相當。方案 4 和 5 是大單元設計，單元故障的隔離性意義不大，方案 4-23-存在產品拆分，相對更好。方案 6 雖然以時間段劃分，隔離性好，但如果業務中是否存在歷史數據聚合等業務場景，就需要引入其他方案用來保障匯集場景。對于降低跨單元操作比重，大單元設計優勢更大。方案 4、5、6 的擴單元操作，特別是跨單元分布式事務操作，比例小于方案 1、方案 2 和方案 3，同時方案 5 產品更像集中式部署架構，所以擴單元操作更少。對于降低運維復雜度，顯然架構集中

34、度越高，拆分的單元越少，運維復雜度也越低；所以方案 5 和方案 4 復雜度相比方案 1、方案 2、方案 3 和方案 6 要低。對于方案 2、方案 3，擴容過程是否挪動數據對運維的復雜度會有明顯影響；如果方案 2/3/的單元擴增過程主要是通過調整數據 shard 的主副本的分布實現，擴容過程不涉及數據挪動，同時因為擴容過程不涉及新的 shard產生，對于生產的監控、備份、數據同步鏈路影響都很小，那么運維復雜度較低。后續對比中，我們將使用“方案 2/3（擴容不挪數據）”來表示上述情況。所以方案 1/6 的運維復雜度與“方案 2/3（擴容不挪數據）”相當，且優于“方案 2/3（擴容挪數據）”。同時對

35、于方案 1 與方案 2/3/6 的運維復雜度對比，目前業內還有如下有代表性的觀點，供大家參考：網商銀行認為方案 1 盡管不需要數據搬遷，但由于是新增單元中包含了新增數據庫，則需要新增數據庫實例、數據庫監控、-24-同城備份、超遠備份，以及數據庫下游日志解析鏈路的同步等，甚至整個離線數倉等大數據體系跟隨變動。顯然方案 1 的復雜度遠大于方案 2、3、6。若使用了支持一致性協議的原生分布式數據庫，則數據搬遷的復雜度可忽略。舉個例子，貸款擴容出新的單元，用戶編號范圍 200 萬300 萬，則貸款的所有數據倉庫的基表都需要增加新的同步任務，因為貸款的數倉基表是貸款的全量數據。微眾銀行認為方案 1 在新

36、增單元的過程中，確實需要進行新增數據庫、新增上下游同步等操作，但是在方案 1 中，由于每個單元的配置完全對等，所以針對單元的擴容操作，是可以實現模板化和全自動化的，所以帶來的運維復雜度是可控的。另外方案1 在運維安全性上還有三個優勢：新增單元的過程中，對存量單元的用戶以及服務完全不涉及，不會產生因為存量數據挪動而帶來的可用性的風險；對于新增單元的用戶主量是可灰度的?？梢酝ㄟ^權重精確控制，先放量極小數量的用戶到新增單元，驗證正常之后，再逐步放量更多的用戶到新增單元?？梢暂^方便的設置一個專用的預發布單元。這個單元可以放置固定的用戶（比如單位內部員工用戶），專門用于版本的預發布和版本驗證。有效降低版

37、本更新帶來的可用性風險。對于建設成本，單元化拆分的越少，成本越低，單元化的拆-25-分通常會帶來整體部署規模的增加。建設成本主要包括了方案搭建所需的服務器數量，以及方案運行所需的技術難度。以小單元的方案 1、方案 2、方案 3 為例，涉及更多的跨單元操作就需要更多依賴單元間分布式組件，例如分布式事務組件、分布式全局路由組件等，整體建設難度會高于方案 4 和 5。而從方案所需服務器的數量來說，由于方案 5 的集中化程度最高，服務器數量也相對更??；方案 1 的單元化拆分的力度更小，所需的服務器數量也相對更多。方案 6 僅適用于特定場景，所以需要單獨評估，但通常會高于常規方案。表 3 五種方案對比圖

38、方案方案擴展性擴展性故障可用性故障可用性降低跨單元操作比重降低跨單元操作比重降低運維復雜度降低運維復雜度降低建設成本降低建設成本方案 1優優差中差方案 2/3（擴容挪數據）良優差差中方案 2/3（擴容不挪數據）優優差中中方案 4差中良良良方案 5差差優優優方案 6優中優中差-26-表 4 網商銀行針對上述對比表格內容的不同觀點補充方案擴展性故障可用性降低跨單元操作比重降低運維復雜度降低建設成本方案 1優優差差差方案 2優優差差中方案 3良良差差中方案 4差中良良良方案 5差差優優優方案 6優中優中差表 5 表格為微眾銀行針對上述對比表格內容的不同觀點補充方案擴展性故障可用性降低跨單元操作比重降

39、低運維復雜度降低建設成本方案 1優優差中差方案 2優優差差中方案 3良良差差中方案 4差中良良良方案 5差差優優優方案 6優中優中差考慮到前 5 種方案更加常見，后續本文的討論將主要集中在前 5 種方案相關的部署實施方案。（二）業務拆分數據庫設計本小節將討論前文 5 類單元拆分方案應用時對應的分布式-27-數據庫設計。1.水平按 Range 拆分第一類是水平按照客戶號的 range 做拆分。1.水平按 Range 拆分第一類是水平按照客戶號的 range 做拆分。方案 1 中 1 個業務單元數據將存儲到分布式數據庫的一個節點組中；不同的業務單元使用不同的節點組；多個業務單元共享一個分布式數據庫

40、集群。以銀行賬戶核心的存貸款服務的個人存款為例，假設目前該業務有 5000 萬的客戶號，我們以每 500 萬個用戶為一個單元，所以需要 10 個單元；我們搭建一個含 10 個數據節點組的分布式數據庫集群，每個數據節點組支撐 1 個單元；即第 1 到 500 萬的客戶號存放在第一個數據節點組，第 500 萬+1 到 1000 萬的客戶號存放在第二個數據節點組，以此類推。當該業務增長客戶號增加時，分布式數據庫集群新增擴容一個數據節點用于存儲新增的客戶號。2.水平按 Hash 拆分2.水平按 Hash 拆分第二類是水平按照客戶號的 hash 拆分，每個單元包含多個shard 分片。水平按照客戶號的

41、hash 拆分，每個單元包含多個shard 分片。方案 2 中 1 個業務單元數據將存儲到分布式數據庫的一個節點組中；與方案 1 不同點在于，方案 2 的業務數據按照hash 拆分，拆分成眾多的 shard 分片，而 1 個節點組將存儲多個 shard 分片。多個業務單元共享一個分布式數據庫集群。-28-以銀行賬戶核心的存貸款服務的個人存款為例，假設目前該業務有 5000 萬的客戶號，我們預期 1 個單元存儲能存儲 5001000 萬左右的用戶，所以初步規劃 10 個單元，為業務增長預留一倍的空間；我們搭建一個含 10 個數據節點組的分布式數據庫集群，而后將 5000 萬的客戶號通過 hash

42、 算法散列到 10 個數據節點組中，每個數據節點組存儲大約 500 萬的客戶號；當該業務增長客戶號增加，每個單元存儲的客戶號接近 800 萬左右時，分布式數據庫集群新增擴容一批的數據節點組（例如擴容一倍），而后在業務低峰時將部分客戶數據重分布到新增數據節點組。每個數據節點組擴容后存儲的數據量基本相當。部署示意圖類似圖11。圖 11 業務單元存儲于數據節點組的部署架構示意圖-29-3.水平拆分再按 Hash 拆分第三類是先水平拆分區域，再按照客戶號的 hash 拆分，每個單元包含多個 shard 分片。3.水平拆分再按 Hash 拆分第三類是先水平拆分區域，再按照客戶號的 hash 拆分，每個單

43、元包含多個 shard 分片。從部署角度，方案 3 與方案 2 等同。1 個單元存儲于一個節點組中，一個單元存儲多個 shard 分片。多個業務單元共享一個分布式數據庫集群。以銀行賬戶核心的存貸款服務的個人存款為例，假設目前該業務有 5000 萬的客戶號，先按區域進行拆分，例如華北地區 1000萬用戶，而后進行 hash 拆分。整體方案與方案 2 部署類似，主要區別是不同區域所使用的數據節點組是不相交的。4.垂直拆分后水平拆分區域第四類是先垂直拆產品、然后水平拆分區域。4.垂直拆分后水平拆分區域第四類是先垂直拆產品、然后水平拆分區域。如圖 12 所示，每個區域單元包含一個產品一個區域的所有數據

44、，對應到一個單獨的分布式數據庫集群，在集群內可以基于客戶號做 hash。即一個單元對應一個分布式數據庫集群。以銀行賬戶核心為例，先按照區域進行劃分，例如華北區，然后按業務拆分為存款服務單元、貸款服務單元、現金憑證服務單元和公共賬務服務單元等。每個單元部署到一個獨立的分布式數據庫集群中。-30-圖 12 業務單元獨占分布式數據庫集群示意圖5.按區域拆分第五類是按區域拆分，大單元設計。5.按區域拆分第五類是按區域拆分，大單元設計。類似方案 4，每個區域的所有相關產品的所有數據放入一個單元，對應到一個單獨的分布式數據庫集群，在集群內可以基于客戶號做 hash。一個單元對應一個分布式數據庫集群。以銀行

45、賬戶核心為例，按區域進行劃分，例如華北區，這個區內是一個完整的賬戶核心業務，包含存款服務、貸款服務、現金憑證和對公賬戶服務等，這個區域作為一個大單元部署到一個獨立的分布式數據庫集群中。最后針對全局單元，如果數據量不大，可以考慮數據到分布式數據庫集群的一個數據節點組；如果數據量較大，可以考慮部-31-署到一個獨立的分布式數據庫集群中。（三）數據庫部署1.單元擴容部署方案1.單元擴容部署方案單元內的擴容包括了應用擴容和數據庫擴容。對于應用節點擴容，單元化架構下，應用服務應該采用無狀態設計，這樣可以通過應用鏡像，快速增加新的應用容器或虛擬節點。對于單元內數據庫擴容則分為 2 種情況：小單元場景和大單

46、元場景。小單元場景，一個單元部署在分布式數據庫的一個數據節點組上，單元內的擴容主要通過數據節點垂直擴展實現，即通過數據庫節點在線滾動升級的方式逐步將一個數據節點組相關的多個數據庫的物理資源進行升配，例如提高 CPU、內存、網絡、磁盤 IO 等。示例如圖 13 所示：圖 13 小單元場景單元內擴容示意圖大單元場景，一個單元部署在一整套分布式數據庫集群上，-32-所以單元內的擴容主要依賴分布式數據庫集群的橫向擴容實現，通過使用更多的機器，實現分布式數據庫在容量與性能吞吐上的提升。分布式數據庫能夠檢測到新的服務器，并將其他服務器上的數據遷移到擴容服務器，盡可能的均衡各個節點的負載，實現整體的平衡，當

47、然這個過程勢必需要進行數據遷移，集群會基于負載均衡原則將部分數據遷移到擴容服務器上，這個數據遷移的過程對業務是透明的。示例如圖 14 所示：圖 14 大單元場景下單元內分布式數據庫擴容示意圖全局單元的數據庫擴容主要依賴上述單元內擴容策略，即提升單元硬件升配或依托分布式數據庫自身的擴容技術實現，無法依賴新增單元的方式進行擴容。當單元的存儲達到瓶頸，無法通過升級物理節點進行提升已經達到分布式數據庫集群有效擴容邊界時，就需要進行新增單元擴容，示意如圖 15 所示：-33-圖 15新增擴容單元示意圖新增單元的擴容方式與業務服務單元的拆分策略緊密相關，本小節將分別討論 5 種業務單元拆分策略對應的新增單

48、元擴容方法。1）先垂直拆產品然后水平按照客戶號的 range 做拆分。對于方案 1 而言，單元客戶容量上限固定，容量超出時新客戶號進新的單元；一個客戶號原則上固定屬于某一個單元，不會出現客戶號在單元間的挪動，所以擴容的基本過程為：當現有的單元快滿時，在分布式數據庫集群上新增一組數據節點組。當單元客戶數達到固定上限，新增的客戶號將被路由分配到新的業務服務單元。2）先垂直拆產品然后水平按照客戶號的 hash 拆分，每個單元包含多個 shard 分片。對于方案 2 而言，每個單元存儲的是多個 hash 散列后的 shard 分片。單元客戶容量過多時將新增單元并挪動已有單元的 shard 分片到新的單

49、元；shard 是擴容的最小-34-粒度，shard 的數量一定程度上決定了架構的擴容上限，擴容時將出現客戶號在單元間的挪動。所以擴容的基本過程為：當現有的單元快滿時，在分布式數據庫集群上新增一批數據節點構建多個數據節點組。例如一次性擴容 1 半的數據節點或擴容 1 倍的數據節點。擴容節點數越多，本次擴容所需挪動的數據總量就越大。計算現有單元內需要挪動的 shard 分片，挪動 shard 分片到新增數據節點組，形成一批擴容任務計劃。逐步執行擴容任務計劃，將業務數據 shard 分片均勻挪動到新增的數據節點組，實現全局數據分布的均衡。這個業務數據挪動的實現可能會涉及相關shard 分片的鎖定，

50、或基于數據庫增量變更日志（例如 binlog）來應用數據挪動過程產生的數據變更以確保數據挪動過程的在線。業務數據挪動到新單元后，調整路由映射。為了實現便捷路由管理，一個可行的實現方式為“hash 函數+路由表”的實現，即通過 hash 將業務數據固定散列為一定數量的 shard 分片，而后通過額外的一個路由映射表來實現一個 shard 分片與后端業務服務單元之間的映射關系。數據挪動完成后，只需調整路由映射表中對應 shard 分片的映射關系即可。3）先垂直拆產品然后水平拆分區域，再按照客戶號的 hash拆分，每個單元包含多個 shard 分片。方案 3 的擴容過程同方案2。4）先垂直拆產品然后

51、水平拆分區域。對于方案 4 而言，新-35-增單元需要搭建一個新的分布式數據庫集群，所以每次擴容都會涉及大批量數據的重分布。擴容過程整體實施代價較大，與相關分布式數據庫的實現也有較大的關聯，一個可能的方案是依托數據同步工具，進行單元業務數據全量和增量的搬遷。5）直接按區域拆分，大單元設計。方案 5 的擴容過程同方案 4。2.高可靠部署方案2.高可靠部署方案1）本地化高可靠部署方案如圖 16 所示，當某個計算節點發生故障，流量直接切換到存活的計算節點，切換過程應用無感，后續通過計算節點自愈恢復后集群自動發現并重新將該計算節點加入集群。圖 16 單元化架構下分布式數據庫高可靠部署架構圖單元化架構下

52、分布式數據庫數據副本高可靠主要依托分布-36-式數據庫本身的數據庫高可靠技術實現。目前主流的高可靠技術主要的實現是依托多數派一致性共識算法，例如 paxos 或 raft算法。數據節點組（即存儲節點）采取多副本方式構成高可用集群，一個節點負責寫入，其他節點通過多數派一致性算法保證數據一致性，因為部署在同一機房，集群同步打開強一致性開關。當主庫發生故障，系統會自動發現并嘗試恢復主庫，如果主庫無法恢復則發起主從切換，保證數據庫高可用。2）同城雙活部署方案同城雙活是雙活技術與同城災備中心模式結合的一種主流容災架構。業務系統可以同時通過生產中心和災備中心進行訪問，無需指定特定的訪問規則。數據庫架構同時

53、兼備異地互備模式的負載均衡和故障自動切換能力，且由于處于同城較近距離，兩個數據中心的存儲節點可以保持數據強一致。當其中一個中心發生災難時，通過接入前端的負載均衡調整，可將全流量輸入對等的災備中心；數據庫同時自動進行切換，災備中心的數據庫集群承載全部查詢請求。同城雙活的部署示意圖 17 如下：-37-圖 17 同城雙活部署示意圖基于數據分布式架構可以對應用層提供透明的雙活能力。以一個四分片的數據表為例，如圖 18 所示，分片數據可以均勻分布在兩個中心的數據庫數據節點中。圖 18 四分片數據在兩個數據庫中心分布式示意圖-38-3）兩地三中心部署方案在同城雙活或者同城互備的架構下，再增加一個遠距離的

54、容災中心，可實現兩地三中心的容災架構。如圖 19 所示，該架構在同城容災方案的基礎上，獲得了對地震、颶風等區域級災難的抵御能力。由于異地災備中心距離較遠，所以數據同步一般考慮使用異步模式，可基于數據庫異步同步功能實現，或者在應用層使用消息隊列等組件進行業務數據異步同步，進而實現遠距離異地機房的數據最終一致性。圖 19 兩地三中心單元化架構示意圖3.灰度發布部署方案3.灰度發布部署方案1）業務單元灰度發布部署方案-39-業務服務單元的業務灰度發布部署方案與單元拆分策略緊密相關，本小節將分別討論 5 種業務單元拆分策略對應的業務灰度發布方案。先垂直拆產品、然后水平按照客戶號的 range 做拆分。

55、對于方案 1 而言，一個單元存儲一個特定范圍客戶號，所以一個簡單的灰度發布方案就是構建一個灰度單元，一些受控用于灰度驗證的客戶號存儲于該單元，例如將銀行職員的客戶號存儲到灰度單元中。每次新版本應用發布時將先在該灰度單元進行發布，驗證沒有問題后再發布到其他業務服務單元。由于方案 1 是小單元設計并且具有優異的故障可用性，灰度單元故障不會影響其他業務服務單元的運行。同時用于灰度驗證的都是受控的客戶號，整個灰度發布過程更加的可控。先垂直拆產品、然后水平按照客戶號的 hash 拆分，每個單元包含多個 shard 分片。不同于方案 1,方案 2 采用 hash 進行客戶號拆分，這樣就難以確保一組用于灰度

56、驗證的客戶號可以固定被散列到一個灰度服務單元中。對任意一個單元進行灰度發布驗證，由于方案 2 較好的故障可用性以及方案 2 的小單元設計，灰度單元故障不會影響其他業務服務單元的運行。但由于無法確?；叶劝l布影響的用戶是受控用戶，所以灰度發布過程對客戶的影響通常也更大。一個可以考慮的折中方案為在 hash 拆分的基礎上，對客戶號做一個白名單，所有受控用戶都放入白名單，并在-40-進行 hash 前先被路由到一個灰度單元中，用于后續恢復發布驗證。先垂直拆產品、然后水平拆分區域，再按照客戶號的 hash拆分，每個單元包含多個 shard 分片。方案 3 的業務灰度發布方案同方案 2。先垂直拆產品、然后

57、水平拆分區域。對于方案 4 而言，由于是大單元設計，灰度發布過程的業務模塊風險較高，恢復發布所影響的客戶范圍也難以控制。方案 4 如果采用方案 2 的灰度單元策略，主要的風險點在于灰度單元的數據規模遠小于正常業務服務單元，量變可能引起質變，在該灰度單元的驗證結果存在與大單元上行為不一致的風險。直接按區域拆分，大單元設計。相比方案 4，方案 5 由于是多個產品使用同一個單元，業務的灰度發布過程的復雜度也明顯增加。2）分布式數據庫集群灰度發布部署方案分布式數據庫集群的灰度發布將主要由分布式數據庫集群自身技術實現，需要確保分布式數據庫集群的所有組件升級版本的向下兼容性，并且做到可升可降。對于計算節點

58、，由于數據庫集群需要支持計算節點的動態增減，通過剔除老版本計算節點并加入新版本計算節點的方式，實現計算節點的滾動輪替升級。需要考量的風險點就是不同版本的-41-計算節點在同一個數據庫集群內部運行過程的穩定性，所以計算節點新版本必須向下兼容。對于存儲層的數據節點，通過數據節點組的在線滾動升級，來實現數據節點的新版本升級?；具^程就是先新增一個新版本的數據節點，該數據節點基于節點組主數據節點的副本進行構建，而后剔除一個老版本數據節點，然后重復前面的步驟，直到所有的備數據節點完成新版本升級，最后進行主備切換并對原主節點進行升級。3）灰度發布部署過程的管理灰度發布過程應該循序漸進，控制發布風險影響的范

59、圍，參考新一代銀行 IT 架構，可參考的管理方案如下：首先針對一個子系統的一個實例進行灰度發布，控制影響范圍為一臺主機，如果出現問題，可以通過停止該主機觸發高可靠 failover機制來快速解決故障。其次針對灰度單元進行灰度發布，將一整個灰度業務服務單元進行發布。發布過程密切關注業務層面與數據庫層監控指標是否正常；如果出現異常，進行快速回滾；如果正常需觀察一段時間驗證發布效果。最后針對普通業務服務單元進行發布。發布過程考慮分批次發布方式，每一批次的發布也是一次灰度發布，都需要預留足夠的觀察時間。對于低風險變更，灰度發布的批次間隔可以考慮為大于 1 小時；對于中高風險的變更，灰度發布的批次間隔可

60、以考慮為大于 12 小時。-42-4.數據匯總聚合部署方案4.數據匯總聚合部署方案1）數據聚合需求單元化架構需要考慮單元內所有的業務需求在單元內部實現，即單元的業務功能要實現自包含，然而還是有些場景需要對所有單元進行匯總和分析的，其中邏輯較重的需求放到 Hadoop為主的大數據平臺完成，另外把簡單或者有一定時效要求的分析需求放到數據聚合庫，圖 20 為單元化數據聚合典型的邏輯架構。圖 20 單元化數據聚合典型的邏輯架構示意圖在部署時，單元化業務數據庫采用典型的兩地三中心的高可用架構，而數據聚合庫由于數據可再生，且不涉及客戶業務，因此部署時基本采用單數據中心的模式，以節省資源。同時為了保證在極端

61、情況下數據中心故障不影響相關的功能，所有使用數據-43-聚合的應用均需要有降級方案，降級方案可以選擇降級到業務系統的備庫或者大數據平臺。圖 21 所示為數據聚合庫的部署架構。圖 21 單元化架構數據聚合部署架構示意圖2）數據聚合技術方案數據聚合采用生產者和消費者的模式，生產者負責進行數據庫增量變更日志解析（例如 binlog），以消息的方式進行傳遞，由下游的消費者進行相應的消息讀取并寫入到下游目標端數據庫。針對不同的業務單元與分布式數據庫部署對應方案，數據聚合的技術方案也有差異：針對小單元部署架構，即一個單元為分布式數據庫的一個數據節點組，單元的增量變更主要是獲取該數據節點組某一副本（例如主副

62、本）的增量變更日志（例如 mysql-44-內核數據庫單數據節點的本地 binlog）。因為單元與單元之間的獨立性，不同單元的增量變更日志抽取也相對獨立，實現較為簡單。針對大單元部署架構，即一個單元對應一個獨立的分布式數據庫集群，單元的增量變更需要獲取整個集群的增量變更日志?？蛇x的實現包括：分布式數據庫集群原生提供 CDC 模塊，例如一個全局 binlog server。由 CDC 模塊負責處理分布式數據庫集群數據節點的增量變更日志信息的匯總、排序、歸并、去重等，最終統一對外輸出一份完整統一的全局增量變更日志。通過外部第 3 方工具抽取分布式數據庫集群后端數據節點的增量變更信息，而后按照一定的

63、規則進行排序、歸并、去重，需要考慮處理的場景包括了全局分布表的去重、DDL 語句的合并與同步、分布式事務信息的合并、分布式事務的排序等等。當然如果目標端消費集群只要求數據最終一致性的話，可以不考慮分布式事務信息的合并與排序。如圖 22 所示為分布式數據庫集群后端數據節點增量變更抽取同步架構示意圖。-45-圖 22 分布式數據庫集群后端數據節點增量變更抽取同步架構示意圖3）數據聚合挑戰聚合庫的容量和性能問題。聚合庫的容量和性能問題。容量壓力主要來自源端通過單元化可以無限增加，而聚合庫是否也能達到同樣的擴展能力，這就需要一種可擴展的數據庫，能夠支持足夠大的容量。除了容量以外，大數據量查詢的性能也往

64、往是一個很大的問題，之所以要進行單元化，往往是因為單個數據庫無法支持太大的數據量。這里面有可能需要應用配合進行一定的改造才能達到最優的效果。數據聚合的時效問題。數據聚合的時效問題。由于數據量和中間過程涉及多個組件的配合，數據同步時效往往無法做到實時，甚至有時候準實時也是奢望，比如在業務高峰或執行批量時，同步出現異常的時候。因此限于時效的考慮，適合訪問聚合數據的業務場景可能會減小一些。數據聚合的數據核對。數據聚合的數據核對。動態的數據核對其實是一個非常復雜-46-的問題，尤其是在大數據量的情況下，動態核對大表甚至可以說是災難。目前比較可行的數據核對方案主要有全量數據核對、數據切片核對、帶時間戳的

65、數據核對等。數據聚合應急問題。數據聚合應急問題。當數據聚合出現異?；蛘咄綍r效無法達到目標時效時，應用如何應急是一個需要解決的問題，建議訪問聚合數據的應用要有適當的降級方案。5.應用備份恢復部署方案5.應用備份恢復部署方案針對不同的單元與分布式數據庫部署對應關系，所需采用的備份恢復方案也不相同。1）對于小單元部署，即一個單元部署在一個數據節點組，單元數據的備份只需針對該數據節點組進行備份。以 MySQL 內核數據節點分布式數據庫為例，可以使用 xtrabackup 物理備份工具對數據節點組的主庫或備庫進行全量與增量的備份，同時對數據節點組的增量變更日志也同步進行備份（例如 binlog 備份）

66、。除物理備份外，邏輯的關鍵數據正文備份也是常用的備份策略。由于單元與單元數據的隔離性，不同單元的數據備份可以完全獨立，備份文件的管理也可以獨立分別進行。每個單元的數據還原只依賴每個單元自己的備份文件，所以并沒有全局一致性的備份需求。對于不含拆分字段的數據以副本形式保留在每個業務單元中的場景，在還原后需要考慮更新為最新數據。還原主要應用的場景包括：災備場景，用于恢復單元數據。容忍一部分的數-47-據丟失，丟失數據量大小取決于增量變更日志的備份周期。單元數據節點組擴容或節點替換場景，基于備份恢復迅速初始化一個新的數據節點。歷史數據的獲取，通過基于時間點還原，讀取歷史版本數據。其他，例如構建測試環境

67、。2）對于大單元部署，即一個單元部署在一個分布式數據庫集群，單元數據的備份恢復依賴分布式數據庫的備份恢復實現。不同于小單元場景，分布式數據庫集群需要提供全局一致性的備份恢復功能，即備份還原的數據不存在部分提交的分布式事務信息、并且還原的集群相當于當前集群的一個歷史快照，可以基于集群的全局增量變更日志進行增量變更的同步。備份任務的執行將依托 CMDB 庫并且由自動化運維管理平臺進行集中式的調度管理。同時建議備份任務走備份私網，避開業務網絡，避免備份對業務流量的影響。（四）數據庫運維要求1.基本運維需求1.基本運維需求隨著單元化架構與分布式數據庫技術的引入，銀行 IT 系統的運維工作量是傳統架構的

68、幾倍甚至幾十倍的提升。本章節將更多側重分布式數據庫在單元化架構下的運維解決方案，并且本章內容參考了新一代銀行 IT 架構。單元化架構下對分布式數據庫應用運維主要的需求包括但不限于：高效合理的資源分配。高效合理的資源分配。由于單元化架構下，特別是小單元設-48-計方案，單元的升配、新增與集群節點的擴容是常見操作。如何高效統籌全局、縮短資源環境準備周期、提高資源控制精細度以減少浪費是主要的運維挑戰之一。高可控的灰度發布管理。高可控的灰度發布管理。根據業界經驗，在一般系統故障中，有超過 70%是由發布變更引起的，而該風險在單元化架構下進一步提升。如何降低灰度發布的危險影響范圍、將改動的風險份數與縮小

69、，以保障系統整體的可靠性是主要的運維挑戰之一。高效自動化的運維管理。高效自動化的運維管理。依托分布式架構，從效率、安全、連接等多個維度構建分布式高效執行與分發、自動化調度與執行結果合并、以及便捷系統聯動的自動化運維管理平臺是單元化架構下分布式數據庫應用運維的核心工作，也是主要挑戰之一。高覆蓋全鏈路的監控告警。高覆蓋全鏈路的監控告警。在單元化與分布式數據庫結合的技術架構下，業務全鏈路所涉及的節點與組件顯著增加，全方位的鏈路監控告警體系的建設是安全生產和鏈路性能分析的基礎，也是主要挑戰之一。2.運維關鍵技術2.運維關鍵技術為了應對上文論述的運維挑戰，單元化架構下分布式數據庫應用的典型運維解決方案需

70、要重點考慮如下運維關鍵技術的建設：1）CMDB 配置管理數據庫1）CMDB 配置管理數據庫CMDB 是所有運維工具的基礎，存儲并集中管理全局物理層、-49-邏輯層和應用層的配置項及關系信息。同時通過豐富的對外 API接口，與其他關鍵技術組件進行融合，支撐運維管理工具以及流程運作中對于配置信息的使用。CMDB 具備如下特性：配置模型的動態擴展能力。配置模型的動態擴展能力。配置項、屬性及關系、屬性數據類型、唯一性，組合關鍵字等均可動態定義與使用。配置查詢靈活多樣。配置查詢靈活多樣。支持自動以多配置的在線關聯查詢。細粒度的權限管理細粒度的權限管理，同時支持權限的在線配置調整。開放友好的 API 服務

71、開放友好的 API 服務，可以方便地進行調度與集成。版本管理。版本管理。支持多維度數據變遷歷史的查詢、支持配置數據版本基線比對、支持版本回退。閉環管理。閉環管理。系統設計的部署架構需要存儲進 CMDB、業務的部署過程的發起需要基于 CMDB 中的部署架構信息、資源的分配需要基于 CMDB 全局資源信息進行、資源的準備情況與部署信息也需要存儲進 CMDB、資源的監控需要基于 CMDB 的部署信息、最后系統下線資源回收需要基于 CMDB 并將最終結果記錄到 CMDB。2）智能資源分配管理系統。2）智能資源分配管理系統。智能資源分配管理系統基于CMDB 數據庫中的資源信息，根據預設規則對全行主機資源

72、進行管理和分配，目標是大幅提高生產與測試環境搭建效率、縮短資源分配與準備周期、嚴格落實高可用規則、同時提高資源利用率。首先單元化架構下分布式數據庫應用的資源分配必須嚴格遵守高可用部署規則，對于一個數據節點組而言，同城至少要有-50-2 份副本，異地至少有一份副本。對于重要子系統，數據節點組在主機房至少部署 2 份副本。一個應用子系統的多個實例，分布在 2 個或 2 個以上不同的物理機上。在單個數據中心，一個數據節點組分布式在 2 個或 2 個以上不同的機柜上，不同的應用域不共享物理機。同時基于 CMDB 滿足應用本身希望滿足的特殊規則，例如子系統互斥。其次支持豐富的 IAAS 資源供給，可以按

73、需提供物理機、虛擬機和容器的資源分配?；?CMDB 的全局資源使用狀態信息和應用的部署需求，高效地從全局資源中挑選滿足規則的合適的資源進行交付。再次具備資源的創建能力，即當資源不足時，可以通過外部的資源創建平臺實現資源的實時動態創建。例如當虛擬機資源池資源不足時，可以根據母機資源情況，動態創建新的虛擬機資源。最后是現網掃描巡檢能力，自動識別不符合當前規則的應用部署，提供整改建議。3）自動化運維平臺3）自動化運維平臺自動化運維平臺實現了單元化架構下分布式數據庫部署維護的全生命周期管理。相比傳統架構下的自動運維管理平臺，面向單元化與分布式數據庫結合架構下的運維管理平臺需要面對大量服務器節點場景下

74、的標準化與批量化的運維壓力，所以需要著重建設如下能力：-51-腳本管理與場景化腳本運維能力。由于單元化+分布式架構下，集群節點數顯著增加，存在大量需要基于腳本進行統一批量執行的運維操作，例如所有節點的一次配置變更。所以平臺針對腳本的使用需要支持腳本的管理與執行、允許腳本在已授權的一臺或多臺機器行運行、支持針對場景的預定義腳本管理、支持腳本的執行調度管理（例如前后順序、串行或并行），最后執行性能的擴展性，即針對大規模節點的并發執行效率應該與節點的規模相關度不大。發布管理。支持對灰度發布的調度管理、例如灰度發布的順序、間隔、并行力度等；支持差異化的變量配置，可以便捷定義與使用差異化規則。支持版本管

75、理與回滾，對于一個子系統，自動運維平臺應該記錄所有主機的應用與數據庫節點版本和發布時間線，支持快速高效的回退。支持分布式架構下的數據庫操作結果合并能力。針對小單元架構，運維管理平臺需要具備跨單元分布式數據庫節點數據的查詢合并能力，將各個單元的查詢結果合并提供一個完成的查詢數據。支持風險識別與自動備份。特別通過運維管理平臺進行涉及數據的高風險操作時，運維管理平臺可以自動調用分布式數據庫的備份能力，進行數據備份，并按需快速還原。分布式的定時任務管理。定時任務可以根據管理員定義的固-52-定時間或間隔周期來針對一個給定范圍執行一項任意的任務。任務的執行需要避免多次執行、超時執行和漏執行。針對單元的數

76、據庫備份任務就是典型的分布式定時任務。分布式架構下的文件存儲與分發。無論是應用/數據庫版本發布還是日常運維，都會涉及文件（例如安裝包、腳本）的快速分發（1 臺或多臺主機），同時針對跨中心的場景應用具備就近分發能力，分發過程可以基于最近的存儲節點或副本進行分發。4）鏈路監控告警系統4）鏈路監控告警系統單元化+分布式數據庫架構場景下，業務請求調用鏈路的復雜度顯著增加，鏈路監控告警系統需要覆蓋單元化業務到分布式數據庫的全鏈路組件的端到端的監控告警能力。具體如下：全覆蓋監控。全覆蓋監控。提供全鏈路基礎架構、公共平臺、中間件、應用、數據庫的監控與告警能力，提供聯機業務指標和跑批場景指標的監控。模板化監控

77、配置。模板化監控配置。提供模板化的監控采集配置，基于策略的閾值配置以及個性化監控告警通知規則，同時可以實現基于CMDB部署信息的監控配置自動添加。個性化監控視圖。個性化監控視圖。建立多維度監控視圖、可自定義監控展現面板。建立端到端的交易場景監控與跑批的全局監控視圖。靈活的監控告警上報與存儲。靈活的監控告警上報與存儲。提供靈活的監控指標上報和告警信息上報接口，支持指標和告警歷史值的查詢與導出，并可以-53-按需設定存儲保留策略。對于單元化+分布式數據庫架構下的鏈路監控，其中一個非常關鍵的功能就是全鏈路各環節響應時間的監控采集與分析匯總。即可以從全局層宏觀的查看各個環境的響應時間均值情況，也可以針

78、對特定慢交易查看具體慢在哪個環節。如圖 23 所示是一個鏈路響應時間監控的實現方案示例。系統鏈路追蹤通過鏈路日志收集模塊收集微服務調用信息并輸出到磁盤的日志文件中，并通過 filebeat 實時傳輸到 kafka 集群中。通過訂閱 kafka 日志 topic 的程序，基于 SpanId（當前這次調用的 ID）、TraceId（一次請求會生成一次全局的請求 ID，跨節點往下傳遞）進行解析、過濾后傳輸給 ES 集群，以提供檢索、分析功能。最后數據可視化展示。鏈路信息輸出點位于網關、業務接收、業務發送、數據，每一次遠程調用請求生成一個 Span。Span 是請求中的基本工作單元，用于記錄調用中的詳

79、細信息（如時間、調用 ip 地址和端口、接口名稱、接口參數、響應參數等），需要通過代碼調整在網管層、業務層和數據層進行 span 信息的采集與文件輸出，平臺根據輸出的 span 能拼出一條完整的請求鏈路。-54-圖 23 鏈路響應時間監控實現方案示意圖-55-四、典型案例（一）建設銀行案例1.應用背景1.應用背景建設銀行客戶規模和日均交易量達數億級別，當前主機平臺已逐步顯現處理性能壓力。且隨著信息化技術的快速發展，業務規模仍將進一步擴大，傳統集中式架構達到擴容瓶頸，無法滿足未來業務發展需要；另一面，當前金融業核心系統強依賴于國外軟硬件，不滿足國家安全戰略要求。因此，行內核心系統由主機下移到開放

80、平臺勢在必行。為實現以上目標，建設銀行開展了核心系統下移至國產分布式數據庫相關工作。但目前國內大規模、復雜的核心業務下移至國產分布式數據庫的方案還達到成熟可借鑒的程度，國產軟硬件產品也需要時間檢驗產品成熟度，因此整個工程大膽探索，采用大量開創性技術，通過應用單元化和分布式數據庫底座，實現核心系統向分布式平臺平穩下移。下面詳細介紹。2.應用方案2.應用方案建設銀行分布式系統總體技術架構如圖 24，包含應用路由、服務集成代理、應用組件集群、配置中心、分布式數據庫等主要組件。其中分布式數據庫使用 GoldenDB 分布式數據庫。如圖 24所示，各組件構成有機整體，實現大型系統靈活路由和高并發處理能力

81、。具體如下：-56-圖 24分布式系統總體技術架構應用集成層：應用集成層包含應用路由、服務集成代理兩大組件。應用路由：具備橫向轉發能力，交易請求發往應用集成層，首先會就近進入當地的應用路由。應用路由通過配置中心的 API接口，確認交易請求歸屬的 Region，如不屬于本地 Region，則將請求轉發至交易歸屬 Region 的應用路由。對應 Region 的應用路接收到請求后會將請求轉發給與其同 Region 的服務集成代理。服務集成代理：服務集成代理具備跨系統事務一致性處理能力，當一筆交易涉及多個服務子系統，如涉及跨 Region 的轉賬-57-交易時，服務集成代理會將單筆轉賬交易拆解成一筆

82、轉出交易和一筆轉入交易，每筆交易都會同時準備好相應的沖正交易數據。此外，在系統過程投產過程中，一支業務的部分數據還在主機平臺，部分數據在開放平臺，這種情況也由服務集成代理跨平臺協調一致。產品服務層：產品服務層提供銀行業務的具體服務，包含產品服務，是整個信息系統的重要組成，目前運行在三個平臺上：主機平臺、C 平臺和 JAVA 平臺。其中主機平臺上的產品服務會全部下移到開放平臺（C/JAVA）上。開放平臺上引入 GoldenDB分布式數據庫，承載原來主機平臺上的數據庫服務。數據訪問代理作為產品服務和數據庫之間的適配層，針對 GoldenDB 等多種數據庫進行適配和統一訪問。配置中心：負責提供應用路

83、由和服務集成代理所需要的定位信息。配置中心包含客戶端和服務端兩部分，客戶端通過 SDK 的方式嵌入在應用路由和服務集成代理組件內，服務端基于 ZK、NoSQL 緩存等方式開放相應的路由數據查詢服務。GoldenDB 分布式數據庫提供大規模數據存儲和高并發數據庫訪問能力。GoldenDB 實現數據多分片、彈性擴容和分布式事務強一致讀寫，通過數據多副本、快同步、分組管理、備份恢復等技術實現大規模數據庫的高可用、高可靠，以及多地多中心容災能力。-58-數據切分與路由方案：業務單元劃分綜合考慮業務負載均衡、數據量負載均衡以及減少跨區操作等因素，通過數據的水平拆分和垂直拆分兩種方式，將業務劃分為四個 S

84、PU 大邏輯單元，近百個數據分片。業務請求通過渠道層后，進入應用集成層。首先會就近進入本地應用路由，本地應用路由解析出請求中的業務類型以及 ID信息，通過訪問配置中心的路由數據，確認交易請求歸屬的業務單元，如不屬于本地業務單元，則將請求轉發至交易歸屬業務單元的應用路由。對應業務單元的應用路由接收到請求后會將請求轉發給與其同一單元內的服務集成代理。圖 25數據路由規則構成-59-如圖 25 所示具體來說，前端渠道送到平臺的請求，根據請求路由的交易碼，確定路由的類型，支持卡號、賬號和手機號等，通過對應的號碼信息查詢到所在應用分區號，再根據應用分區號可以快速確定對應的服務單元地址。應用層的服務單元數

85、量較多，通過眾多節點分擔聯機處理壓力，滿足高并發處理性能要求。而在數據庫層，則使用大單元機制，在一套 GoldenDB 集群下創建四個租戶集群，分別部署在四個數據中心。由于數據庫層采用大單元設計，同一數據中心內的請求均由同一數據庫租戶處理，無需應用層協調分布式事務，這顯著降低跨服務集成代理跨子系統處理的業務吞吐量，減少資源壓力。采用大單元設計的好處是應用層和數據庫層擴容解耦。當數據容量不足時，數據擴容僅發生在數據庫層，路由層無需任何配置改變；而應用處理性能不足時，增加對應數據中心的應用服務節點，路由層的應用路由和配置中心僅需要關注業務類型信息即可，如圖 26 所示。-60-圖 26大單元設計實

86、現應用與數據庫解耦其次是簡化路由配置的粒度，不需要基于分行粒度或分片粒度進行路由設計，路由粒度變為四個大單元級，管理更加簡單，減少了配置管理的復雜度?？鐢祿行氖聞沼煞占蓭韺崿F。服務集成代理具備處理跨系統子事務的一致性能力，將數據中心請求拆解成一個或多個服務請求。如跨數據中心轉賬交易時，服務集成代理會將單筆轉賬交易拆解成一筆轉出交易和一筆轉入交易，每筆交易都會同時準備好相應的沖正交易數據。執行正常，等待各子系統完成交易操作；執行失敗，則會調用該交易的沖正交易，確保轉賬涉及的各方賬戶數據恢復到交易之前狀態。而大單元內部的跨行操作由 GoldenDB 分布式事務來保障。GoldenDB 通過

87、全局事務節點來管理分布式事務的生命周期，實現數據的實時強一致。-61-3.應用成果對私核心系統里程碑節點：3.應用成果對私核心系統里程碑節點：2021.03 完成國內對私業務的大型分布式核心系統在生產環境部署，實現與主機系統并網運行，交易雙發。2021.07 完成海外核心在生產環境部署，實現與主機系統并網運行，交易雙發。2021.12 青海、寧夏兩家分行的對私業務從并網狀態切換到開放平臺，完成兩省投產。試點業務非功能指標。下移開放平臺后，平均交易時長控制在 50ms 左右，接近主機平臺處理時延；核心批處理時長縮短 1個小時；壓力峰值大大減輕，在 3 萬 TPS 下仍保持低資源占用，達到建設銀行

88、對服務質量以及未來業務增長的處理性能要求。當前已完成兩個省份投產，正在逐步將其他省分行從并網狀態切換到投產狀態，并加大主機平臺剩余系統向分布式平臺遷移的步伐。單元化架構提升了系統的橫向擴展能力和系統整體可用性。但單元化開發對于應用存在一定的侵入，在新系統設計時需要認真分析單元拆分的邏輯，減少跨單元訪問。建設銀行采用大單元設計，將核心系統數據拆分為四個大單元，單元內的跨分片事務處理交由分布式數據庫處理，大單元之間的事務交由服務集成代理處理，有效減少了在下移改造過程中對原有系統的邏輯入侵，-62-最大程度地保持了系統的穩定性，實現了應用路由層、產品服務層和分布式數據庫層的解耦，便于各層獨立擴容和管

89、理。（二）平安銀行案例1.應用背景1.應用背景平安銀行信用卡老的核心系統采用的是IBM大型機AS400架構，由于是國外成熟技術，早期對平安銀行信用卡業務的起到很好的推動作用。但是隨著業務的發展，系統技術升級困難、軟硬件成本過高、系統擴容難度大、業務發展不靈活、新功能實現周期過長等問題愈發凸顯。2018 年平安銀行啟動信用卡核心系統的重構選型，經過多輪的對比，最終決策以高擴展、高彈性、業務自主可控為主要的架構重構目標，選擇分布式單元化架構去 IBM 大型機，數據庫使用 TDSQL，預期實現至少支持 10 倍并發業務量，支撐 3.3 倍發卡量，批量處理性能提升 3 倍，并且實現業務系統完全自主可控

90、的目標。2.建設方案1）單元化業務總體架構2.建設方案1）單元化業務總體架構平安銀行單元化架構基于量身打造的分布式 PaaS 平臺如圖27，應用在進行單元化分布式改造時盡可能只關注業務邏輯的實現，而平臺架構、數據庫和各種工具交給 PaaS 層。-63-圖 27 平安銀行 Paas 平臺平安銀行信用卡業務的單元化 DSU 架構總體如圖 28 所示，總體上我們的 DSU（Distributed Service Unit）架構包括 CS 區（Common Service）、CM 區（Central Management）和 DSU 區，其中 CS 區和 CM 區為非單元化區，DSU 區為單元化區。C

91、S 區是提供公共服務，主要包括配置中心、監控中心、消息中心、注冊中心、發布中心等；CM 區是提供公共管理功能，主要進行參數管理、運營管理、經營報表服務。DSU 區是按照客戶緯度進行單元化拆分后的業務數據區，單元的基本要求是業務自包含，即客戶的業務在單元內完成，同一個客戶無須跨單元訪問相關數據。-64-圖 28 平安銀行信用卡業務的單元化架構圖2）業務單元的數據切分與路由方案2）業務單元的數據切分與路由方案單元分片的路由邏輯如圖 29，是根據卡號、客戶號、銀行賬號進行映射，每個客戶會根據卡賬客的映射得到一個唯一的PID 號，根據 PID 進行 hash 得到該客戶所在分片。分片信息由GNS 服務

92、負責維護，在用戶第一次注冊時分配，之后客戶每次登錄時訪問該數據。GNS 把分片信息同步給 DLS 服務，DLS 服務負責進行服務的交付，收到用戶請求后根據 GNS 的分片信息生成路由到該分片的策略。DLS 把請求轉發到對應的 DSU 后，由 DSU 完-65-成業務邏輯，并把結果返回給客戶端。圖 29 單元分片的路由邏輯3）分布式數據庫部署方案3）分布式數據庫部署方案如圖 30 所示是平安銀行單元化的部署架構，采用了兩地三中心的架構，根據所承載用戶的不同劃分出多個邏輯單元。-66-圖 30 單元化的部署架構生產數據中心和同城數據中心之間采用數據強同步，如圖31 所示，即任意時刻同城 RPO=0

93、，RTO 理論在 40s 左右，實際測試最壞的情況不超過 90s。當生產中心出現任何軟硬件異常時，業務會自動切換到同城數據中心，期間的業務影響是業務總體的1/n 短暫不可用，不可用時間小于一分鐘。-67-圖 31 數據中心架構4）試點業務擴容策略4）試點業務擴容策略設計擴容策略時同時考慮到縱向和橫向的擴容場景，如圖32 所示。圖 32 系統配置擴容-68-縱向來說，初始上線的系統配置只占服務器資源的 25%，這意味必要時在不更換硬件的情況下可以進行 4 倍的擴容。而橫向上則可以支持無限的橫向擴容，隨著業務增長，可以滿足任意量級的業務發展需求。雖然可以方便的進行縱向擴容，但是需要理解，分布式架構

94、對縱向擴容的需求應該盡可能低，因此設計的縱向擴容方案為“以防為主，以治為輔”的方針，盡量避免數據遷移的發生。同時還需充分考慮到單元的容量余量，給 DSU 容量預留了一定的buffer。橫向擴容的整體邏輯如圖 33 所示：新建一組或者多組單元。調整客戶的路由規則，比如新的客戶路由到新單元的比重調高，讓大部分新客戶端路由到新的分片。由于路由規則的調整，后續老的 DSU 業務基本不再增長，新 DSU 承擔了新業務的流量。-69-圖 33 橫向擴充5）5）數據操作包括數據訪問和更新，為了支持單元化的架構，可把數據訪問工具和業務一樣進行分片化訪問，可以一次訪問一個分片，也可以一次訪問全部分片。雖然系統是

95、分布式的，但是事務卻未必要分布式，相反應盡可能規避分布式事務，以保證系統的健壯性。在業務邏輯上，盡可能實現單元內業務自包含。如果一定要進行分布式事務，需考慮在框架層支持，如果框架也不能支持時由應用層實現，應盡可能避免使用數據庫層的分布式事務，一方面數據庫的分布式事務還不成熟，另外容易形成對特定數據庫的依賴并產生單點故障的風險。-70-6）試點業務維護方案6）試點業務維護方案由于所有的系統節點完成了去中心化的工作，因此對所有節點都可以使用滾動升級的模式進行維護，而不影響業務的連續性。同時對可能發生意外或者容易出現故障的環節做了完善的應急預案，在緊急情況下可以自動或者人工模式快速的故障恢復。3.應

96、用成果3.應用成果新信用卡核心系統實現了 100%源碼的自主知識產權。經過壓測，新信用卡核心系統并發業務量至少達到原 AS400 核心系統并發量的 20 倍，交易耗時降低 2.5 倍，批量耗時降低 3 倍，新業務功能的交付周期大大縮短，業務應對市場能力得到提升，系統總體建設、維護成本降低 70%左右，系統可用率提升一個檔次。1）業務時間里程碑節點1）業務時間里程碑節點2020-10-31，信用卡 A+上線切換成功，是分布式方案邁出第一步最重要的里程碑。2020-11-11，新的信用卡 A+上線后第一個雙十一和業務促銷活動，期間系統運行平穩。2021-04-30，完成信用卡 A+容災演練，容災切

97、換過程平滑，系統運行穩定。2021-07-19，信用卡 A+同城切換演練，采用到點一鍵切換，并在同城運行一天，系統運行平穩。經過系統促銷活動、重要節日、同城、容災切換等檢驗，系-71-統具備自動化同城切換，分鐘級容災切換并真正承擔全業務流量的能力。2）試點業務非功能指標2）試點業務非功能指標系統可用率大大提高，可以達到 5 個 9。使用了僅 1/3 的成本建設了各項指標都遠超原系統的集中式架構。具體新老核心對比如圖 34 所示。圖 34 新老核心效果對比3）總結和展望3）總結和展望單元化的分布式架構有著巨大的優勢，主要體現在，第一：雖然單機的可用率很低，但是分布式系統整體的可用性卻大大提-72

98、-升；第二：通過對基礎架構、數據庫和應用的自主可控，達到了業務層的自主可控和業務快速創新的要求；第三：單元化的分布式架構，搭積木式的即插即用模式，徹底解決了系統發展的瓶頸，無懼任何促銷。當然，單元化架構也有其弊端，主要有以下方面，第一：分布式架構建設和改造的工作量大，需要配套建設的分布式工具也很多；第二：過度單元化可能會帶來很多問題，比如上下游業務不均衡帶來的小業務被動單元化，以及單元化帶來的應用層和數據庫層的資源浪費等；第三：單元的失控和故障的蔓延，分布式的故障如果不能做到有效的隔離，很容易形成蔓延，那將會是災難，因此避免單元的管理失控非常重要。分布式單元化的架構，在信用卡 A+業務上取得成

99、功之后，平安銀行也在總結經驗，把信用卡的模式推廣到其他的核心信息，后續平安銀行成功上線了統一支付系統的分布式改造，另外對其他核心系統的改造也在規劃和進行中。（三）華夏銀行案例1.應用背景1.應用背景隨著華夏銀行數字化轉型戰略的持續深入推進，銀行業務系統需要同時具備高性能、可擴展、高可用、高容錯等特性，為支撐各分行特色業務的快速發展，更加開放與靈活的技術架構成為首選。-73-2.建設方案1）單元化業務總體架構2.建設方案1）單元化業務總體架構華夏銀行分行中間業務平臺采用區域拆分的大單元設計，設計要求統一入口，流量調配，各分行業務進行資源隔離。數據基于各分行進行設計方案，采用區域拆分的方式，分行產

100、品的所有數據放入一個單元，對應到一個單獨的分布式數據庫集群，如單元 1 中代發工資、ETC 等業務產品對應北京分行 DB，組成完整區域大單元，其他分行依次類推。如圖 35 所示：圖 35 華夏銀行單元業務示意圖-74-2）分布式數據庫部署方案2）分布式數據庫部署方案如圖 36 所示是華夏銀行單元化的部署架構，根據分行地域的不同劃分出多個邏輯單元，采用同城雙中心架構。數據庫層采用的是 1 主 3 備的方式，本地機房 1 備，另外中心機房 2 備份，確保一個節點的 ack 返回，主庫提交，這樣最大的保障數據一致性并兼顧性能問題，最大限度保證數據的安全。同城雙中心部署具備同城雙活能力，每個數據中心均

101、可對外提供服務，同時具備城市內部的跨中心容災能力，任何一個數據中心或主單元故障都可以切換到備中心或備單元提供服務。圖 36 單元業務部署圖-75-3）業務高可靠與業務連續性架構3）業務高可靠與業務連續性架構在城市大集群下進行跨中心的一主三從（四副本）模式進行部署，通過配置同城從中心兩副本為強同步模式（保證所有數據變更至少會在所有強同步副本中有一個完成持久化），保證所有數據的變更具備跨中心的副本來應對集群的跨中心高可用能力要求，最大限度的保障數據一致性并兼顧性能問題，保證數據的安全（RTO=2 個），然后接入到所在 IDC 的負載均衡模塊。應用通過各個 IDC 的負載均衡模塊的 VIP，接入 T

102、iDB 進行讀寫訪問，實現應用同城多活。TiDB 的管理與調度模塊 PD Server 同樣也是跨同城三 IDC-86-部署，每個 IDC 部署一個節點。在同城多機房部署的架構下，任何一個 IDC 都可以提供業務接入，任何一個 IDC 的服務器節點故障，或者整體 IDC 故障，都不會影響業務可用性，或者只是短暫的影響，然后在 RTO 的預期內快速恢復。3）業務擴容策略微眾銀行在單元內采用的是單實例主備架構的數據庫模型。單元內的擴容主要通過數據節點垂直擴展實現，即通過數據庫節點在線滾動升級的方式逐步將一個數據節點組相關的多個數據庫的物理資源進行升配，例如提高 CUP、內存、網絡、磁盤 IO等。當

103、某個業務單元的用戶數量達到預設值，就需要進行新增單元擴容。微眾銀行通過單元自動化擴容平臺，可以實現單元一鍵部署功能，實現高效率的單元擴容。已經滿載的單元將不再接受新的用戶開戶，所有的新開戶請求將會被自動路由到新擴容的單元中。4）業務跨單元數據操作與分布式事務設計微眾銀行通過自研的分布式消息中間件平臺進行跨單元間的數據交互。對于跨單元間的事務一致性，由應用層實現跨單元的分布式事務保證。在此不做詳述。3.試點成果3.試點成果經過幾年的發展，微眾銀行目前已有數千個 TDSQL 實例，近-87-百個業務單元，承載行內的所有核心業務系統。TDSQL 管理的數據規模達到 PB 級，每天承載數億次的金融交易

104、。同時，還建立了數十個 TiDB 集群，承載多單元數據匯聚、核心業務批量、數據歸檔、全局類業務存儲等業務場景，服務器節點達數百個，數據規模達到 500TB 以上。在微眾銀行單元化分布式架構的基礎上，通過對 TDSQL 和TiDB 數據庫的綜合應用，有效的解決了行內各類業務對于數據庫存儲需求，也進一步提升了行內單元化分布式核心架構的可靠性與完備性。（五）支付寶案例1.應用背景1.應用背景支付寶業務誕生于 2004 年。到 2013 年，支付寶的應用層已經是無狀態的了，可以隨意水平擴展，容量足以滿足業務需求。此時的支付寶核心數據庫依然使用 Oracle，并按用戶維度水平拆分。應用層流量是完全隨機的

105、，任意一個應用節點都可能訪問任意一個數據庫節點，因此每個應用都需要占用數據庫連接，而數據庫連接是非常寶貴的資源，是有上限的，這必然導致 Oracle數據庫的連接數不足。因此，數據集連接數的瓶頸導致了應用不能擴容，意味著支付寶系統的容量定格了，不能再有任何業務量增長。既無法應對大促活動的洪峰流量，隨著業務的高速發展，支撐日常業務也捉-88-襟見肘。為解決上述問題，支付寶自研了 OceanBase 分布式數據庫，在普通硬件上實現金融級的高可用性。OceanBase 使用 Paxos 協議在保證數據強一致的前提下，實現水平擴展，給上層應用提供充足的數據庫連接、計算以及存儲資源，滿足支付寶業務高速發展

106、的需要，支撐支付寶實現了單元化異地多活的技術架構。2.建設方案1）單元化業務總體架構2.建設方案1）單元化業務總體架構支付寶的技術架構也經歷了單活、同城雙活、兩地三中心三個階段，隨著支付寶業務量的規模和復雜度越來越高，業務對于基礎架構的要求也越來越高，包括擴展能力、容災能力、灰度能力等。最終支付寶發展到了單元化架構，將主要業務拆分單元即分片，裝入不同的邏輯單元內，每個分片的數據庫實現三地五中心部署即三地五中心的單元化架構。支付寶單元化架構包含RZone、GZone 和 CZone 三類：其中 GZone 部署的是無法拆分的數據和業務，GZone 的數據和業務被 RZone 依賴，GZone 全

107、局只部署一份。CZone 的出現是因為 GZone 全局只有一份，不同城市的RZone 可能依賴 GZone 服務和數據的時候需要遠距離調用，延遲比較大，所以在每個城市部署一個 CZone 作為 GZone 的只讀副本，為本城市的 RZone 提供服務。-89-RZone 部署的是可拆分的業務和對應的數據。每個 RZone內的數據分片如圖所示有五副本，實現三地五中心部署，每個分片內只有一個可寫入的主副本，其余副本按照 Paxos 協議做數據強一致。每個 RZone 內實現業務單元封閉，獨立完成自己的所有業務。支付寶對單元化的基本要求是每個單元都具備服務所有用戶的能力，即具體哪個單元服務哪些用戶

108、是可以動態配置的，當某個單元因為故障而無法提供服務時，客戶端的訪問可以被重新路由到其他單元，由其他單元的應用及數據庫提供服務。如圖 42所示。圖 42 支付寶單元化整體架構-90-任何應用的 RZone 都可以給所有客戶提供服務，對數據庫的要求就是需要每個單元都包含全量數據。OceanBase 數據庫采用三地五中心部署，每個 IDC 部署集群的一個 Zone，每個 Zone 都包含業務所需要的全量數據。2）業務單元的數據切分與路由方案2）業務單元的數據切分與路由方案單元化的必要條件要求全站所有業務數據切分所用的拆分維度和拆分規則都必須一樣。支付寶以用戶來切分數據，交易、收單、微貸、支付、賬務等

109、全鏈路業務都基于用戶維度拆分數據，并且采用一樣的規則拆分出同樣的切片數，支付寶以用戶 id 末2 位作為標識，將每個業務的全量數據都劃分為 100 個切片（00-99）。把一個或幾個數據分片部署在某個單元里，這些數據分片占總量數據的比例，就是這個單元能夠承擔的業務流量比例。選擇數據分片的維度是個很重要的問題，一個好的維度應該粒度合適。粒度過大，會讓流量調配的靈活性和精細度受到制約；粒度過小會給數據支撐資源和訪問邏輯帶來負擔。通過引入數據訪問中間件，可以實現對應用透明的分庫分表。一個比較好的實踐是：邏輯拆分先一步到位，物理拆分慢慢進行。以賬戶表為例，將用戶 ID 的末兩位作為分片維度，可以在邏輯

110、上將數據分成 100 份，一次性拆到 100 個分表中。這 100個分表可以先位于同一個物理庫中，隨著系統的發展，逐步拆成-91-2 個、5 個、10 個，乃至 100 個物理庫。數據訪問中間件會屏蔽表與庫的映射關系，應用層不必感知。這 100 個表創建時候，可以配置不同的 Primary Zone，從而靈活配置其主副本位于哪個單元。比如第一個分表的 Primary Zone 是 Zone1Zone2Zone3，表示該表的主副本默認都在 Zone1 內，而與之對應的業務系統也在 Zone1 內，保證正常情況下整個處理都在一個單元內閉環。當單元內數據庫服務器發生故障時，數據庫集群會按照該表配置的

111、Primary Zone 的順序調整其他單元內的從副本為主副本，這個過程是自動完成的，且可以保證 RPO=0。這么多的組件要協同工作，必須共享同一份規則配置信息，如圖 43 所示。圖 43統一路由規則必須有一個全局的單元化規則管控中心來管理，并通過一個-92-高效的配置中心下發到分布式環境中的所有節點。規則的內容比較豐富，描述了城市、機房、邏輯單元的拓撲結構，更重要的是描述了分片 ID 與邏輯單元之間的映射關系，如下表 6 所示。表 6 規則配置內容示例表城市數據中心業務分片 ID數據分片 ID城市 1IDC1RZ01：【00-19】【00-19】IDC2RZ02：【20-39】【20-39】

112、城市 2IDC3RZ03：【40-59】【40-59】IDC4RZ04：【60-79】【60-79】城市 3IDC5RZ05：【80-99】【80-99】單元化是個復雜的系統工程，需要多個組件協同工作，從上到下涉及到 DNS 層、反向代理層、網關/WEB 層、服務層、數據訪問層?？傮w指導思想是“多層防線，迷途知返”。每層只要能獲取到足夠的信息，就盡早將請求轉到正確的單元去，如果實在拿不到足夠的信息，就靠下一層。DNS 層感知不到任何業務層的信息，但支付寶使用“多域名技術”。比如 PC 端收銀臺的域名是 ，在系統已知一個用戶數據屬于哪個單元的情況下，就讓其直接訪問一個單獨的域名，直接解析到對應的

113、數據中心，避免了下層的跨機房轉發。例如 ，gtj 就是內部一個數據中心的編號。移動端也可以靠下發規則到客戶端來實現類似的效果。-93-反向代理層是基于 Nginx 二次開發的，后端系統在通過參數識別用戶所屬的單元之后，在 Cookie 中寫入特定的標識。下次請求，反向代理層就可以識別，直接轉發到對應的單元。網關/Web 層是應用上的第一道防線，是真正可以有業務邏輯的地方。在通用的 HTTP 攔截器中識別 Session 中的用戶 ID 字段，如果不是本單元的請求，就 forward 到正確的單元。并在Cookie 中寫入標識，下次請求在反向代理層就可以正確轉發。服務層 RPC 框架和注冊中心內

114、置了對單元化能力的支持，可以根據請求參數，透明地找到正確單元的服務提供方。數據訪問層是最后的兜底保障，即使前面所有的防線都失敗了，一筆請求進入了錯誤的單元，在訪問數據庫的時候通過OBProxy 查詢數據主副本所在的單元，也一定會路由到正確的庫表，最多耗時變長，但絕對不會訪問到錯誤的數據。即使 OBProxy無法準確識別主副本所在位置，他也會隨機路由到任何一個OBServer，這個 OBServer 可以在集群范圍內找到應用所需的數據并返回。3）分布式數據庫部署方案3）分布式數據庫部署方案支付寶系統中任何一個單元都可以給所有客戶提供服務，對數據庫的要求就是需要每個單元都包含全量數據。因此Ocea

115、nBase 數據庫采用三地五中心部署，每個 IDC（也即是每個單元）部署集群的一個 Zone，每個 Zone 都包含全量數據。-94-如圖 44 所示，RZone 的數據是可分片的數據，需要確保數據與應用部署到一個單元內。以【00-19】分片為例，這些分片的數據在 5 個 IDC 都有副本，默認情況下，所有的讀寫操作都在主副本完成，其他的從副本通過 Paxos 協議與主副本組成 Paxos組。當要對數據進行修改時，主副本會同步 Redo-Log 日志給從副本，當主副本確認多數派的副本已經完成落盤后才會返回給應用。這樣可以確保在任何少數派故障情況下都可以保證 RPO=0。為了保證主副本與應用都在

116、一個單元內，可以對這些表配置Primary Zone（Zone1 優先級最高），從而讓【00-19】分片內的所有主副本都位于 Zone1，與【00-19】分片的應用 RZone 在一個單元內，減少網絡的開銷。圖 44OceanBase 數據庫 RZone 數據分布示例圖-95-在這種情況下，由于所有的寫操作需要滿足多數派落盤，對于一個 5 副本的集群來說，OceanBase 需要滿足 3 個副本的落盤才能返回給應用，而每個城市最多只有 2 個副本，因此對于任何一次寫操作都需要跨城市的同步 Redo-Log 日志，對性能造成影響，因此城市 1 和城市 2 的距離不能太遠。為了降低存儲成本，城市

117、3 的數據中心也可以部署日志型副本，該副本沒有基線數據，只有日志數據，因此他只能參與投票和幫助其他副本恢復數據，而自己不能轉為主副本提供服務。因此這種情況下，城市 3 的數據中心基礎設施可以要求低一些，但他永遠也無法成為主副本。GZone 和 CZone 的數據一般是全局數據，且不可以分片，這些數據被 RZone 所依賴。如圖 45 所示，支付寶將 GZone 數據部署為一個五副本，也就是每個單元都有 GZone 的全量數據，Primary Zone 配置為（Zone1=Zone2 Zone3Zone4Zone5），將 GZone 數據的主副本匯聚到單元 1 和單元 2 內（位于一個城市），主

118、副本會通過 Redo-Log 日志的方式強同步到其他單元內的副本，確保 RPO=0。所有單元內的應用要修改 GZone 的數據，都需要訪問單元 1 和單元 2 的數據，會產生跨單元的延遲，好在一般應用較少更新 GZone 的數據。應用訪問 GZone 數據較為頻繁，為了減少跨單元的網絡延遲，OceanBase 集群可以在每個集群創建一個 GZone 的只讀副本，-96-也就是 CZone。只讀副本不參與 Paxos 組的投票，只是作為一個觀察者實時追趕 Paxos 成員的日志，并在本地回放。因為 CZone并沒有加入 Paxos 組，不會造成投票成員增加導致事務提交延時的增加。但由于 CZon

119、e 與 GZone 之間強同步，當對 GZone 進行修改時，主副本需要收到所有 CZone 副本的反饋才會返回給應用，因為會有一定的延遲，不過 GZone 的數據修改不多，這個影響可以忍受。圖 45OceanBase 數據庫 GZone 及 CZone 數據分布示例圖4）業務高可靠與業務連續性架構4）業務高可靠與業務連續性架構借助 OceanBase 多副本的能力，支付寶業務可以實現在少數派故障的情況下，實現 RPO=0，RTOZone2Zone3Zone4Zone5】，此時由于第一優先級 Zone2 也無法提供服務，那么單元 3 內的【00-19】分片的副本將成為新的主副本，此時【00-1

120、9】應用也由單元 3 內的 RZ03接管，所以【00-19】用戶的訪問可以在單元 3 內部完成。同理，對 于【20-39】分 片 的 數 據，他 的 PrimaryZone 是【Zone2Zone1Zone4Zone3Zone5】,由于 Zone2 和 Zone1 都已無法提供服務，因此 Zone4【20-39】分片的數據將成為主副本，剛好與應用都在單元 4 內。因此配置 Primary Zone，OceanBase可以很好的根據應用單元化的切換來靈活的切換主副本的位置，-100-實現業務在一個單元內完成。圖 48OceanBase 數據庫城市級故障容災切換示意圖但此時由于只剩 3 個副本，對

121、于一個 5 副本的集群來說，需要滿足多數派落盤（3 個副本落盤），所以任何一次事務的完成都需要跨越城市 2 和城市 3，這會帶來較大的延時。這時可以將這個 5 副本的集群降級為 3 副本的集群，對于 3 副本的集群來說只要有 2 個副本落盤即可，可以在城市 2 內的兩個單元完成，從而大幅降低網絡延時。5）業務擴容策略5）業務擴容策略-101-隨著支付寶業務的不斷擴展，當單元內的資源不足以應對日常流量時，可以對各個單元內的資源進行擴容。應用服務器無狀態，可以線性的擴展，擴展后按比例切流量到擴容服務器即可。如圖 49 所示，OceanBase 數據庫也可以支持平滑擴容，比如之前每個單元內有2臺數據

122、庫服務器，形成一個2-2-2-2-2的集群，可以在每個單元內擴容2臺服務器，形成一個4-4-4-4-4的集群，使得各個單元內數據庫資源充足，滿足單元內業務需要。圖 49 OceanBase 數據庫單元內擴容示意圖擴容的服務器加入數據庫集群后，集群會基于負載均衡的策略在單元內進行負載均衡。如圖 50 的示例，單元 1 負責【00-19】-102-一共 20 個分片用戶的數據，擴容前，每臺服務器各有 10 個分片用戶的主副本，用來供應用服務器訪問，同時每臺服務器有 40個分片用戶數據的從副本來自別的單元的主副本提供備份服務。擴容后，基于負載均衡策略，舊服務器將自動遷移部分數據到新服務器，當新服務器

123、上的數據追平后，部分從副本將切換為主副本。最終每臺服務器可能有 5 個分片用戶的主副本來供應用來讀寫，同時每臺服務器可能有 20 個分片用戶數據的從副本，來給別的單元的主副本提供備份服務。這個過程是集群自動完成的，無需管理員手工調整數據的分布。單元內數據庫服務器的擴容并不影響整體分片的規則和流量路由的規則，單元 1 還是繼續給【01-19】分片的用戶提供服務。圖 50OceanBase 數據庫單元內擴容后負載均衡示意圖-103-支付寶為了應對雙十一等促銷活動的洪峰流量，如果擴容線下機房（現有單元）的話比較浪費，此時可以使用阿里公有云服務快速的擴容一個新的 Zone，并將部分單元在促銷前彈出到擴

124、容的新 Zone 中。例如圖 51 所示，原有的數據庫集群是一個 3 個 Zone 的集群，Zone1 為單元 1【00-39】分片的用戶提供數據服務，Zone2 為單元 2【40-79】分片的用戶的提供數據服務，Zone3 為單元 3 的【80-99】分片的用戶提供數據服務。擴容數據庫集群，從 3 個Zone 擴容到 4 個 Zone，并將【20-39】分片用戶的數據由單元 1彈出到單元 4。當然流量路由規則等配置也要同步修改，才能夠將【20-39】分片用戶的訪問流量路由到擴容的單元 4 中。圖 51 OceanBase 數據庫擴容新單元示意圖管理員可以調整庫表的 Locality 來實現上

125、述擴容，比如-104-【20-39】相關庫表的 Locality 需要首先在單元 4 內增加一個副本，等單元 4 內的從副本跟隨單元 1 內的主副本追平數據后，再調整 Primary Zone，將 Zone4 的優先級設置為最高，從而將【20-39】分片數據的主副本匯聚到單元 4 內。OceanBase 集群將能夠自動完成數據在單元間的傳輸和切主等操作。促銷活動結束后，管理員在進行反向的動作，實現集群的縮容。6）試點業務跨單元數據操作與分布式事務設計6）試點業務跨單元數據操作與分布式事務設計跨單元數據操作時會產生分布式事務，支付寶使用分布式事務中間件來保障在大規模分布式環境下業務活動的最終一致

126、性，應用于交易、轉賬、紅包等核心資金鏈路。分布式事務與服務框架、OceanBase 數據庫以及消息隊列等產品配合使用，實現服務鏈路級事務、跨庫事務和消息事務等各種組合。以支付寶三地五中心的部署結構為例，如圖 52 所示，假設一個轉賬的業務場景。付款方用戶 ID 是 12345666，分片號是66，應該屬于 RZ04；收款方用戶 ID 是 54321233，分片號 33，應該屬于 RZ02。付款方用戶的請求會被路由到 RZ04 的收銀臺，RPC 框架層會自動識別業務參數上的分片位，將請求發到正確的單元。業務設計上，系統會保證交易流水號的分片位跟付款用戶的分片位保持一致，所以絕大部分微服務調用都會

127、收斂在 RZ04內部。但是收款方的賬號就剛好位于另一個城市的 RZ02。當交易系統調用賬務系統給收款方的賬號加錢的時候，就必須跨單元-105-調用 RZ02 的賬務服務，圖中這條跨城訪問鏈路用紅色表示。這時分布式事務的 ACID 保障由中間件來完成。圖 52 跨單元分布式事務示例圖3.應用成果3.應用成果支付寶試點業務已完成了單元化整體改造，在數據庫、中間件及應用層都實現了自主研發。支付寶單元化的思想是單元內高內聚、單元間低耦合、跨單元調用無法避免，但應該盡量限定在-106-少數的服務層調用，大量的數據訪問操作控制在同城，把整體耗時控制在可接受的范圍內。支付寶通過單元化架構實現了平滑的擴容縮容

128、、實現了藍綠發布、實現了異地多活容災，OceanBase分布式數據庫在其中是核心的基礎設施，為螞蟻單元化改造提供了諸多核心能力：無限可伸縮微服務架構：無限可伸縮微服務架構：能夠通過快速搭建一個業務完整的邏輯部署單元對系統進行整體擴容，對新機房擴容等操作帶來巨大的便利。突破接入層、應用層和數據層的瓶頸，可支持無限擴展。異地多活部署：異地多活部署：除了具備異地容災能力以外，還能做到異地多城市多活，可隨時在多個城市間調配流量比例，在提升容災能力的同時，降低了成本。全站藍綠發布和線上灰度仿真：全站藍綠發布和線上灰度仿真：通過多單元之間靈活的流量調配機制，可以實現大規模集群的藍綠發布，極大的提升了發布效率。同時，通過單元內自包含的服務發現/路由和數據層的單元化分片，保證故障被切割的更小且具備獨立性，不會傳播到其他機房，從而實現發布時的故障自包含，支付寶基于這個機制實現了線上全鏈路壓測和灰度仿真環境，為業務提供了更真實的驗證環境，這對充分驗證業務正確性，降低技術故障起到了關鍵的作用。