ICS35.240.40CCSA11Financialdistributedsystem--Applicationdesignpr北京金融科技產業聯盟發布IT/BFIA039—2024前言 2規范性引用文件 3術語和定義 4縮略語 5應用單元化設計 6應用服務設計 7一致性設計 8雙機并行驗證設計 9漸進切換設計 T/BFIA039—2024本文件按照GB/T1.1—2020《標準化工作導則第1部分：標準化文件的結構和起草規則》的規定起請注意本文件的某些內容可能涉及專利。本文件的發布機構不承擔識別專利的責任。本文件由北京金融科技產業聯盟歸口。本文件起草單位：中國金融電子化集團有限公司、北京金安信息技術有限責任公司、中國建設銀行股份有限公司、建信金融科技有限責任公司、中國工商銀行股份有限公司、中國農業銀行股份有限公司、中國銀行股份有限公司、中銀金融科技有限公司、招商銀行股份有限公司、平安銀行股份有限公司、華為技術有限公司、螞蟻科技集團股份有限公司、騰訊云計算（北京）有限責任公司、中電金信數字科技集團有限公司、安超云軟件有限公司、新華三技術有限公司。本文件主要起草人：姜云兵、班廷倫、馬國照、韓竺吾、李晨曉、金磐石、唐成山、丁陳飛、楊晗琦、張以哲、張正園、楊永、隋寧寧、王炳輝、夏龍飛、施經緯、劉瓊、王磊、楊東、肖飛軍、劉艷明、張美慶、金艷、楊進、潘振禹、胡曉磊、郭智慧、蔣增增、李克鵬、駱君柱、劉磊、隋成龍、許剛、李培、高云超。T/BFIA039—2024近年來隨著科技與金融加速融合，金融業務模式逐步朝著線上化和多樣化的方向發展，分布式架構具備高效彈性、開放靈活等特性，可有效適應業務的快速調整和市場的快速變化，為金融信息系統的發展筑牢基石。金融業IT系統分布式架構轉型提升了應用系統海量交易高并發和海量數據處理的整體性能，保證了金融應用系統的可用性，分布式架構是未來金融行業IT系統架構的重要架構形式。當前，仍存在較多的金融IT系統運行于集中式架構之上，IT系統整體進行分布式架構轉型還面臨著業務連續性要求高、海量遺留系統改造難、海量應用管理難、缺少行業級架構設計標準指導以及潛在技術安全風險等共性問題，隨著金融行業數字化轉型的深入，這些問題將影響金融機構數字化轉型質量與進程。為幫助和引導金融機構快速構建自身的分布式架構支撐體系，推動金融行業應用系統的整體分布式架構轉型，提升各金融機構分布式架構轉型的質量和效率，降低實施成本，特編制金融分布式系統系列標準。本文件是金融分布式系統系列標準之一，金融分布式系統系列標準包括：——《金融分布式系統術語》。目的在于給出本文件系列中所使用的專業名詞，是其余各部分閱讀和應用的基礎。——《金融分布式系統IT治理指引》。目的在于給出金融機構分布式架構轉型后IT治理能力建設原則、流程管理、技術要求、技術支撐體系等方面的要求，以指導金融業分布式架構轉型的IT治理能力建設，形成貫穿研發、運維、管理各領域的立體式的深度治理體系。——《金融分布式系統參考架構》。目的在于給出金融機構IT系統分布式架構設計參考，確立金融業IT系統分布式架構的核心模塊、組件以及整體結構，闡明分布式系統架構下各模塊和組件的主要功能以及相互間關系。——《金融分布式系統應用設計原則》。目的在于給出金融應用微服務改造設計的總體要求，闡明微服務設計、單元化設計、一致性方案設計、并行驗證設計以及正確性驗證等通用要求。——《金融分布式系統技術平臺能力要求》。目的在于給出金融應用運行時所需關鍵技術平臺能力的總體要求，闡明軟負載、微服務、分布式事務、分布式消息、分布式數據庫、分布式緩存以及批量調度等領域的通用要求和安全擴展要求。——《金融分布式系統應用開發測試原則》。目的在于給出分布式架構下金融應用開發與測試相關要求，闡明分布式應用軟件開發規范、工具方法與測試要求、內容、方法、過程、環境、文檔、工具以及管理的通用要求，保障金融分布式應用的研發質量，更好滿足用戶需求。——《金融分布式系統運維能力要求》。目的在于給出金融應用運維時所需關鍵支撐能力的總體要求，闡明金融應用部署、監控、故障定位與分析、運行保護等領域的通用要求。1T/BFIA039—2024金融分布式系統應用設計原則本文件給出了金融分布式系統的應用單元化設計、應用服務設計、一致性設計和雙機并行驗證設計。本文件適用于金融領域分布式系統的應用設計。2規范性引用文件下列文件中的內容通過文中的規范性引用而構成本文件必不可少的條款。其中，注日期的引用文件，僅該日期對應的版本適用于本文件；不注日期的引用文件，其最新版本（包括所有的修改單）適用于本文件。JR/T0167—2020云計算技術金融應用規范安全技術要求JR/T0203—2020分布式數據庫技術金融應用規范技術架構JR/T0223—2021金融數據安全數據生命周期安全規范T/BFIA037-2024金融分布式系統術語3術語和定義T/BFIA037-2024中界定的術語和定義適用于本文件。4縮略語下列符號和縮略語適用于本文件。SQL：結構化查詢語言（StructuredQueryLanguage）API：應用程序編程接口（ApplicationProgrammingInterface）I/O：輸入/輸出（Input/Output）AZ：可用分區（AvailableZone）XA：擴展架構（eXtendedArchitecture）SAGA:長事務模式TCC:嘗試-確認-取消（Try-Confirm-Cancel）5應用單元化設計5.1概述在金融分布式系統設計中，通過單元化設計將一個大規模的系統分拆成許多相對獨立的小規模的系統，每個單元系統可以靈活的部署，應用系統可獲取適當的擴展能力。系統的伸縮模式可變成單元的2T/BFIA039—2024增減，單元內部的規模和復雜性不變。單元之間的故障隔離，可降低軟硬件故障的影響范圍。應用單元化設計，應對外圍用戶透明。5.2單元化總體設計應用系統在單元化架構下的總體設計，應該做到每一個部署單元都是全量數據的一個子集，且單元內包含可以實現本系統服務的全部功能。應用單元化架構設計遵循以下設計原則：a）宜滿足單元的全功能，一筆交易、一個作業涉及到的所有處理都在本單元內完成；b）應滿足單元的隔離性，任一單元不能直接操作其他單元的數據，若有需要應以服務調用的方式進行，可以是同步的，也可以是異步的，同步調用需要關注異地響應延時；c）應滿足故障的隔離性，一個單元內的故障不會傳播到其他單元；d）應滿足容災性，每個單元在同城或異地有災備單元以保證在故障期間進行單元處理接管；e）應滿足分層設計的，分層模塊間的調用只會選擇同一單元內的節點。單元內的模塊設計需要能夠完成本單元的所有業務和技術處理；f）宜滿足交易流量在單元內收斂，避免應用與單元數據分片跨機房調用。5.3單元化平臺設計單元化應有一套技術平臺來支撐應用單元化的設計，技術平臺封裝一系列的技術能力作為支撐。技術平臺能力包含以下內容：a）宜具備一套支持單元化的技術中間件，來屏蔽單元化對業務的影響，如：數據訪問中間件、消息中間件等；b）應具備一套基于單元化數據拆分維度配置管理平臺，比如單元可以訪問哪個分庫等；c）應具備一套單元化部署的平臺；d）應具備一套支持單元化的鏈路跟蹤平臺。5.4數據單元化設計在應用的單元化設計時，應在應用數據上滿足單元化設計。數據的單元化是單元化應用的基礎，數據的單元化劃分可以使系統更好的具備擴展能力、高可用以及容災能力。數據單元化遵循以下原則：a）數據宜具備可按照某個維度來劃分的能力；b）應適合自身交易特性，拆分維度應與應用特性相適配，可采用垂直與水平相結合的方式；c）宜采用統一拆分規則，數據拆分時，應對數據采用按照統一規則進行拆分，進而產生統一的全局分庫鍵，并盡力減少分布式事務；d）應充分考慮單元數量，數據拆分時，應考慮業務的發展，盡量避免因為拆分數量不夠，導致業務發展過程中多次進行水平拆分；e）應具備進一步分拆能力，可以根據未來可見的數據量大小做拆分，便于將來繼續拆分；f）宜具備數據副本同步能力，對于全局性的數據，宜做到在可接受的時間內同步到副本的能力；g）應具備獨立的高可用和容災能力。5.5單元化路由設計在應用單元化設計中，為了使得外圍無感知，且便于單元化服務訪問，應有一個支持全局單元的調度路由系統。路由系統控制著流量分配、跨單元訪問等，是實現單元化設計的一個重要手段。路由設計，遵循以下設計原則：a）應具備分配流量能力，可根據單元實際負載進行流量分配；b）應具備加載單元化分片的規則與方法的能力，并根據規則實施控制所有單元的運行的能力；3T/BFIA039—2024c）應支持多種不同的路由算法，需要根據應用特點支持多種不同的路由算法，算法能力包括但不限于哈希算法、業務要素映射、指定尋址等；d）宜具有熔斷能力，算法能力包括但不限于斷路、流量控制、服務降級等；e）宜具有負載均衡能力，算法包括但不限于輪詢法、隨機法、最小連接數法等。5.6單元化伸縮設計伸縮性是指通過不斷向集群中加入服務器的手段來緩解不斷上升的用戶并發訪問壓力和不斷增長的數據存儲需求。在應用單元化設計中，單元化伸縮宜滿足以下原則：a）通過停止故障單元的方式隔離故障，降低故障的影響范圍；b）通過監測設定閾值，在進入單元的流量增長/減少時，進行單元的動態擴縮容。5.7單元化治理設計在應用單元化設計中，隨著業務量的增加，系統拆分出的單元數量會隨之上升。治理設計，宜滿足以下設計規則：a）有一個統一的服務單元地址管理系統，包括服務單元的發現和注冊，即注冊中心；b）有一套機制管理分配進入各單元的流量，包括平均分配流量的軟負載均衡、瞬時請求的流量削峰、服務不可用的服務熔斷、服務器壓力過大時保護核心業務的服務降級、通過限制流量進出單元而保障系統穩定運行的服務限流；c）保證版本升級后，新數據結構能解析舊的數據；d）具有多活災備，保證服務單元的高可用性。6應用服務設計6.1概述服務是一個單一的、可以獨立部署的軟件單位，實現了一系列的業務功能。分布式系統下的應用服務設計，有別于集中式系統下的應用服務設計，需要考慮服務在單元內的業務邏輯還要考慮跨單元協同的邏輯。因此，在分布式架構下的應用服務設計，除了關注業務功能之外，還需要確定合理的服務的分解。6.2服務總體設計分布式系統應用服務設計時，從業務功能識別定義到形成單元化的服務，遵循以下總體的設計原則：a）宜為服務系統創建抽象模型，并根據模型來定義系統的操作；b）可基于業務能力進行服務拆分，針對目標的結構流程分析識別業務能力，并為每個能力定義服c）可基于領域進行服務拆分，分析業務并識別出業務對應的不同子域，并為領域定義模型界限上下文，進而分解為服務；d）宜設計無狀態的服務。6.3服務拆分設計在形成業務模型之后，需要對服務進行服務識別拆分。在服務拆分設計時，宜遵循以下拆分原則：a）遵循跨單元拆分原則：一個事務所涉及的數據是否有可能在不同數據庫單元，若有可能在不同單元，只能拆分為微服務進行協同處理；4T/BFIA039—2024b）遵循繼承性原則：業務功能經過長期的傳承演進，原有服務的設計存在既有合理性，針對原有功能和數據分布未發生改變的，其微服務的設計應該盡量保持原有顆粒度，盡量減少對外圍調用方的影響；c）遵循企業架構原則：遵循自身企業的業務領域劃分和組件劃分。其中，按業務領域劃分是指按業務把每個業務都拆分成一個微服務，如：按照存款、貸款、借記卡的維度拆分。按組件劃分是指公共組件按組件劃分原則拆分成多個微服務；d）遵守微服務單一職責的原則：一個微服務中如果包含太多功能、職責，一旦任意一個模塊修改就會導致該微服務重新編譯重新部署，進而增加了變動成本、降低研發效率；e）遵循最少調用原則：分析數據處理的步驟，要盡可能歸并在一個單元處理的步驟，讓服務組合調用微服務調用次數最少。4個步驟：步驟1訪問A單元->步驟2訪問B單元->步驟3訪問A單元->步驟4訪問C單元。如果四個步驟之間無依賴關系，則可拆分微服務1（步驟1->步驟3）、微服務2（步驟2）、微服務3（步驟4）；f）遵循性能約束原則：一個服務的顆粒度過大，處理步驟過多，訪問數據過多，占用系統資源過多，響應時間過長，需要結合交易的業務功能的內聚性，拆分為多個微服務，保證系統整體資源并發處理效率；g）遵循持續演進原則：微服務應隨著應用系統開發、測試和運維過程的持續開展逐步完善，持續演進。6.4服務編排組合設計針對拆分之后的服務，應用中會存在一些面向其他服務調用的操作，需通過多個服務之間協作來完成的業務能力。這就需要對多個服務進行編排組合，服務編排組合設計遵循以下原則：a）應對邏輯比較復雜，跨集群協作的服務，需要通過服務編排組合的方式，將微服務串聯；b）對于需要根據外呼調用返回結果來決定后續的編排路徑的場景，宜采用面向可執行流程的編排策略。即通過一個可執行的流程來協同內部及外部的服務交互，通過流程來控制總體的目標、涉及的操作、服務調用順序；c）對于實時性要求不高的，宜采用面向協作的編排策略。即通過消息的交互序列來控制各個部分資源的交互，參與交互的資源都是對等的，沒有集中的控制；d）宜提供一種編排框架，包含賦值、調用的活動模型和分支、循環、異常捕獲等控制模型；e）宜采用統一的全局流水號和每個服務不同的子交易序號。6.5查詢服務設計查詢服務設計遵循以下策略：a）對于時效性不高的高頻查詢服務，可讀取備庫以減少數據庫主庫的壓力；b）純查詢服務可設計以只讀用戶連接數據庫，降低問題代碼風險；c）可采用API組合模式，通過查詢數據提供方的服務來實現查詢操作。該模式可以簡單直觀的實現查詢操作，但也會增加一些額外的開銷并帶來可用性降低的風險；d）可用命令查詢職責隔離模式，使用時間來維護從多個服務復制數據的只讀視圖，借此實現對來自多個服務的數據查詢。6.6緩存使用設計在應用設計中，針對頻繁使用且極少更改的數據，可以考慮使用緩存，減少與數據庫的交互，降低交易的響應時間，提高系統的性能。緩存可分為多級。如交易級緩存、應用服務器緩存、分布式緩存等。5T/BFIA039—2024多級緩存中通過緩存一致性協議、監聽機制、狀態轉換以及數據同步等手段，可以確保處理器能看到共享內存中的最新數據，保證緩存一致性。應用使用緩存時，應遵循以下原則：a）需要考慮數據的特點，緩存適合用戶讀多寫少的數據，比如利率、費率等參數類數據；b）考慮數據使用的業務時效性，緩存適合對業務時效性要求低的數據，不同的時效性要求決定了緩存的更新策略和過期時間，對時效性要求越低的業務越適合使用緩存；c）考慮對象粒度，粒度不可過大，通常而言緩存對象的粒度越小越適合放在緩存中；d）考慮合適的淘汰策略，盡量避免同一時間大規模過期數據引發緩存擊穿或緩存雪崩；e）做好容量規劃以及容災策略，避免緩存實例故障后造成大規模緩存失效；f）交易級緩存的生命周期僅為一個交易內。可用于在一個交易內頻繁訪問的數據，且該數據可以較為頻繁的更新。需要關注的數據在交易內更新時，需要清空緩存；g）應用服務器緩存存在于本地內存中。其與分布式緩存相比，減少了網絡I/O的開銷，性能更優。使用該級別緩存要注意緩存刷新策略。緩存刷新的方式可根據緩存數據生效的敏感度進行設置，若為敏感參數，采用事件通知方式刷新；若為不敏感數據，采用定時刷新。6.7消息使用設計聯機交易由多個業務步驟組成，某些業務步驟與其他步驟關聯性不強，可以單獨延遲處理，這類步驟就可以通過消息實現。應用使用消息時，應遵循以下原則：a）分析原本的業務邏輯，將其中對實時性要求不高的部分拆分出來，通過異步消息進行處理例如短信發送、客戶合約快照同步、代理人信息登記等；b）具備冪等性，能夠處理重復的消息；c）消息處理交易，具備反向處理能力，能夠處理沖正交易的異步消息；d）應用使用的異步消息框架考慮消息的時序性和并發處理。6.8數據庫訪問設計分布式架構下，分布式數據庫應提供關系型和非關系型數據存儲能力，具備JR/T0203—2020，7中的相關能力。為簡化應用對分布式數據庫操作的開發，一般需提供數據庫操作語句的封裝。在數據持久化時，遵循以下規范：a）宜對數據庫訪問進行標準封裝，支持對指定數據庫表進行基本操作，并提供異常處理功能；b）僅使用標準SQL進行數據庫表操作，避免使用某種數據庫特色的SQL語句；c）宜對增刪改查等基本數據庫操作進行封裝。封裝時應避免數據庫產品特性，以支持數據庫產品變更對應用代碼透明；d）宜對一些使用簡單數據庫操作實現的場景，例如關聯查找、范圍查找、聚合函數等，只能通過非標準的語句實現。對這些內容，應規定開發規范，限定使用場景；e）宜對于數據庫事務提交，在平臺層面進行統一處理，對于數據庫事務操作也宜提供標準的封裝。6.9應用服務安全設計分布式應用服務安全策略包括身份認證、訪問控制、敏感信息保護、數據完整性與一致性等，具體如下：a)用戶訪問信息系統資源前，應對用戶身份進行鑒別，鑒別信息應由用戶交互提交，前端禁止以任何形式保存用戶鑒別信息。對于行內各個系統、組件間的認證，應由加密組件完成；b)各平臺組件間應實現面向組件的訪問控制，防止組件被非授權訪問；c)系統應有完整的數據產生、存儲、歸檔管理機制，運行生成的交易報文敏感信息不在非數據庫以外的設備落地。數據庫存儲的敏感數據應采用加密手段進行保護，敏感信息應在應用系統中6T/BFIA039—2024實現加密傳輸；d)應確保數據在傳輸過程中不被篡改，分布式系統所有節點都能看到相同數據，應符合JR/T0223—2021的7.2節及JR/T0167—2020的9.2節相關內容。6.10應用服務高可用設計分布式應用服務高可用設計遵循以下策略：a)確保業務連續性：縮短計劃內外的停機時間，降低對客戶的影響；b)容錯架構設計：通過冗余設計避免單點故障，將應用部署到多個AZ，采用兩地三中心或三地三中心；網絡設備冗余，服務器配置雙電源、雙網卡等；c)數據庫高可用：傳統數據庫采用高可用存儲、數據庫復制，分布式數據庫采用多份數據副本。d)服務降級：采用限流和熔斷策略應對流量陡增、關聯系統故障等外部因素影響；e)監控與應急響應：建立全方位監控指標，及時發現系統異常；建立完善的應急機制，保證及時介入處置。7一致性設計7.1交易一致性設計交易一致性是指在交易過程中，每個調用步驟應當是全部成功或者全部失敗的狀態，不可以出現一部分成功一部分失敗的情況。為此，應用在進行交易設計時應考慮交易一致性，并根據實際業務模式選擇以下交易一致性設計：a）采用XA標準的分布式事務：采用XA標準的分布式事務來保證一致性，應通過兩階段提交來保證事務中所有參與方同時完成提交或者同時回滾。要求在多個服務、數據庫和消息代理之間維持數據一致性的參與方都滿足XA標準；b）采用Saga模式：采用Saga模式維護交易一致性，應通過異步調用的方式來協調一系列的本地事務，在檢測到事務失敗時，利用補償事務回滾來達到數據一致性；c）采用TCC模式：采用TCC的模式來維護交易一致性，各業務參與方應提供業務檢查并預留資源的服務、一個不做資源檢查直接執行業務的服務和一個釋放預留業務資源的服務。7.2賬務一致性設計在一個賬務類應用系統中，賬務步驟應滿足賬務是一致的。因此應用在設計時，應包含賬務一致性的設計，包括：a）在聯機交易執行時，一只微服務生成的會計分錄需遵循借貸一致原則，即借貸方向相反，金額相等；b）在系統內，如果組合交易的微服務之間存在賬務關系，則應在微服務中記錄跨分片往來。跨分片往來也應滿足平賬要求，即各微服務記載的跨分片往來借方及貸方匯總應該相等。同時，在微服務內部，跨分片往來與其他會計分錄之間也應遵循借貸一致原則。在系統間，如果存在賬務關系，則應在每個系統內部記錄跨系統往來；c）對交易與核算分離的系統，為避免交易、核算系統間的消息丟失，應在日終進行核算一致性比對，即將交易系統記載的賬務要素同核算系統記錄的賬務信息進行比對。比對一般按全局唯一的跟蹤號進行勾連，并檢核其金額、幣別等關鍵要素是否一致；d）日終時，進行總分核對。即核算系統將當日生成的核算信息，按科目、機構等要素匯總文件發總賬系統；同時交易系統將分戶賬余額文件發總賬系統。由總賬系統根據兩套文件進行總分核7T/BFIA039—2024對。7.3服務的冪等性設計服務的冪等性是指應用系統的服務在重復調用的時候，應返回上一次調用的結果。在應用設計中，服務遵循一定冪等性規范，包括：a）宜通過全局唯一跟蹤號的方式，在服務中增加全局唯一跟蹤號，利用數據庫的唯一索引約束來保證服務的冪等性；b）可采用有限狀態機的方式，通過狀態機的狀態變更流程來達到服務的冪等性。7.4服務事后對賬設計對于涉及賬務的系統，需要在日終設置對賬機制，以檢查是否有交易發生不一致。根據對賬發生在系統間或系統內部，宜分為“系統間對賬”和“系統內對賬”。a）涉及跨系統的賬務交易，設計系統間對賬機制應遵循以下原則：——系統間對賬基于流水記錄；——系統間對賬考慮對賬周期問題；——系統間對賬考慮性能。b）對于集中式系統，內部不存在交易組合，因此不涉及系統內對賬。同時，集中式系統中事務一次提交，因此流水中的交易狀態是明確的。但在分布式系統中，系統內部存在交易組合，可能存在內部微服務不一致的場景，因此需要系統內對賬；同時流水狀態可能存在“未知”，在系統間對賬前應先明確組合交易的流水狀態，以避免出現混淆。系統內對賬應遵循以下原則：——系統內對賬基于交易流水；——系統內對賬考慮性能；——系統內對賬時，對賬周期為同一營業日期；——在系統內對賬之后，提供自動化的處理機制；——對于“狀態未知”的組合交易，在調賬之后明確其流水狀態。8雙機并行驗證設計雙機并行指的是，將生產流量復制一份發往目標待驗證的系統，以此來驗證新系統在真實生產流量下運行的準確性和穩定性，雙機是指目標驗證系統及生產系統。由于交易還是運行在生產系統，雙機并