《北京金融科技產業聯盟：2025金融級單元化架構設計及應用研究報告（53頁）.pdf》由會員分享，可在線閱讀，更多相關《北京金融科技產業聯盟：2025金融級單元化架構設計及應用研究報告（53頁）.pdf（53頁珍藏版）》請在三個皮匠報告上搜索。

1、金融級單元化架構設計及應用研究報告北京金融科技產業聯盟2025 年 5 月I版權聲明本報告版權屬于北京金融科技產業聯盟，并受法律保護。轉載、編摘或利用其他方式使用本白皮書文字或觀點的，應注明來源。違反上述聲明者，將被追究相關法律責任。i編制委員會編委會成員：聶麗琴萬柯辰楊明王豐輝王軍張春雷鄭陽編寫組成員：黎意超江鵬馮釗李軍華顧首成劉家瑜羅睿錢寶蕾楊振芳楊文云熊云斌楊承熙黃瀟馮宇陳明朱佳慶肖斌徐立江張沖顧夢寅吳潤東許澤敏潘星文狄尚朋編審：黃本濤劉昌娟參編單位：北京金融科技產業聯盟秘書處四川銀行股份有限公司深圳市騰訊計算機系統有限公司中國銀聯股份有限公司珠海華潤銀行股份有限公司中國人民保險集團股份

2、有限公司北京同創永益科技發展有限公司i目錄一、引言.1（一）課題背景.1（二）研究方法.1二、金融級單元化架構概述.3（一）術語描述.3（二）技術架構發展歷程.7三、金融級單元化架構設計.20（一）單元化適用場景.20（二）單元化架構設計原則.21（三）數據庫單元化架構設計.28（四）云平臺單元化架構設計.31（五）應用單元化架構設計.36四、金融級單元化架構應用場景.38（一）數據拆分場景.38（二）數據聚合查詢場景.40（三）單元路由轉發場景.41（四）單元高可用場景.44五、應用實踐.45六、總結展望.47（一）新技術融合加快業務創新.47（二）多地多活架構進一步深化.47（三）生態合作

3、與標準化建設逐步完善.48參考文獻.491一、引言（一）課題背景一、引言（一）課題背景在全球數字化轉型加速推進的背景下，金融行業面臨著前所未有的挑戰與機遇。特別是面對西方“脫鉤斷鏈”的技術封鎖和信息安全威脅，金融機構的技術架構自主可控、可持續發展顯得尤為重要。同時，銀行業正朝著更加智能化、個性化和高效化的方向邁進。未來的業務場景將更加多樣化，客戶對于服務的即時性、精準性、便捷性和連續性的要求也會越來越高。單元化架構最初起源于我國的互聯網公司，擁有較強的自主可控能力，同時具備高性能、高可用、多地多活的特點，適用于業務連續性要求高、用戶數量多、性能要求高的場景，是金融科技的重大研究方向。四川銀行以

4、新一代工程為契機，圍繞銀行的業務特點及管理要求，對單元化架構進行深入研究和創新應用，應用到四川銀行業務系統，依托北京金融科技產業聯盟向金融科技產業推廣。本文重點對單元化架構規劃及試點過程可能遇到的關鍵技術問題進行梳理、研究和提示，供金融行業相關單位參考。（二）研（二）研究方法究方法單元化架構作為業界較新的技術，如何結合金融行業的業務場景及管理要求，并進行研究、試點和落地，需要一套系統性的研究方法。這種方法不僅需要科學性，還要具備可行性，以確保2研究成果能夠順利轉化為實際應用。同時考慮到課題參與單位所承擔信息保密的責任和課題成果的篇幅關系，以下是課題組從POC 驗證、可行性評審、項目招標、總體設

5、計等不同階段的通用研究方法總結。1.POC（Proof of Concept）驗證1.POC（Proof of Concept）驗證目標：初步驗證單元化技術的成熟度及在金融場景下的適用性和潛在價值。方法：選取典型業務場景，如跨用戶、跨單元的轉賬處理等，設計并實施小規模的單元化原型系統。在設計驗證用例時，需重點關注單元化特有的功能，如單元化配置能力、容災能力、路由能力，同時由于金融行業嚴格的安全管理要求，需高度重視圖形化配置能力，以降低運維難度。2.可行性評審2.可行性評審目標：獲取領域內專家對單元化技術的認可和建議，明確在本項目落地具備可行性。方法：組織研討會，邀請金融行業中 IT 架構、分布

6、式系統、數據庫等領域的內外部專家，對 POC 結果及項目立項材料進行評審。在評審階段需關注新技術對開發測試運維的技術風險、基礎資源需求、成本投入等方面。3.項目招標3.項目招標3目標：引入市場競爭，選擇最優的技術和服務供應商。方法：發布詳細的需求說明書，明確業務目標、技術要求、質量標準、服務保障等需求。由于單元化屬于較新的技術，且對開發、測試、運維原有的習慣均產生了新的變化，除了關注新技術產品化能力外，需重點關注供應商在技術服務方面的案例及可投入情況，以保證落地質量。4.總體設計4.總體設計目標：明確單元化的總體設計方案，輸出單元劃分原則與劃分結果、路由規則以及各種單元所承載的應用系統清單等關

7、鍵信息。方法：根據業務發展需求、應用系統建設規劃、單元化的最佳實踐梳理出單元劃分原則，明確單元類型及數量，確認各應用系統歸類到何種類型的單元中，以及業務流量如何在單元內及單元間進行處理。二、金融級單元化架構概述（一）術語描述二、金融級單元化架構概述（一）術語描述為了本報告范圍內的相關術語表達含義統一，本節對相關術語進行描述。1.金融級1.金融級本報告中的“金融級”主要指應滿足金融行業 IT 系統的高標準要求。這類系統具有以下顯著的特點：41）高性能與低延遲：在高頻交易等場景下，系統需要能夠處理大量并發交易，同時保持極短的響應時間。這要求系統具有優秀的性能和高效的處理能力。2）高可用性與災難恢復

8、：金融交易需要持續不間斷的服務，任何中斷都可能造成巨大的經濟損失。金融級 IT 系統需要設計成高可用架構，如多數據中心、熱備份、負載均衡等，確保在極端情況下能繼續提供服務。同時，還需要具備快速的災難恢復能力，以應對自然災害或人為錯誤。3）高安全性：金融系統處理大量的敏感數據，包括個人身份信息、交易記錄、財務數據等。因此，安全措施必須極其嚴格，包括數據加密、防火墻、入侵檢測、權限控制、審計日志等，以防止數據泄露和惡意攻擊。4）合規性：金融行業受到嚴格的法律法規監管，IT 系統必須符合一系列的合規標準。5）數據完整性與一致性：金融交易的數據必須準確無誤，系統需要保證數據的完整性和一致性，即便在高并

9、發或故障切換的情況下，也應避免數據丟失或錯誤。6）復雜性與個性化：金融系統需要處理多樣化的業務邏輯，包括但不限于存款、貸款、投資、保險、支付、清算等，每種業務都有其特定的規則和流程。此外，還需要支持個性化需求，如5不同客戶的差異化服務。7）實時分析與決策支持：現代金融系統需要具備實時數據分析能力，能夠迅速處理大量數據，為風險評估、欺詐檢測、市場趨勢分析等提供支持。8）用戶界面與體驗：雖然后臺系統要求復雜，但對于最終用戶來說，前端界面需要簡潔、直觀、易于使用，同時提供多渠道接入，如網頁、移動應用、電話銀行等。9）集成與互操作性：金融系統往往需要與其他系統（如監管機構、第三方服務提供商、合作伙伴）

10、進行數據交換和業務協同，這就要求系統具備良好的集成能力和標準化的接口。10）可審計性：所有交易和操作都需要有詳細的記錄，以滿足內部管理和外部審計的要求。11）成本效益：盡管安全性和性能是首要考慮，但成本控制同樣重要。金融級 IT 系統需要在確保質量和安全的前提下，盡可能降低運營和維護成本。12）持續創新與適應性：隨著金融科技的快速發展，金融IT 系統需要不斷進化，引入新技術如人工智能、區塊鏈、云計算等，以保持競爭優勢和滿足客戶需求。綜上所述，金融級 IT 系統的設計、開發、測試和運維是一項復雜而嚴謹的任務，需要跨學科的知識和專業的團隊來實現。6本報告站在金融科技架構團隊的視角，重點從上述金融級

11、特點的“（1）高可用性與災難恢復”和“（2）高性能與低延遲”的角度，研究單元化架構的設計原理和應用落地。2.單元化2.單元化單元是指一個期望能完成所有業務操作的自包含集合，在這個集合中包含了所有業務所需的所有服務，以及分配給這個單元的數據。單元化架構就是把單元作為部署的基本單位，在所有機房中部署數個單元，每個機房里可部署多個單元，任意一個單元，都部署了系統所需的所有應用，數據則是全量數據按照某種維度劃分后的一部分。單元化架構的價值，是通過分布式原理拆分應用和拆分數據的基礎上，重點解決以下問題：1）單機房數據庫連接數及性能上限，制約了業務的擴展速度。2）頻繁跨機房訪問，網絡延時累積過大，降低了用

12、戶體驗。3）通過將應用與數據的訪問拆分在多個單元內閉環管理，可為多地多活架構提供基礎技術支持。單元化架構包含的通用術語見表 1。7表 1 通用術語表術語術語描述全局單元全局部署單元 GDU（Global Deployment Unit），簡稱全局單元，包含多地多中心共用的功能服務、數據以及該數據的管理服務。通常包含那些無法按照單元路由要素進行拆分的服務和數據。標準單元標準部署單元 SDU（Standard Deployment Unit），簡稱標準單元，將一部分計算資源和一部分數據資源進行邏輯上的綁定，來形成標準化的業務處理單元。SDU 默認按照特定維度拆分，單客戶交易流程實現單元內閉環處理。

13、跨客戶交易流程可能會存在一定比例的跨單元協同處理。單 元 路 由規則一組定義了如何將請求路由到特定單元上的規則。在本報告中，如將客戶號 00-01 分組的交易流量路由到標準單元 01 中，是一條路由規則，將客戶號 02-03 分組的交易流量路由到標準單元 02 中，是另外一條路由規則。單 元 路 由要素指用于確定路由規則的具體因素或條件。如本報告中，客戶號、賬號、卡號、存折號、手機號、身份證號都可以作為直接或間接的路由要素。（二）技術架構發展歷程（二）技術架構發展歷程研究一種技術的價值，首先要了解該技術的發展歷史。為了描述單元化架構的演變過程，本節結合 IT 領域的發展歷史，介紹從單體架構開始

14、，經歷了集中式架構、分布式架構等技術架構升級后，如何發展出單元化架構。81.單體部署架構1.單體部署架構集中式單體架構，程序和數據庫都在一臺服務器上面。大型金融機構的核心系統，曾經的典型運行方式就是在大型機或小型機上，主要基于 Cobol 語言開發。由于主機的高成本，每年都要花費大量資金購買 MIPS（主機算力）來應對不斷上升的業務量，然而對于這類架構而言，垂直擴展方式的經濟成本、管理成本是很高的，同時面臨供應鏈高危風險。單體架構示意見圖 1。圖 1 單體部署架構2.應用與數據分離部署架構2.應用與數據分離部署架構集中式架構在業務高峰時，由于程序和數據庫部署在一臺服務器上很容易就出現資源爭搶問

15、題，第一步就是把程序和數據庫分開，將數據庫獨立部署。應用與數據分離架構見圖 2。圖 2 應用與數據分離部署架構93.應用集群化部署架構3.應用集群化部署架構隨著業務量的增大，下一個問題便是應用側的瓶頸。這塊除了應用程序內部的性能調優外，從架構層面可以采用集群化部署模式，將大量的業務流量通過負載均衡服務來分流到多臺應用服務器上處理。常見的負載均衡有 F5，Nginx。這個階段的架構已經可以具備一定的橫向擴容能力，需要注意的是應用需要實現“無狀態”化，避免有狀態數據存在本地。應用集群化部署架構見圖 3。圖 3 應用集群化部署架構4.讀寫分離部署架構4.讀寫分離部署架構當應用側可以實現橫向擴容之后，

16、逐漸對服務器垂直擴容的需求開始減少，因為垂直擴容的邊際成本很高，收益卻越來越小，大家更愿意通過橫向擴容標準服務器來應對高并發。隨著應用層實現橫向擴容后，當業務進入到下一個階段，壓力又會回到數據庫這邊。應用橫向擴容，而數據庫還是單體。這個時候就需要分析當前系統的讀寫比。大多數系統的讀寫交易比是 8:2，讀多寫10少的場景可以考慮使用讀寫分離模式。開啟數據庫的主從復制能力，并將寫交易路由到主庫，讀交易路由到從庫。讀寫分離架構見圖 4。圖 4 讀寫分離部署架構可以設置多個從庫來負載相對較多的讀交易，主庫與從庫間通過數據庫的數據復制能力來保證一致性。復制模式包括同步復制和異步復制。同步模式會損耗一定交

17、易性能，因為需要等到多個從庫請求落盤才會反饋主庫，對性能敏感的寫場景需要考慮業務對時效性的容忍度。而異步復制會存在一定的延時，同樣讀交易也需要考慮業務對數據一致性的容忍度。5.NOSQL 部署架構5.NOSQL 部署架構在能承接當前業務量的情況下，從優化角度引入 Redis、MongoDB 等 NoSQL 中間件。Redis 具備很高的讀寫 QPS，可以有效提升系統整體性能，在秒殺、熱點數據查詢、數據緩存場景中11運用廣泛。MongoDB 具備靈活的文檔存儲能力，在存儲對象，非關系型數據，地理數據等非強事務類場景下具備獨特優勢。NOSQL部署架構見圖 5。圖 5 NOSQL 部署架構6.分布式

18、文件系統部署架構6.分布式文件系統部署架構隨著業務的發展，文件讀寫的場景越來越多，傳統的本地文件讀寫或 FTP 方式已無法滿足業務的快速發展，通過引入分布式文件服務，實現了文件的并行處理和高速訪問。分布式系統部署架構見圖 6。12圖 6 分布式系統部署架構7.數據垂直切分部署架構7.數據垂直切分部署架構隨著業務的持續增長，主庫已經難以支撐所有的寫請求，這個階段優先需要做的是數據庫的垂直切分。即按領域把“賬戶數據”“用戶數據”拆到不同的數據庫中，這樣寫交易可以按照業務需求分流到不同的庫上，從而降低集中庫的壓力。需要注意的是這種拆分可能會引起分布式事務產生。如果存在一次事務跨了多個業務域的數據庫，

19、那就需要考慮多個數據庫間的數據一致性問題。該問題可以借助分布式數據庫的產品能力解決，或在應用層引入分布式事務框架解決，也可以通過消息中間件實現最終一致性，取決于不同場景下的業務接受度，數據垂直切分部署架構見圖 7。13圖 7 數據垂直切分部署架構8.應用垂直切分部署架構8.應用垂直切分部署架構當數據已經按領域切分而應用還是集中式部署時，每個應用可能需要連到多個庫上才能完成業務處理，這顯然是不合理的。數據庫的連接數和應用后期的擴容都會存在問題。通常情況下數據拆分后會同步考慮應用拆分。應用垂直切分部署架構見圖 8。圖 8 應用垂直切分部署架構到這個階段，最初的系統已經被按照不同技術方向，從設計到落

20、地都實現了應用部署方式與數據部署方式的解耦?；谶@種14架構已經可以初步支持不同模塊的獨立迭代與演進，已接近“微服務”架構。9.SOA 與微服務部署機構9.SOA 與微服務部署機構在前面的架構中，當把一個大型應用拆分為多個子應用時，隨之而來的問題是這幾個子應用間的高頻通訊問題。在微服務架構之前，普遍采用消息總線來做多個系統間的“銜接”。它就像一根通道，集成不同的應用、不同的協議，承擔消息解釋與路由的作用，實現互聯互通，稱之為 SOA 部署架構屬于早期分布式的經典架構。SOA 部署架構見圖 9。圖 9 SOA 部署架構傳統 SOA 架構，雖然解決了服務間的調用和治理，但是引入了一個企業服務總線

21、ESB，而企業服務總線 ESB 是一個中心化的應用，所有業務應用都連接它，存在兩方面主要的問題，一是隨著接入系統的數量不斷增加，總線 ESB 的性能瓶頸以及系統間調用性能下降；二是企業服務總線 ESB 出現故障后，將會使所有的應用出現問題。為了解決這個問題，微服務架構出現了，提供注冊中心、配置中心來簡化系統間調用鏈路并提升性能。微服務部署架構見圖 10。15圖 10 微服務部署架構微服務架構和 SOA 架構都是面向服務的架構設計。微服務更強調了去中心化思想，而 ESB 作為全行的消息總線在一定程度上是形成了單點和瓶頸。微服務架構去掉了 ESB，通過注冊中心來實現服務發現能力。以發布和訂閱服務目

22、錄的方式，讓應用間通過服務目錄來實現點對點的直連通訊，使得通訊的鏈路更短更高效。10.數據水平切分部署架構10.數據水平切分部署架構在系統按領域切分之后，如果某一領域內的業務量依然大到主庫無法承載。那么接下去就需要在垂直拆分的數據庫上再進行一次水平拆分。水平拆分可以將落到一臺主庫的壓力分攤到多個分庫上。這個階段設計時需要注意數據路由和擴容場景：（1）數據一旦被按照一個維度進行了分庫，那應用在請求時就需要在請求中帶上該維度的值，進行路由判斷，識別該數據16在哪個分庫上；（2）其次是擴容問題，假如當前為 10 個分庫，一開始的路由算法為 hash（客戶號）%10，后面擴容到 12 個分庫，那計算規

23、則就要變成 hash（客戶號）%12。這樣，所有分庫上的數據都需要按照新的路由規則重新計算并進行數據遷移，這個過程稱為“數據重分布”，成本和代價都很高。建議在設計階段提前與各方約定好路由規則和擴容策略。數據水平切分部署架構見圖 11。圖 11 數據水平切分部署架構11.單元化部署架構11.單元化部署架構應用系統完成水平拆分后，系統的水平擴展能力和容量已經可以滿足大部分金融機構的需求。由于金融行業的特殊性，IT系統對高性能、高可用、穩定性要求高，兩地三中心是金融行業的標準架構（如圖 12）。即：同城雙活，異地容災，一共三個17數據中心。同城雙活架構，指一個系統分布在同城的兩個數據中心，兩邊都能同

24、時接收業務請求并進行處理，流量通過全局負載均衡均勻地分發到同城 A、B 兩個機房。異地容災架構，指當同城雙中心都出現故障后，將數據和應用的主本切換到異地，由異地數據中心繼續提供金融服務。圖 12 兩地三中心部署架構圖 12 所示中，金融服務的流量從同城雙中心進入，到微服務網關層時，網關通過注冊中心獲取目標服務的可用地址，基于最佳路由策略發起點對點調用。應用在處理數據時，只有數據庫主本可處理讀和寫的請求，備份的副本只能處理讀請求，所以同城中心的應用需要跨中心訪問到另一個中心進行寫數據操作?；诖?，應用程序跨機房寫數據庫，在微服務場景下就產生了網絡時延累加過高以及數據庫連接數不足的問題。18從數據

25、主本和副本的角度去看分布式數據庫，都是主本可讀可寫，所有副本都只讀，這是所有數據庫中主本和副本的基本內核。從架構的優化上，可以指定一些庫的主本在 A 中心，一些庫的主本在 B 中心，這些庫都隸屬于一個分布式數據庫實例，不同應用訪問不同的主本，整體上看在分布式數據庫就在 AB 兩個中心同時提供服務，以此實現“整體上的雙活”。在圖 12 的案例中，賬務庫和公共庫的主本在 A 中心，而歷史庫的主本在 B 中心，對應用是一個分布式數據庫實例。圖 12 是使用微服務框架和分布式數據庫來實現兩地三中心的通用架構，但在極端情況下，這類架構可能會存在兩個跨機房訪問的情況：應用服務之間的跨機房橫向流量。應用與數

26、據庫之間的跨機房縱向流量。同城內多個機房間的網絡情況在大部分情況下穩定性和性能都是有保障的，50 公里的延時一般都在 1ms 以下。這對于跨中心訪問來說問題并不大，足以應對大部分金融機構的要求。一般城商行的日常 TPS 可能就只有幾十，峰值可能也就幾百到一千左右。橫向流量對網絡帶寬壓力并不大，抖動和時延對業務的影響也較小?？蓪τ谟脩魯盗魁嫶蟮拇笾行豌y行機構，跨機房流量的問題則會被數倍放大，這些銀行的日常 TPS 大多上千，活動峰值可能接近上萬。每一筆交易進入，核心平均需要進行 5080次的數據庫操作，所以在應用到數據庫這一層橫向流量會被放大19數倍。其次，在應用層微服務之間的訪問也會出現橫向跨

27、機房流量，因為常見的微服務體系中沒有提供就近訪問能力，需要自行在負載策略中增加規則來實現同中心優先調用，否則就會有流量被調度到另一個中心，而每次服務間的調用都會面臨反復來回調度的情況，這部分消耗應進行優化。因此，在大型金融系統進行分布式轉型時，需考慮其系統內部在實現微服務化和數據分布式化之后，大量流量在兩個機房間穿梭的問題，這對基礎設施的穩定性及成本要求是很高的。單元化架構的出現也正因如此，它可以很好地減少數據中心間的橫向流量，進一步提升微服務架構的性能與穩定性。單元化部署架構見圖 13。圖 13 單元化部署架構單元化架構遵循分布式系統“分而治之”的設計思想，我們可以將一個系統分為多個“標準處

28、理單元”。每個處理單元由一組計20算資源與一部分數據資源組成。每個處理單元的計算容量保持基本一致。如圖 13 所示，采用這種模式，我們可以把一個大型系統拆分為若干個單元。單元內實現閉環處理，單元之間互不影響，減少了故障半徑的同時，還大大降低了無效的橫向流量，提升了性能與穩定性。三、金融級單元化架構設計三、金融級單元化架構設計本章從技術架構的角度，分別介紹單元化架構中涉及到數據庫、云平臺和應用所需關注的設計要素。（一）單元化適用場景（一）單元化適用場景第二章在介紹金融行業單元化架構的演進時提到應用系統采用微服務架構做完水平拆分后，系統的水平擴展能力和容量已經可以滿足大部分的金融機構的需求，什么情

29、況下可能需要使用單元化架構呢？單元化架構通過合理的數據切分，把計算與數據進行綁定處理，來控制業務流量單元內閉環，解決了大規模業務并發場景下的跨中心流量訪問問題，提供了多地多活架構的基礎條件。但是由于單元的拆分，應用系統會更復雜，應用系統需要考慮服務的拆分（一個交易涉及多個客戶時必須進行服務拆分）、SQL 語句的調整、批量交易的改造（涉及文件的拆分與合并），因此當應用包含一個及以上的下述需求時可考慮采用單元化架構：1.數據體量足夠大，目標有效客戶數大于 1000 萬的客戶。212.應用是面向客戶的，要求同城雙活，極致的性能和穩定性且數據訪問頻率較高。3.未來考慮異地多活的架構，單元化架構是異地多

30、活的關鍵技術基礎。4.在灰度場景中，基于數據隔離的需求，金融行業為了控制風險，在新業務投產時，通常會先進行灰度測試，通過灰度單元的設計，可以控制灰度的范圍，將灰度版本應用在有限的客戶范圍內。（二）單元化架構設計原則（二）單元化架構設計原則單元化架構最核心的設計理念是“分而治之”，將重要高并發的業務流量分發在數個單元內閉環處理，盡可能減少跨地域、跨機房、跨單元的網絡訪問，以實現高效高可靠的業務處理能力。1.整體設計原則1.整體設計原則單元化架構設計原則主要圍繞“拆分流量”和“閉環處理”展開，必須滿足如下要點：1）業務流量可按特定規則進行分流后歸屬到不同單元進行處理。如銀行的交易類流量可以根據全局

31、唯一的客戶號進行分單元處理。2）單元內的業務處理系統是完整的，盡可能在本單元內完成對業務流量的處理。如銀行的交易請求所需的機構、客戶、賬戶等關聯系統在每個單元都進行了完整部署，并具備同樣的功能。3）單元內的業務處理系統面向邏輯功能設計，每個單元都22可以獨立地運行，而不是面向物理部署環境設計。如每個單元既可以在 A 機房運行，也可以在 B 機房運行，多個單元既可以在同一個機房運行，也可以分別在不同機房運行。2.設計要點2.設計要點為方便讀者更容易理解單元化架構中關于“拆分數據”“拆分應用”和“拆分單元”的關系，以下面的生活示例進行輔助說明。物流公司在送貨上門前，會對包裹、車輛和路線進行安排。1

32、、按照包裹收貨人所在區域進行了分類，可理解為拆分數據。2、按照包裹體積大小進行分類使用不同車型進行運輸，可理解為拆分應用。3、按包裹目的地確定送貨優選路線和備選路線，可理解為拆分單元。單元化架構的設計要點是圍繞業務場景來開展的，通過梳理業務類型和業務鏈路，明確數據、應用和單元各自的拆分關鍵參考原則如下。1）拆分數據1）拆分數據(1)為什么要拆分數據？拆分數據要回答的是數據如何分類存儲和減少跨機房訪問的問題，其工作原理類似上述例子中將快遞包裹分類。(2)如何拆分數據？金融行業有個重要的業務特點，其業務流程大部分是圍繞“交易”進行，存款、貸款、匯款等交易行為都有一個交易發起23方，這個交易發起方在

33、全局有一個唯一編號作為身份標識，為方便描述，本報告將這個唯一編號簡稱為客戶號。拆分數據的前提是確定數據分片規則。研究發現，目前國內進行單元化架構設計的項目，以互聯網金融機構和銀行機構為主，數據分片規則是通過對“客戶號”按照某種的計算規則（如計算機編程語言中的取模運算）將所有的客戶分為數個分片中，已成為業界常見方法。取模運算進行數據分片作為示例見表 2。表 2 數據分片示例表拆分粒度拆分后數據分片數量客戶號取模結果客戶號所歸屬分片客戶號%101000112233445566778899(3)注意事項拆分數據的維度，應選擇未來業務量增長、科技基礎設施容量擴容的主因維度，同時所選維度應能夠將全量數據

34、進行相對平均劃分到多個分片。拆分數據到數個分片，目的是提高系統并發能力，因此24主要適用于高并發場景下標準單元 SDU 中的應用來處理。對于低頻業務或不滿足數據拆分規則的業務，則數據采用傳統的主備架構模式即可，在全局單元 GDU 中進行存儲。標準單元 SDU 中所有數據按照統一粒度進行拆分。建議采用拆分數據的規則在企業級范圍生效，即所有系統采用相同的規則進行拆分或不拆分，避免每個系統選擇不同的拆分規則（如存款系統采用客戶號進行拆分，貸款系統采用流水號進行拆分，就是典型的單元化數據拆分規則混亂），否則會導致數據管理混亂和路由規則混亂。數據拆分需匹配支持單元化的數據庫產品，確保數據在多個單元內有相

35、應的數據副本，以便保障單元切換時的數據完整性。2）拆分應用2）拆分應用（1）為什么要拆分應用？拆分應用要回答的是分別用什么程序代碼來處理標準單元和全局單元的數據，其工作原理類似上述例子中不同的貨物使用不同的運輸車。（2）如何拆分應用？單元化架構的價值體現在重要高并發的業務場景，同時如果這些重要高并發業務流量又能夠滿足拆分數據的要求，那么處理這些業務流量的請求需要單獨拆分出來部署在標準單元 SDU 中以便實現橫向擴展性，而不滿足拆分數據要求的應用或普通低并25發的應用則只需部署在全局單元 GDU 中以簡化管理成本。研究發現，目前國內進行單元化架構設計的金融類項目，主要是考慮將存款、貸款、匯款等重

36、要高并發且能滿足按照客戶編號拆分數據的應用系統部署在標準單元SDU中，其他部署在全局單元GDU中，如圖 14 所示。圖 14 全局單元與標準單元的應用部署示意圖（3）劃分應用系統至全局單元的原則數據不能按照指定維度進行拆分。如標準單元的劃分維度是按照客戶號，而運維類系統管理對象是基礎設施設備（服務器、交換機等）則無法按照客戶號進行拆分數據；非對客業務的主鏈路系統。如辦公類、內部管理類系統等，應劃分到全局單元；交易類較小的應用系統，可暫時部署在全局單元 GDU，26待業務量增長明顯且性能出現瓶頸，再考慮到標準單元 SDU；提供全局查詢服務的系統。（4）劃分應用系統至標準單元的原則數據可按照指定維

37、度（如客戶號）進行拆分，且處于關鍵業務鏈路上；系統自身數據已進行拆分設計并且訂閱大量的標準單元消息；系統自身對全局單元中系統的服務依賴較少。僅操作本單元中系統的數據，如其他單元的外部請求，需轉發至本單元內處理完成；發現不屬于本單元的業務（數據），需通過服務的方式轉到其他單元，典型的是同行轉賬涉及 2 個賬戶在 2 個單元的情況，如果有需要把跨單元數據訪問，改為服務化訪問，而不是直連跨單元的數據庫訪問。內部流量如調度任務也需本單元內完成任務加載和業務處理，只取本單元負責的用戶分片數據。（5）注意事項一個應用系統中相同的微服務不允許同時部署在全局單元和標準單元。對全局單元和業務單元的服務都有大量的

38、依賴，比如銀行核心系統的賬戶中心，應當拆分成微服務，其中能夠按客戶號分片的微服務部署在業務單元，無法按客戶號分片的微服務（如27配置數據）部署在全局單元。標準單元內的多個系統之間在接口調用時，需在接口或報文中傳遞數據拆分維度所依賴的字段（如客戶號）或能轉換成拆分維度的路由映射要素。3）拆分單元3）拆分單元（1）為什么要拆分單元？拆分單元要回答的選哪個單元的應用來處理數據，其工作原理類似上述例子中運輸車走哪條送貨路線。（2）如何拆分單元？研究發現，拆分數據到拆分單元是遞進關系，設置單元數量的常見方式是設置為數據分片總數的倍數分之一，即一個單元可以處理一個或數個數據分片。以下示例僅供參考，實際情況

39、可根據用戶數量、業務特征及機房等基礎設施進行調整，如表 3。表 3 數據分片參考表拆分粒度拆分后數據分片數量單元的數量每個單元數包含數據分片數（1:N）客戶號%1010101:151:221:5客戶號%1616161:181:241:4客戶號%100100201:5101:1041:2528（3）注意事項考慮到金融行業在滿足業務連續性要求時，已具備兩個及以上的生產機房如兩地三中心是常見的技術架構，因此建議單元的數量是機房數量的整數倍，避免每個機房僅部署一個單元，否則單元化的效果打折扣，退化成了常規的同城雙活模式，同時又增加了因引入單元化的管理成本?？紤]到國內金融行業主流的兩地三中心架構中，其底

40、座為同城雙活機房+異地災備機房，實際承載生產業務流量為同城雙機房，即機房的數量為 2 個。為了保證引入單元化架構后，保障流量在雙機房負載均衡，建議單元的數量為 2 的整數倍。建議數據分片均勻分布在多個單元內，即每個單元包含多個分片且單元間的分片數據盡量保持一致。綜上，機房、單元、應用和數據分片的映射關系見圖 15。圖 15 數據分片與單元的映射關系（三）數據庫單元化架構設計（三）數據庫單元化架構設計數據庫單元化負責數據分單元存儲和訪問，可簡要類比為前29述例子中快遞包裹的分類管理。數據庫單元化架構設計需重點考慮四個方面，包括：數據庫集群劃分、數據路由工具、數據同步工具、數據庫容災與備份。1.數

41、據庫集群劃分1.數據庫集群劃分在金融行業對業務連續性及系統性能有較高的要求，數據庫作為應用系統中最重要的基礎設施，研究發現，數據庫可通過物理隔離和邏輯隔離來劃分不同集群，以滿足不同應用系統的單元化數據存儲和訪問的需求。因此數據庫集群劃分需重點關注三個方面，一是數據庫產品需在技術上支持物理隔離和邏輯隔離部署多套集群；二是分別規劃全局單元和標準單元的集群數量以及每個集群包含的分布式副本數；三是規劃每個集群上承載的系統，明確什么類別的系統使用獨立集群進行物理隔離，什么類別的系統使用共享集群進行邏輯隔離，這取決于成本和風險之間的平衡；2.數據路由工具2.數據路由工具數據路由工具主要作用是準確高效將 S

42、QL 請求分發到目標的單元內，并盡量減少跨單元跨級的網絡訪問，提升整體性能。規劃數據路由工具需重點關注四個方面，一是支持識別 SQL 中路由要素（如客戶號）或單元信息，并將 SQL 轉發至全局單元或標準單元所對應的數據庫中，優先實現本機房訪問的最短網絡路徑；二是高可用及負載均衡，數據路由工具應具備多節點高可用部署架構，并對外提供負載均衡 VIP 供應用側訪問，由于數據庫穩定性的重要級別高，需重點關注實現負載均衡的設備性能、功能及30穩定性；三是故障檢測與切換，具備對各單元數據庫狀態的故障檢測，當某個單元出現故障后，能夠及時感知并采取相應措施，如重試、切換路徑到災備單元等；四是性能考量，數據路由

43、工具的性能會影響訪問數據庫的效率，因此關注 SQL 解析、路由決策及與后端數據庫的通訊效率。3.數據同步工具3.數據同步工具數據同步工具主要作用是處理從多個標準單元 SDU 向匯聚庫等外部數據庫進行同步并聚合數據的場景，以滿足業務上聚合查詢的需求。規劃數據同步工具需重點關注五個方面，一是多對一的聚合能力，將多個單元不同庫不同表的源數據聚合到同一個庫同一個表；二是多數據源支持，即支持多種類型的數據庫，以滿足不同業務需求；三是數據一致性能力，保證數據在傳輸過程中的完整性和準確性，一致性分為實時一致性和最終一致性；四是容錯性與恢復能力，應具備自動重試、斷點續傳等容錯能力；五是可擴展性，隨著業務增長帶

44、來數據量增長的同時，工具支持水平擴展來提升性能上限。4.4.數據庫容災與備份數據庫容災與備份數據庫容災的主要作用是根據監管要求、金融行業技術規范以及金融機構自身的業務連續性要求，通過數據庫的容災能力來滿足業務數據容災的要求。在規劃數據庫容災能力時，需重點關注六個方面，一是需支持以單元為粒度的數據復制及容災切換能力，從而控制爆炸半徑及最小化處理范圍；二是需支持跨機房和31跨地域的容災能力，即同城容災和異地容災；三是自動切換能力，單元化架構下的數據庫通常需支持分布式多節點的部署方式，當部分節點故障時，數據庫內部自身實現自動切換，減少人工干預和提升 RTO；四是支持多種數據同步方式，包括實時同步和異

45、步同步，以滿足同城容災和異地容災不同的 RPO 要求；五是備份恢復，通過數據庫自身備份機制或第三方備份工具，支持定期和手工觸發數據庫的備份，以滿足異常場景下數據庫恢復及監管審計的需求；六是監控告警，除了數據庫自身提供完備的監控工具外，還需滿足金融機構運維要求，將監控告警、設備管理等信息對接到第三方的告警及相關運維平臺，實現統一化管理。（四）云平臺單元化架構設計（四）云平臺單元化架構設計云平臺單元化負責單元訪問路線的管理，可簡要類比為前述例子中快遞的送貨路線。為了準確高效分配好送貨路線，單元化架構設計需重點考慮六個方面，包括：單元化管理、微服務平臺、消息隊列、分布式事務、任務調度、容災管理。研究

46、發現，為獲得較高的兼容性，通過云平臺集成化的方式提供單元化架構所需的中間件等技術組件，是業界常見的方案。1.單元化管理1.單元化管理通過云平臺單元化管理相關能力，提供單元管理、單元路由規則、單元網關、單元容災、單元灰度等功能。1）單元管理1）單元管理單元管理的核心功能需求是提供單元信息的配置，包括定義32單元數量、單元類型（標準單元、同城單元和全局單元等）。通過單元規劃，可直觀地看到包含全局單元的數量和標準單元的數量，每個單元所部署和運行的機房信息等。2）單元路由規則2）單元路由規則單元化路由規則管理的核心功能需求包含兩方面，一是支持配置單元化路由，如業務請求根據客戶號進行取模運算后，得到不同

47、單元的路由結果；二是支持動態推送配置更新，當發生容災切換或單元數量調整時，需將最新的路由規則自動化推送至所有單元立即生效。3）單元網關3）單元網關單元化網關主要用于將客戶端訪問流量根據全局統一的單元化路由規則分發到目標單元中，實現流量動態調撥。核心功能需求包括三個方面，一是接收并存儲單元化管理下發的單元化規則，根據請求標簽識別單元信息（單元類型、單元 ID），將請求正確路由到指定的單元，支持同機房轉發、跨機房同城轉發和跨機房異地轉發；二是容災切換時，接收變更后的單元化規則，將流量轉發到對應的容災單元?；厍袝r，將流量轉發回恢復后的原始單元；三是單元灰度時，按一定流量比例/特定標簽，將符合特征的流

48、量轉發到對應的灰度單元。4）單元容災4）單元容災單元容災的核心功能需求是支持配置同城/異地災備單元，實現單元的容災切換和恢復后回切。研究發現，目前市面上容災33切換分組有兩種實現方式，一是固定單元作為切換目標，即 A 單元故障后只能將對應分組流量切換至 B 單元；二是可變單元作為切換目標，即 A 單元故障后可將對應分組流量切換至任意單元。兩種實現方式取決于基礎設施的準備情況、供應商技術方案及容災管理需求，具體項目具體分析。5）單元灰度5）單元灰度單元灰度用于在生產環境中構建一個灰度的單元以支持應用系統灰度發布。單元灰度的核心功能需求是應支持灰度單元的創建和灰度路由規則管理，以便區分正常業務單元

49、和灰度單元的流量。同時需要重點關注兩類信息，一是灰度方式可以分為應用灰度和數據灰度。二是在流量請求中需支持灰度標記，以實現將流量分流到正常單元還是灰度單元。研究得知，灰度數據也屬于生產數據，對于同一用戶的數據而言，要么在正常業務單元，要么在灰度單元，因此如果規劃數據灰度，將涉及隨著人員變更引起在正常業務單元和灰度單元之間的數據遷移，需要應用系統、數據庫聯合支持數據跨單元遷移，當涉及遷移的數據表數量較多時，在金融行業嚴格的業務連續性要求的背景下，開展數據灰度的挑戰是非常大的。2.微服務平臺2.微服務平臺微服務平臺，包括注冊中心和配置中心，主要用于提供服務注冊和發現、配置統一和更新的功能，通過提供

50、本單元服務發現和跨單元服務發現的能力，實現流量優先本單元調用。在單元化34架構中，對于微服務平臺提出的核心功能需求包括兩點，一是服務實例注冊時自動標記單元信息，以確定每個服務實例分別運行在什么單元內；二是最短路徑調度能力，在進行微服務調用時，如果目標服務在本單元中存在正常實例，則優先調用單元中微服務，如果目標服務在本單元中沒有正常的目標服務，則調用跨單元的微服務。3.消息隊列3.消息隊列在單元化架構中，消息隊列負責幫助生產者將消息投遞到目標的單元供消費者進行消費，核心的功能需求包括三點，一是在生產端支持對消息設置目標單元；二是消息傳播過程確保消息能發送到同單元和跨單元，覆蓋全局單元和標準單元等

51、所有單元類型；三是在消費端支持根據單元信息過濾消息并進行消費。4.分布式事務4.分布式事務在單元化架構中，分布式事務的作用是為了確保交易流程在跨服務跨單元等分布式場景下能夠正確地完成，并在出現故障時能夠保證數據的一致性、隔離性、持久性和原子性。為了支持這些特性，分布式事務通常需要實現以下五個關鍵機制：一是兩階段提交（Two-Phase Commit,2PC）：這是一種經典的分布式事務協議，用于確保所有參與者節點都同意提交或回滾事務；二是補償事務（Compensating Transactions）：當主事務失敗時，可以通過執行一系列補償操作來撤銷已經完成的部分工作；三是分布式事務協調器：負責管

52、理并協調分布式環境中多個參與者的35事務，確保所有參與者達成一致；四是最終一致性（EventualConsistency）：某些情況下，可以采用最終一致性模型，在短時間內允許數據存在不一致狀態，然后通過異步消息傳遞或其他機制最終達到一致；五是事務日志（Transaction Logging）：記錄事務的執行情況，用于恢復和審計。在實際應用中，選擇什么機制取決于具體的業務場景和技術約束。研究發現，在金融行業的系統中，分布式事務通常和業務場景有較為緊密的關系，需要在通用的分布式事務能力基礎上，加上特定的業務邏輯，具體表現為不同的系統的供應商可能已自帶一套分布式事務能力，可根據實際情況考慮是否采用統

53、一的機制。5.任務調度5.任務調度在單元化架構中，任務調度的作用是將定期觸發的任務調度到目標單元內執行，通常需要具備幾個方面的能力，一是負載均衡，支持配置任務的執行單元，確保各個單元工作負載相對均衡，避免過載或空閑的情況；二是容錯與恢復，在檢測到某個單元故障時，能夠重新調度任務到健康的單元上繼續執行，保證系統持續運行；三是依賴管理，管理不同任務之間的依賴關系，確保前置任務完成后才能啟動后續任務；四是批處理與實時處理，支持不同類型的任務調度，比如周期性的批量處理任務以及實時數據處理任務；五是優先級控制，根據任務的重要性或緊急程度賦予不同的優先級，優先執行重要的任務；六是支持常見的編程語言，如 J

54、ava 任務、Shell 任務、Python 任務以及外部任務的調度36執行。（五）應用單元化架構設計（五）應用單元化架構設計金融行業在進行單元化架構設計時，通常先需根據機構的業務特點及未來 5 年的業務增長目標，評估出機構的數據量，確定機構的數據拆分維度和分片的數量，單元數量，部署的架構。1.應用單元化架構可行性評估1.應用單元化架構可行性評估單元化架構雖然具備很多優點，但并不是所有應用系統都適合進行數據拆分和應用拆分，需要根據應用系統的特點進行評估，具體評估方法主要有以下幾點：1)系統類型：分析系統的業務形態，原則上管理類或分析類系統不適合單元化改造，只有面向客戶類的應用系統才需要考慮單元

55、化架構，因為管理類或分析類系統的數據并不好拆分，且對系統的高可用和性能要求也不高，而通常面向客戶類的應用系統通常對高可用和性能要求較高。2)數據分片：為方便金融行業的單元化管理，通常單元的數量及數據分片會采用統一標準，判斷一個系統能否單元化改造，需分析系統能否按統一的維度進行切分數據。3)路由映射：應用系統是否能夠建立從交易要素轉換成數據拆分維度的映射關系，或者請求方能否按照要求改造上送路由要素，只有具備這樣的條件，交易入口才能將請求根據路由要素計算出該交易對應客戶所在的數據分片，從而將交易路由到對應的單元中。374)功能改造：功能能否按單元進行改造，如果出現跨單元的交易，能否將功能拆分開。比

56、如在銀行業務中，通常會以客戶號作為數據拆分維度，銀行的高頻交易轉賬，有轉入客戶和轉出客戶，當兩個客戶所在的單元不同時，這時會出現跨單元的交易，該功能需拆分為轉入服務和轉出服務，轉入服務和轉出服務分別在不同的單元執行。2.應用單元化改造策略2.應用單元化改造策略一個應用系統確定了采用單元化架構后，可參考如下策略及步驟進行單元化改造：1)架構規劃：對應用系統進行業務模塊拆分，將參數類、后臺管理類、非客戶類業務模塊規劃到全局單元 GDU，面向客戶的模塊規劃到標準單元 SDU。2)數據庫表拆分及 SQL 修改：按照應用架構規劃分析應用數據庫表，切分全局數據庫表（部署在全局單元 GDU）和單元化應用數據

57、庫表（部署在標準單元 SDU），原則上需將單元化應用的數據庫表加上行內統一的分片鍵值，應用的 SQL 語句也需要做相應的修改，SQL 語句需加上分片鍵值，以便分布式數據庫能按照設計好的分片鍵進行數據層的路由。3)路由要素設計：分析應用交易場景，識別出應用系統中可以作為轉換成核心客戶號的映射要素，建立映射關系。4)應用系統功能調整：一是聯機交易功能，將涉及到跨單元的交易做微服務的拆分。二是批量交易的改造，單元化后批量38交易涉及按照單元進行數據拆分與合并。四、金融級單元化架構應用四、金融級單元化架構應用場景單元化架構推廣至四川銀行多個業務系統的過程中，數據拆分、數據聚合、單元化路由轉發、單元高可

58、用等場景是業務系統在開發、測試、運維時最關注的場景。本章重點圍繞如上場景進行總結。（一）數據拆分場景1.數據拆分維度（一）數據拆分場景1.數據拆分維度在業界通常有按客戶號進行 hash 分片、客戶號 Range/List模式、和機構或省市維度分片三種拆分維度。三種拆封維度的差異性見表 4。表 4 數據分片常見實現方法方案分布式事務概率數據分布訪問壓力分布擴容難易度按客戶號進行hash分片低，金融行業 大 部 分交 易 都 在一 個 客 戶內閉環。均勻，當客戶號采用連續的數字生成時，數據分布是均勻的。均勻，同樣，當客戶號采用連續的數字生成時，數據分布是均勻的。高，擴容時數據需要重新進行hash

59、計算，涉及數據遷移工作，因此擴容難度較高?？?戶 號Range/List 模式低，金融行業 大 部 分交 易 都 在一 個 客 戶內閉環?？傮w均勻，每個單元的數據量是固定的，只有最后一個單元數據可能均勻，同樣，當客戶號采用連續的數字生成時，數據分布是均勻的。低，每個單元的數據量是固定的，每次都往最后一個單元新增數據，當數據達到固定的數39較少量后，就新增一個單元機構或省市維度分片低，金融行業 大 部 分交 易 都 在一 個 客 戶內閉環。不均勻，每個機構或者省市的用戶體量不同。不均勻，易出現熱點。取決于擴容策略及每個機構或者省市下面的數據存儲策略。綜上，所有數據拆分維度應優先考慮的是盡量避免跨

60、單元分布式事務的發生，獲得最佳性能和最低擴展難度。課題組研發得知，金融場景多以客戶場景居多，以客戶號分片是常見的方式。2.數據拆分實現策略2.數據拆分實現策略對數據拆分的實現策略通常有兩種，一是借助數據庫廠商的分布式數據庫來實現數據的拆分及分片；二是在應用層通過數據庫分庫分表組件實現數據拆分及分片，兩種方式的特點見表 5。表 5 數據分片策略策略優點缺點策略 1-分布式數據庫實現分片可利用分布式數據庫能力實現擴容，對應用層透明，簡化應用。擴容策略有限，通常有HASH 和 LIST 方式。策略 2-數據訪問組件實現分片定制化能力強，路由策略豐富，與物理分片解耦，能有效適配單元化架構。需配合數據遷

61、移工具實現擴容。從金融行業的通用性角度，建議優先考慮策略 1-分布式數據庫實現分片，數據拆分模型和擴容均由數據庫產品提供，理由是對應用開發的入侵性較??；當應用開發團隊的技術能力較強、40需要定制化單元擴容需求且新開發建設系統時，可考慮策略 2-數據訪問組件實現分片，理由是定制化能力強，且與數據庫為弱依賴關系。（二）數據聚合查詢場景（二）數據聚合查詢場景單元化架構通過數據拆分后進行分片存儲和訪問，對于以單個客戶為對象的交易類流程，因單元內收斂原理最大限度降低了跨機房的網絡調用次數，有效提升了整體交易的性能水平。同時對于跨客戶的查詢場景就涉及到跨單元數據聚合查詢，如以機構為粒度的業績查詢及風險評估

62、、以全行客戶為粒度的財務報表分析及審查審計等多種場景。研究發現，實現數據聚合查詢的常見方式有兩種，一是先查詢再聚合，二是先聚合再查詢。方式一：先查詢再聚合主要原理為客戶端發起查詢請求時，由服務端的應用程序或數據庫訪問組件識別所涉及的單元信息，并到涉及的所有單元中查詢信息，并進行數據匯聚及加工后再返回給客戶端。方式二：先聚合再查詢主要原理為數據生成并寫入各單元數據庫時，將數據復制一份到專門的匯聚庫中，匯聚庫中包括了所有單元的數據，后續客戶端在發起查詢請求時，服務端的應用程序直接向聚合庫發起請求。具體實現還可分為由應用層復制數據到聚合庫、由數據同步工具從源庫中復制數據到聚合庫等兩種常見方式。41如

63、下是兩種方式簡要的優缺點對比，見表 6。表 6 數據聚合算法參考表方式優點缺點方式一：先查詢再聚合數據準確度高，查詢時為 最 新 數據。1、較高的網絡延遲及處理時間，查詢速度慢。2、異常處理機制復雜，如部分單元數據查詢失敗、超時等。3、可能導致數據庫及應用程序的內存使用率占用過高。方式二：先聚合再查詢查詢時響應速度快，直接向聚合庫查詢得到結果。1、如采用應用層聚合會對應用代碼有較大入侵性，影響交易性能和增加故障處理的復雜度，如源庫寫成功但復制至聚合庫失敗。2、如采用數據同步工具聚合，則數據實時性降低，可能較源庫的最新數據存在一定延遲，原因聚合過程為避免對源庫性能影響而采用異步復制方式，同時難以

64、實現復雜業務規則的聚合條件。（三）單元路由轉發場景（三）單元路由轉發場景研究發現，在金融行業中以客戶號為數據拆分的維度是常見方法?；诖?，本節圍繞客戶號研究單元化路由轉發的設計方法。1路由標記設計1路由標記設計在金融行業的業務場景中，客戶號是科技內部表示客戶身份42的唯一標識，對終端用戶及柜面是不可見的，因此從客戶端發起的請求的原始報文信息中，并不一定會包含客戶號，而是包含銀行卡號、手機號等信息。為了滿足單元化架構基于客戶號的路由需求，需要制定一套報文規范。對應的設計要求可參考如下方法。1）在報文規范中指定路由要素字段 A，用于標識單元化的路由要素，并建議采用 Key-Value 的方式表示，

65、示例見表 7。表 7 路由要素設計表類別Key值分隔符Value報文中的字符串客戶號01-12345678901-123456789銀行卡號02-234567890102-2345678901手機號03-1801234567803-18012345678其他04-3456789012根據類別按需擴展2）在報文規范中指定灰度規則字段 B，用于表示該請求是否進入灰度單元內。根據灰度單元的數量來設計該字段的枚舉值即可，如果只有一個灰度單元，則只需設置 TRUE 或 FALSE 接口，如果未考慮灰度單元，則報文中無需設計灰度單元標記。2.路由轉發設計2.路由轉發設計路由轉發的主要作用是解析報文中的路由

66、要素字段和灰度規則字段，轉換為單元號，并將請求轉發至對應單元中，主要工作原理如下。1）手機銀行、柜面、ATM 等終端設備的客戶端程序在發起交易請求時，在報文中填充路由要素字段 A 和灰度規則字段 B。2）設計一個全局路由服務，負責將報文中的路由要素字段43A 進行解析，主要能力是將銀行卡號、手機號等統一轉換為客戶號。由于客戶號與銀行卡號、手機號屬于業務屬性的映射關系，在不同銀行機構有較大區別，屬于定制化的場景，建議該服務由應用層實現以便管理和擴展。3）交易請求在接入層網關處，由云平臺的單元化管理服務調用全局路由服務，獲得客戶號后按照數據拆分規則，將客戶號轉換為單元號，轉換結果應包含單元類型（全

67、局單元或標準單元）以及單元編號，如 G01 表示全局 01 單元、S02 表示標準 02 單元。4）云平臺的單元化管理服務解析報文中的灰度規則字段 B，判斷該請求是否進入灰度單元，前提是灰度單元包含了全局灰度單元和標準灰度單元，并已完成相應的應用系統部署。5）云平臺的單元化管理服務負責將報文轉發到目標單元所在服務程序，該轉發過程在網絡上可能會涉及到跨單元、跨機房或跨地域的轉發。路由轉發流程見圖 16。圖 16 路由轉發流程示意圖44（四）單元高可用場景（四）單元高可用場景單元高可用重點關注以單元為粒度的故障場景，即一個單元發生故障后，如何在另外一個單元中保持業務的連續性。單元高可用設計示意圖見

68、圖 17。圖 17 單元高可用設計示意圖1數據庫高可用設計按照數據拆分的后分片，確保每個分片在對應同城和異地有相應的副本，可考慮同城采用強同步復制機制，異地采用異步復制機制。2應用高可用設計一是針對標準單元 SDU，要求每個 SDU 至少設計一個同城備45份單元，當發生單元級或機房級災難時，可在同城單元中接管業務，同時需考慮為每個單元在異地設計一個備份單元，當發生城市級災難時，業務可切換至異地單元。二是針對全局單元 GDU，應用系統應基于無狀態原則進行設計，在同城和異地的每個機房都進行部署，且全局數據不存在分片設計，當發生災難時無需進行單元切換，由負載均衡引流至狀態正常的全局單元中。標準單元

69、SDU 備份關系的示例見表 8。表 8 單元備份關系示例表單元同城備份單元異地備份單元S01S03S11S02S04S12S03S01S13S04S02S143云平臺高可用設計根據金融行業的相關技術標準規范要求，在生產環境需要兩地三中心的部署模式，且每個中心支持全局單元 GDU 和標準單元SDU 的部署，并實現單元配置信息在多個中心的云平臺之間進行同步。當發生單元故障后并切換至新單元后，新單元所在的云平臺環境可快速提供服務，并實時更新單元化配置規則。五、應用實踐五、應用實踐本報告精選了四川銀行單元化架構設計及應用實踐為案例。案例介紹了四川銀行如何根據自身發展需求選擇單元化架構（架46構見圖 1

70、8）、如何通過架構升級提升了對基礎設施的自主可控能力、以及如何通過平臺級能力來最大幅度減少單元化架構落地時對應用側的影響。主要特點如下。（1）四川銀行作為省級法人銀行，是服務四川省區域經濟、做好“金融五篇大文章”的重要力量。銀行本身的體量、增長趨勢和政策定位，決定了其信息系統架構必須具備高可用、高彈性、高擴展的能力，單元化架構正是契合其業務發展戰略的最佳選擇。（2）在大數據高性能、金融關鍵產品的國產化替代、信息核心技術的自主可控的背景下，單元化架構從底層即解耦了基礎設施硬件，降低對國外品牌和單一芯片的依賴。（3）采用企業級平臺化的端到端單元化落地方式，覆蓋了從渠道到核心的關鍵交易鏈路，對應用基

71、本透明，通用性強。同時該架構實現了在機房內收斂流量，減少跨機房時延疊加、帶寬需求及降低網絡穩定性風險，更易提升交易鏈路的整體性能。為提升單元化架構在應用層的透明性，本案例采用了一項關鍵技術，在接入層通過微服務網關實現了單元化的路由轉發。同時提供了全局客戶號轉換服務，以確保在不同業務場景下路由要素的一致性。這樣一來，避免了在應用層對客戶號轉換流程進行代碼邏輯調整和代碼改造的需求。這樣的設計不僅簡化了開發人員的工作，還提高了系統的靈活性和可維護性。47圖 18 四川銀行單元化架構六、六、總結展望隨著金融行業數字化轉型的加速以及業務需求的不斷演進，金融級單元化架構作為提升系統性能、可用性和擴展性的關

72、鍵技術，其未來發展前景備受關注。（一）新技術融合加快業務創新（一）新技術融合加快業務創新金融級單元化架構未來將與更多前沿技術深度融合，進一步提升系統的性能和穩定性。如，結合人工智能和機器學習技術，實現更智能的單元路由優化、故障預測與自動恢復，以及更精準的風險評估和安全防護。（二）多地多活架構進一步深化（二）多地多活架構進一步深化隨著數字化轉型的加速和金融業務向更廣泛的人群及區域覆蓋，多地多活架構將成為金融級單元化架構的重要發展方向。未來，金融機構可能會在全國范圍內部署更多的數據中心，通過48單元化架構實現跨地域的業務連續性和高可用性。不僅能夠更好地應對自然災害、網絡攻擊等突發事件，還能滿足不同

73、地區用戶對金融服務的實時性和一致性的需求。此外，多地多活架構的深化還將推動單元化架構在數據同步、分布式事務管理、容災切換等方面的技術創新，進一步降低故障恢復時間和數據丟失風險。（三）生態合作與標準化建設逐步完善（三）生態合作與標準化建設逐步完善金融級單元化架構的推廣和應用離不開生態合作與標準化建設。未來，金融機構、科技企業、云服務提供商等各方將加強合作，共同構建開放、共享的金融級單元化架構生態系統。通過制定統一的技術標準和規范，降低不同機構之間技術對接的難度，促進金融級單元化架構的廣泛落地和應用。同時，標準化建設還將有助于提升系統的可維護性和可擴展性，推動金融級單元化架構在不同金融業務場景中的快速部署和靈活調整，為金融行業的數字化轉型提供更有力的支持。49參考文獻1JR/T 0166-2020 云計算技術金融應用規范 技術架構2JR/T 0167-2020 云計算技術金融應用規范 安全技術要求3JR/T 0168-2020 云計算技術金融應用規范 容災