近期讀到騰訊發布的《商業銀行核心系統分布式轉型白皮書》，書中介紹了銀行核心分布式改造的架構路線、關鍵技術及最佳實踐等內容。結合自己之前在金融業的一些體驗，感覺總結整理的不錯，特分享出來。文中的部分內容摘自此白皮書。

1. 背景：分布式選擇成為必然

無論從業務還是技術角度，銀行業都正在完成從“集中式”到“分布式”的轉型。其背后是有必然性的，可概括為以下幾個方面：

? 業務發展需求

隨著互聯網技術和移動支付的快速發展，銀行的業務形態和模式發生了巨大變化。傳統的集中化核心系統往往難以滿足快速應對市場變化、實時處理大量交易的要求，因此需要進行分布式核心改造。

? 系統性能瓶頸

傳統的集中化核心系統往往存在系統性能瓶頸，無法滿足大規模用戶同時在線交易、高頻交易的需求。通過分布式核心改造，可以將系統對各項業務進行分拆和擴展，提高系統的并發處理能力和吞吐量。

? 系統可擴展性不足

傳統的集中化核心系統往往難以實現快速靈活的業務拓展和系統擴展。通過分布式核心改造，可以將不同的業務模塊分布在不同的服務器上，實現業務功能的獨立擴展，提高系統的可擴展性和靈活性。

? 系統穩定性和安全性

傳統的集中化核心系統往往存在單點故障風險，一旦發生故障或被攻擊，將對銀行的正常運營造成嚴重影響。通過分布式核心改造，可以將系統分布在多個服務器上，實現故障隔離和負載均衡，提高系統的穩定性和安全性。

? 技術創新驅動

現代分布式技術和云計算技術的快速發展為銀行分布式核心改造提供了技術支持。通過采用分布式數據庫、分布式計算等技術手段，可以實現銀行業務的高效處理和大規模擴展，進而提升銀行的競爭力和用戶體驗。

2. 方法：建設模式與整體架構

1).建設模式

銀行核心分布式改造，可分為兩種模式：一是技術平移，二是規劃重建。

• 技術平移

這是科技部門內部能夠閉環的模式，在保持功能基本不變的情況下，將應用遷移到分布式平臺或將應用適配到國產數據庫或云平臺上。技術平移首先要確定平移目標，如平移到國產化的云、操作系統、數據庫、中間件等等。其次是要確定平移的路徑，比如優先使用產品、定價等模塊做試點，再平移核算，形成完善的平移經驗和工序后，最后是進行存貸模塊的平移。

• 規劃重建

這是比較徹底的一種模式，需要聯合業務部門，結合全行業務發展戰略，整合業務需求，重新設計建設新一代核心系統。規劃重建整體上比技術平移更具挑戰，不同銀行也都根據自身特點走出一條適合自己道路。

業務建模

業務建模是最早由建行聯合眾多業內專家實踐產生的需求分析與統一建模的方法論，隨后在幾家國有大行的新核心建設中逐步豐富延展。IT工藝是與之配套的新核心建設方法論，其能承接業務建模的產出，用業務模型指導微服務模型落地，用識別、定義、分解等標準工序拆解復雜架構，最終基于構件實現松耦合的組裝和編排，在復雜項目設計與建設中發揮了重要作用。

2).整體架構

圖片

從核心系統整體架構上，可分為七大部分內容。

• 底層是IaaS云平臺，中間是PaaS云原生平臺，上層是SaaS核心應用領域，左側為研發效能體系和混沌測試體系，右側為智能運維體系和安全體系。上圖七塊內容形成新核心所需的整體能力框架。
• SaaS層包括了銀行核心系統的應用域，如：存貸、支付結算、銀行卡、核算及公共服務等。所需的能力中心和7*24等公共機制。分布式技術組件用于封裝分布式底層技術，負責對上層應用模塊屏蔽產品差異與技術復雜度，同時連接著下層PaaS平臺的各項能力。其中，一部分與云廠商的產品存在一定重疊，如：單元化能力組件、分布式事務、聚合查詢組件、服務調用代理等。在實際落地過程中需要明確雙方邊界，進行有效的整合與聯動形成一體化的、穩定的技術平臺底座。
• PaaS層以云原生容器平臺、分布式數據庫、分布式消息隊列、分布式緩存、微服務平臺等中間件為主。
• IaaS層主要包括了云平臺的計算、存儲、網絡、資源編排、多云管理和安全能力。
• 研發效能體系中包括了傳統的Devops體系，同時還集成了項目管理和質量管控體系。以需求為抓手，貫穿設計、開發、測試、安全、發布、生產全生命周期管理，每個環節形成有效的反饋機制，確保在每一輪迭代都能有效量化生產數據，實現精益管理。

3. 路線：微服務與單元化

對于核心提供的分布式改造，有兩種技術路線選擇：一是微服務、二是單元化。微服務和單元化之間并不是一個包含關系，而是一種加強關系：單元化是微服務架構在宏觀架構層面的增強，而微服務是單元化架構在微觀機制層面的支撐。我們可以從多方面對比兩者的差異。

圖片

在若干核心的設計要點上，兩者均存在一些差異，可以從下面六個方面進行對比。

• 數據切分策略上，需考慮幾個問題：一是按什么維度進行何種拆分，二是采用什么存儲方式，三是如何進行擴容，四是需處理那些數據。
• 技術架構標準上，需考慮幾個問題：一是交易調用處理策略，二是分布式事務策略，三是聚合查詢策略，四是灰度發布策略。
• 服務實現策略上，需考慮幾個問題：一是服務顆粒度的選擇，二是落地實施工藝，三是技術組件。
• 業務連續性上，需考慮高可用架構及容災切換策略。
• 研發效能上，將研發、測試、發布環節打通，形成一體化的持續跟蹤、反饋、提升體系。
• 分布式運維上，一改傳統運維方式，突出發現隔離能力，并可引入大數據與AI提高分布式下的分析預測能力。

圖片

4. 路線：微服務架構

1).基本概念

微服務架構是一種軟件架構風格，其中應用程序被拆分為一組小型、松耦合的、自治的服務。每個服務都可以獨立地進行開發、部署和擴展，并通過輕量級的通信機制（如HTTP、消息隊列等）進行互相通信。微服務架構的核心原則是將復雜的單體應用程序拆分成更小、更可管理的部件，每個部件專注于完成一個特定的業務功能。這些服務旨在可以獨立開發、測試、部署和擴展，以滿足不同的需求和快速變化的業務要求。

? 架構特點

• 松耦合：每個服務都是獨立的，可以獨立部署和擴展，沒有共享的數據庫或技術限制。
• 獨立自治：每個服務具有自己的代碼庫、數據庫和團隊，可以獨立地進行開發和管理。
• 服務邊界明確：每個服務都定義了明確的業務邊界，可以專注于解決特定的業務問題。
• 分布式：不同的服務可以運行在不同的服務器或容器中，并通過網絡進行通信。
• 彈性和可伸縮性：由于每個服務都是獨立的，可以根據需求進行單獨的擴展，提高系統整體的彈性和可伸縮性。
• 高可用性：通過服務復制和負載均衡等機制，提高系統的可用性，一個服務的故障不會影響整個系統的正常運行。

? 銀行微服務特點

微服務架構可以帶來像應用解耦、獨立自治等諸多優勢，但微服務并沒有解決所有問題，如服務拆分后的服務編排問題、分布式事務問題，或者數據拆分后的聚合查詢問題等。在銀行核心如此嚴謹的領域，微服務的使用一定要綜合考慮各種場景，充分聽取多方意見，從中找到平衡點。如果一味從理論角度推進，往往得不償失。考慮到微服務顆粒過細所帶來的整體復雜度，通常在設計時會按照標準的業務領域進行組件的設計和開發，但在發布時會將多個相關的組件進行合并發布。以此來減少組件間的調用鏈路，提供系統穩定性和性能，簡化運維復雜度，包括減少分布式事務的產生。

2).設計要點

? 數據切分策略

• 維度字段：數據切分維度主要以客戶號Hash和List兩種方式為主，可分別從分布式事務出現概率、數據分布均勻程度、訪問壓力的均勻程度、擴容的難易度等幾個維度結合核心業務特征來確定。客戶號并未唯一選擇，只是在核心業務場景中單客戶的交易場景居多，為避免產生分布式事務所以大多以客戶號作為數據分片的維度。當然也有按地域和機構的維度來切分數據的，這種切分方式一定程度上解決了核心場景中非客戶維度的查詢問題，但會導致潛在的數據分布不均以及訪問不均的風險。
• 聚合查詢：針對數據分散之后帶來的聚合查詢問題，業界有不同的技術手段來處理，比如把相關數據同步到聚合庫或搜索引擎，或者采用分布式數據庫產品自帶的AP引擎進行處理。
• 擴容問題：設計切分策略時需要同步考慮未來的擴容策略，針對微服務架構路線，可直接采用分布式數據庫自身的擴容能力實現數據層的擴容。無論用哪種方案原則都是在擴容時要盡可能的減少數據遷移的規模。在銀行核心場景中，我們建議充分評估未來業務增長量，結合單個物理分片能承載的業務量基線，評估能滿足未來5年的規模容量，盡可能避免數據遷移場景的產生。

? 服務交互方式

技術標準主要以SpringCloud微服務體系的標準為主，服務注冊和發現模型是目前分布式系統最主流的模塊交互模式。應用實例在啟動時均會向注冊中心提交自身信息，而注冊中心會維護一個全量的服務目錄，并下推到所有消費方。服務消費方通過微服務提供的負載均衡組件和服務調用組件實現對目標服務的尋址與點對點的調用能力。這個過程中，注冊中心作為非關鍵交易路徑提供服務，提升了該模型的整體穩定性。負載均衡算法需要支持主流的幾種策略，包括：隨機、輪詢、最小連接數等。

? 分布式事務

分布式事務是集中式系統微服務化之后不可避免的問題，在金融領域顯得格外重要。然而目前為止在微服務體系中尚未統一分布式事務的處理標準。其產生的原因不同，對應也有不同解法。

圖片

分布式事務最好的處理方式是“恰好不用解決”。即通過合理的應用規劃和數據切分來有效地避免分布式事務的產生。所有的分布式事務處理機制都會帶來不同程度的損耗，無論是在應用側實現還是數據庫側實現。在數據庫性能和容量允許的情況下，也會考慮將相關微服務組件對應的數據庫進行合并，來減少因為數據拆分而產生的分布式事務，應用層也會考慮將關聯的服務組件合并成一個微服務組件進行發布，以減少因為應用拆分而產生的分布式事務。

? 擴容策略

擴容可分為應用擴容與數據庫擴容。在微服務架構下，因為有注冊中心的存在，新的應用實例在啟動時會自動注冊到注冊中心，注冊中心會更新服務目錄并推送到服務消費方，隨后消費方在新的服務目錄中負載時就會將一部分流量隨機到新的實例上，以此來實現應用集群的擴容。對于數據庫擴容，則基本依托分布式數據庫能力實現。

? 高可用策略

在同城兩個數據中心中，標準架構中數據庫采用分布式實例，對上層應用屏蔽底層數據庫結構，應用只需連接本單元的數據庫代理進行訪問。數據主副本都在主中心部署，應用在兩個中心中分別部署。

圖片

流量通過頂層接入，經過 DNS 到中心內負載均衡服務再到微服務網關，經過鑒權、限流等一些列檢測后進到微服務業務集群，處理時兩個中心的應用都連接本機房的數據庫代理進行訪問數據，但在數據庫代理這一層會根據路由算法計算客戶所在的數據主備位置，并發起轉發，這個過程中同城機房的請求將出現橫向流量訪問主中心的數據主本，這個過程應用是不可見的，因為分布式數據庫對上屏蔽了底層的數據庫架構和數據路由。以此實現同城兩個數據中心同時處理業務請求的雙活架構。當下基礎設施在同城之間的數據傳輸和穩定性已經非常成熟，對于大多數系統組建這樣的分布式架構是完全沒有問題的。只有在兩個機房間超過一定距離，或延時過高時才需要考慮橫向流量的治理問題，那時單元化架構是一種好的解決方案。

異地容災上，由于在分布式應用系統中，應用的無狀態屬性使得擴容和遷移都變得方便許多，我們只需要考慮有狀態服務，站在核心系統視角主要是數據庫。數據庫的 RTO 和 RPO 是整個核心做異地切換的主要關鍵指標。在大型復雜的銀行核心系統中，會涉及到多個業務數據庫，且每個數據庫下又會有多個數據分片，由于異地間的數據傳輸是異步模式，其切換過程比同城切換要復雜許多，會涉及網絡狀況的判斷，數據補償與校驗等。

圖片

當數據庫切換完成后，容災中心的應用集群連到切換后的數據庫，隨后啟動內部校驗，確認無誤后，在全局負載均衡服務（GSLB）中將流量指向異地的容災中心，實現地域級故障的業務連續性保障能力。整體異地容災切換的流程極為復雜，且與客戶的實際運維環境有關。

5. 路線：單元化架構

1).基本概念

單元化，通過把一部分計算資源和一部分數據資源進行邏輯上的綁定，形成一個標準化的處理單元。我們將一個大型系統拆解成多個標準的處理單元，每個處理單元具備完整的業務能力，但只處理全量數據中的一部分，簡單理解一個單元就相當于一個小分行。單元化架構因其學習成本和實施成本較高，比較適合體量相對較大或有異地多活規劃的銀行，需要結合具體銀行客戶在賬戶數、預算、自主研發能力、業務連續性要求、異地多活規劃等方面來綜合考慮。單元化架構是銀行核心分布式轉型的一種重要方向，但不是唯一的技術方向。

單元化與微服務區別

標準微服務架構默認不對跨中心流量進行治理，其對雙活兩個機房之間的距離和延時有一定要求。假設兩個異地機房，沒有單元化的微服務架構中，應用在訪問數據庫時會存在異地間的數據訪問，因為計算層的負載是無狀態的，而數據的主本是固定在某一機房的，應用跨異地訪問數據時，其穩定性和時延是無法保證核心系統正常運行的，也就是微服務架構在不做改進的情況下較難適應未來異地多活的場景。這是標準微服務架構和單元化架構之間較大的區別之一。

2).設計要點

? 數據切分策略

單元化架構下，數據分片的維度、分布規則都與微服務架構相似，主要以客戶號 Hash 和 List 兩種方式為主。同樣需要考慮分布式事務出現概率、數據分布均勻程度、訪問壓力的均勻程度、擴容的難易度等幾個方面。不同的是單元化架構多以應用側主導數據分片策略及路由策略。這種方式能擺脫對分布式數據庫或中間件產品的依賴，靈活可控是單元化架構的重要優勢。

? 服務交互方式

單元化架構下交易處理策略以注冊發現體系為基礎，但在調用與負載時需要遵循以單元維度和就近調用原則，即：所有路由均需要判斷單元維度，識別單元內調用還是跨單元調用，對于相同服務的調用順序為：優先單元內調用，其次本中心調用，最后同城中心調用。

單元化架構會要求所有應用在往注冊中心注冊時需要帶上自身所在單元的標記信息，同時微服務之間在調用時需要先根據單元標記過濾目標服務的實例，確保在指定單元的服務實例之間進行負載均衡算法。這種根據單元標記進行路由和目標尋址的邏輯在標準微服務架構中是不存在的。

? 分布式事務

同“微服務”的處理機制一致

? 擴容策略

在分布式系統中，應用的無狀態化讓計算資源的擴容變得容易，但在銀行核心場景中就顯得不規范和不受控，而單元化架構則提供了一種分布式系統下計算和數據資源擴容的標準規范。針對數據層的擴容，在單元化架構中會將全量數據分為若干份，每一份稱為一個邏輯分片，然后建立邏輯分片到物理分片和單元的映射關系。擴容時，首先加入新的物理分片，再將指定邏輯分片遷移到新的物理分片中，最后更新邏輯分片到物理分片的映射關系。這個擴容的邏輯通常是由應用側結合數據遷移工具來做定制化開發，也可以通過分布式數據庫的擴容功能實現。在核心場景中，原則上要盡可能減少數據層的擴容，其次是擴容時要盡可能減少數據遷移的規模。

圖片

舉例：假設以客戶維度切分全量數據，每個邏輯分片中存放著1萬客戶數據。現在有兩個單元，每個單元中各一個物理分片，每個物理分片中有32個邏輯分片，也就是一個單元中有32萬客戶數據。其中1號邏輯分片原本是在1單元的1號物理分片中，由于識別到其為熱點分片，現要將其遷移至一個新的3號單元的3號物理分片。那么首先要將1號邏輯分片中的所有數據遷移至3號物理分片，再修改1號邏輯分片到3號物理分片的映射關系以及1號邏輯分片到3號單元的映射關系。當更新生效后，1號邏輯分片中的客戶再發起交易時，網關就會將其路由到3號單元，其中的應用會從3號物理分片中獲取數據進行處理。通過這種方式解決擴容問題。

? 高可用策略

在單元化下的業務連續性，通過設計“互備單元表”來建立兩個單元間的互備關系。當其中一方出現故障時，通過更新狀態，來指向其互備單元ID從而進行路由調整。實現單元間互備要求單元的數據庫副本需要放置在對方單元中，當發生切換時，數據庫會將對方單元下的副本調整為主本。

圖片

如圖，請求通過全局負載服務進入到兩個機房，機房內部通過負載均衡服務轉發到本中心的微服務網關集群，在網關這一層識別請求對應的單元和路由信息，轉發到指定單元處理。當單元1發生故障時，停用單元1的流量，并獲取單元1對應的互備單元信息（單元5），等待數據庫主備切換完成，更新全局路由將流量轉發至單元5。此時單元5除了承載自身業務流量還會承載單元1的業務流量。單元切換的指標絕大部分情況下取決于數據庫的RPO和RTO。回切過程類似，先關停單元1的流量，執行主備切換，讓主庫回到原單元1下，調整網關層路由回到單元1。

與微服務的區別

單元化架構在同城高可用設計上與標準微服務架構有所不同，微服務架構因為沒有單元概念，在故障發生時是直接將整個數據庫切到同城，再切換GSLB的流量。而單元化架構則是以單元維度進行切換，雖然最終效果是一樣的，但是內部運作機制不同，切換控制的顆粒度也不同。

3).示例：騰訊銀行單元化架構

騰訊單元化架構是一種針對銀行分布式核心系統技術架構的體系化、分層次、分領域的架構思想。接入層負責接收流量、識別流量、轉發流量。識別后的流量被轉發至應用層對應單元處理，單元默認按照客戶維度拆分，單客戶交易實現單元內閉環處理。跨客戶交易存在一定比例的跨單元協同處理。數據默認被分為64份，被均勻放置在若干個單元內。可通過灰度機制將指定標簽的客戶放置在灰度單元實現生產灰度運行或驗證。其中：接入單元(ADU)負責接入接出能力、標準處理單元(SDU)負責業務處理能力、本地單元(LDU)和同城單元(RDU)分別用于提供單AZ共享服務能力和同城共享服務能力、以及在異地多活架構中會涉及的全局類型服務則由全局單元(GDU)提供。