銀行核心系統如何應用分散式架構
相對於主機集中式架構，以X86 和雲端計算為基礎、以資料切分為特徵的現代分散式架構在擴充套件性、低成本、降低執行風險等方面的優勢明顯，已經成為主流的聯機交易系統架構方案。
3401
相對於主機集中式架構，以X86 和雲端計算為基礎、以資料切分為特徵的現代分散式架構在擴充套件性、低成本、降低執行風險等方面的優勢明顯，已經成為主流的聯機交易系統架構方案。本文針對分散式架構在銀行核心業務系統中的應用，分享了分庫分表、讀寫分離、資料共享和訪問效能優化、高效運維等關鍵技術方案設計要點。
分散式架構概念
各大型國有商業銀行經過十多年的發展，都已經實現了資料集中，而且，隨著客戶服務的不斷髮展和提升，各家銀行核心業務系統的賬戶量和交易量都已經達到了超大規模，系統的處理能力和效能以及可用性、可靠性、資料一致性、業務連續性等要求極高。在這個過程中，集中式架構發揮了重要作用，各家銀行的核心繫統基本都構建在集中式架構之上，尤其以大型主機架構為代表。集中式架構下，一般採用縱向擴充套件的方式即通過增加單機的資源配置來提升系統的處理能力。通過硬體裝置和基礎軟體的叢集機制來提升系統的可用性。
本文談及的分散式架構是指近年來興起於網際網路公司的一種現代分散式架構。分散式架構以X86和雲端計算為基礎、以資料切分（Sharding）、讀寫分離為特徵，採用橫向擴充套件的方式，通過增加伺服器的數量，提升系統的處理能力，每個節點都是一個可獨立執行的單元，失效時也不會影響應用整體的可用性。另外，系統可以分散到多個節點執行，降低了對單節點的處理能力和可靠性要求，給使用X86伺服器替代高效能的主機和小型機伺服器創造了條件，可大大降低基礎設施的投入成本。
長期以來，銀行核心業務系統一直是安全、穩定、可靠的典範。但採用集中式架構的核心業務系統建設費用和運營成本昂貴，隨著銀行業競爭的加劇，特別是面對採用了低成本分散式架構技術的網際網路公司向金融領域的滲透，各大銀行都在探索主機遷移方案以節約成本。更大的挑戰是隨著銀行經營轉型和業務拓展，核心業務系統的規模急劇擴大，支援的交易模式也更加複雜，核心業務系統處理能力的瓶頸逐漸凸顯，需要採取有效措施降低主機負荷，控制執行風險。因此，將分散式架構應用於核心業務系統必然成為各大銀行應對上述雙重壓力的一種選擇。
困難和挑戰
由於分散式架構採用了單體處理能力較小、可靠性較低的常規伺服器，與主機或小型機相比存在一些弱點，要將分散式架構應用到銀行核心業務系統中，將面臨以下困難和挑戰。
1.併發處理能力。採用分散式架構的銀行核心業務系統一般採用兩層結構，即應用伺服器層和資料庫伺服器層，按照SOA的設計原則，部署在應用伺服器層的業務邏輯採取服務化和無狀態的處理，易於實現橫向擴充套件。而資料庫伺服器層採取分庫分表、讀寫分離的策略實現處理能力的擴充套件，如何提高資料庫伺服器層的併發處理能力是分散式架構在銀行核心業務系統應用面臨的最大挑戰。
2.可用性水平。高可用性是銀行核心業務系統最重要的執行指標。各大銀行之所以仍然採用主機集中式架構構建核心業務系統，最主要的原因是開放平臺比主機的可靠性要低。分散式架構下使用的X86伺服器可靠性更低，由於應用伺服器層採取了負載均衡及高可用設計，其總體可用性可以達到更高標準。而資料庫層採用分庫分表和讀寫分離技術後，也更有利於提高資料庫總體可用性，但基礎設施包括雲平臺及網路、儲存以及複製、同步軟體的可用性將成為主要挑戰。
3.交易一致性。
4.運維複雜度。分散式架構下，採用大量的X86伺服器來實現主機或小型機才有的處理能力和高可用性，使得系統的伺服器數量急劇膨脹，應用結構和關聯關係更為複雜，給運維工作帶來巨大挑戰。
解決方案
分散式架構的核心在於“分”，難點在於“既要能分，也要能合”。下面是分散式架構中幾個關鍵技術方案的設計要點。
圖1 分庫分表概念模型
1.分庫分表策略。常見的分庫分表策略包括垂直切分和水平切分。垂直切分是指從業務分析入手，將系統按照不同的業務功能，劃分為一些相對獨立的子系統或模組。水平切分是指按照一定的邏輯，將資料表按照分割槽鍵值進行切分，實現資料的分散式儲存。
多數場景下都需要將垂直切分和水平切分聯合使用，先對資料進行垂直切分，再針對場景下資料訪問特徵選擇性地進行水平切分（如圖1所示）。
2.資料分佈演算法。可以使用SBF資料分佈模型解決分庫分表的問題（即Shar d i n g K e y分割槽鍵-DataBucket資料桶-TableFamily表族）。其核心思想是應用資料邏輯態與物理態的隔離，從請求資料識別出分割槽鍵，然後應用演算法確定資料桶的編號，相同編號的資料桶形成一個表族。最後將資料桶對映為物理資料庫的表，然後根據資料庫的數量，將所有的表族均勻分佈到各物理資料庫中。
採用一致性“雜湊演算法”來分庫分表，其核心是將要分佈的資料經過計算對映到一個具有0～（232-1）的資料空間中，形成一個閉合的環形。然後將物理節點也通過“雜湊演算法”對映到這個環上，以順時針方向將所有的物件儲存到離自己最近的物理節點上（見圖2）。
圖2 使用SBF 資料分佈模型解決分庫分表問題
將該演算法應用於核心業務系統的資料庫分庫分表場景下，最重要的就是讓應用的資料訪問模型與演算法特徵、資料庫特徵和資料庫物理部署相結合，充分發揮一致性“雜湊演算法”的優勢。
3.資料訪問路由。資料訪問路由模組的功能是將資料分佈演算法嵌入到交易流程中，使應用能夠透明地訪問對應的資料庫分庫和分表（如圖3所示）。
圖3 資料訪問路由模組的功能設計
首先，需要在請求接入時確定應用的分割槽鍵，輸入是服務的請求資料，然後根據應用場景的不同嵌入分割槽鍵的識別邏輯，實現分割槽鍵的轉換功能。轉換後的分割槽鍵和計算的桶編號需要寫入本交易的記憶體區，用於後續的分庫分表處理。
其次，採用統一的應用訪問資料庫介面實現資料庫訪問層，在資料庫訪問層嵌入資料訪問路由邏輯。核心功能包括SQL的解析和重寫、多資料來源管理、單庫資料訪問介面等，通過幾個模組的協作就可以完成資料訪問路由的決策、分發和執行。
4.資料重分佈。資料重分佈是分庫分表後的基本能力要求。重分佈過程應該以最大程度地保證應用可用性為前提，避免因為重分佈導致全量資料的重組。從服務視角來看，每一次的服務呼叫，都是針對單一的資料記錄進行操作，資料表中儲存的也是資料記錄。基於關係型資料庫進行資料重分佈，最好的方式並不是通過記錄，而是通過表。將重分佈的顆粒度定義到表級別，可以利用資料庫的匯入匯出工具，大大提高資料重分佈的效率，降低對系統可用性的影響。
5.資料聚合。跨庫查詢是分庫分表模式下最為典型的應用場景，解決的思路是將查詢下發到所有的資料庫執行，然後再對結果集進行合併和篩選。方案主要包括並行執行排程、多分割槽鍵識別和重組、執行緒池管理、多資料來源管理和資料訪問介面、SQL解析和執行計劃優化、結果集合並篩選等幾個模組。
6.資料共享和訪問效能優化。對於讀多寫少的公共資料，可採用分散式快取技術實現資料共享，優化訪問效能。
但應用快取也有一個問題，即快取的資料都儲存在記憶體中，如果出現伺服器宕機和程序異常退出的情況，極有可能造成資料丟失。在應用時應該遵循以下幾條原則：一是應用快取的交易必須具有大併發量的特性，放在快取的資料應當滿足只讀且使用頻繁的條件；二是由於銀行業務對可用性的要求，在使用快取時要在設計時做到應用的高可用，一旦快取出現問題，應用要能夠無縫切換；三是將快取元件整合到資料訪問層，避免對整體業務邏輯的影響。
7.讀寫分離。資料存在多個副本，包括一個主資料庫和多個從資料庫。主庫負責資料更新和實時資料查詢，從庫負責歷史和準實時的資料查詢。分散式架構設計時，可從下面幾個層級實現讀寫分離機制。
元件級：從服務的維度將歷史查詢和準實時查詢從核心應用的主庫中隔離出來，在企業級服務匯流排（ESB）實現元件和交易級的服務路由選擇，從而在元件級實現讀寫分離的要求。
聯機服務級：當交易請求通過ESB到核心業務系統後，在請求接入層進行資料訪問路由選擇，實現交易服務資料訪問的讀寫分離。
資料訪問層級：在資料訪問層中實現對於SQL語句的解析和識別，如果是可以訪問讀庫的查詢功能，則可通過多資料來源管理模組路由到讀庫訪問，降低主庫的處理壓力。
8.可用性保證機制。應用分庫分表後，在大幅提升系統處理效能的同時，規避了大型單一集中式資料庫的執行風險。可以採取以下幾個可用性保證機制。
故障隔離機制：通過“SBF”資料分佈模型，準確地識別資料桶編號與物理資料庫的對應關係，快速地通過改變物理資料庫可用性的標識，實現故障隔離。
叢集架構：每個分庫仍然應該保持叢集架構，利用關係型資料庫管理系統的高可用機制進一步提升分庫的可用性水平。
資料庫的災備：可以部署災備資料庫，保證極端情況下資料庫層的可用性。
9.高效運維。建立分散式架構下的高效運維體系，在資源供給、應用部署、集中監控、故障診斷和應急處置等方面提升自動化水平，是確保分散式架構能夠應用和推廣的必要條件。
一是通過雲平臺封裝標準PaaS雲服務，可實現多套資料庫、中介軟體服務的快速供給及動態伸縮，還可根據主備庫配置關係，實現日常檢查、一鍵式切換、服務啟停、資料遷移、軟體分發、配置管理等自動化操作。二是通過集中監控系統實現從基礎設施到應用的全面事件和效能監控，採用規則引擎、視覺化引擎、工作流引擎實現事件智慧化分析、展現、處置及資訊推送，為分散式架構下的快速故障定位、故障自愈和應急處置提供有力的保障。三是通過應用監控系統可度量元件間可用性、效能、流量等指標資料，從而實現端到端交易監控，並實時展現各元件的交易效能、元件間呼叫關係、追蹤單筆交易路徑。四是通過大資料技術實時分析系統、資料庫、中介軟體等基礎服務和應用服務的效能、容量，動態調整資源，提高資源利用率。
分散式架構轉型路徑
按照整體規劃、分步實施、風險可控的策略，推進系統從集中式架構向分散式架構轉型。
1.整體架構設計。“新一代”架構的基本特徵是企業級、元件化和麵向服務，在架構分層的基礎上，建設12個應用平臺，承接業務架構建模成果，將115個業務元件所對應的應用元件部署在平臺上，元件之間通過標準化的服務和事件驅動架構（EDA）進行互動。可以說，應用的解耦為分散式架構的採用提供了極大便利，分散式處理是“新一代”架構所具備的重要能力之一。
2.合理選用平臺架構。根據整體架構設計，我們將115個應用元件絕大多數在開放平臺上部署，只保留極少的關鍵核心應用（如存貸款、借記卡、貸記卡等）在主機平臺上。
一是對於客戶積分管理這類應用，將其全部功能部署在分散式架構平臺上。二是對於客戶資訊這類查詢交易為主的應用，將客戶資訊的維護操作保留在主機上，將客戶資訊查詢下移到分散式架構平臺上。三是對於對私存款與借記卡這類應用，其交易量大，資料一致性要求高，目前還很難將其全部遷移到分散式架構平臺。基於讀寫分離的原則，將涉及客戶合約、賬戶、介質維護類的交易保留在主機平臺上；將對合約、賬戶、介質、以及交易明細的查詢交易部署到分散式架構平臺。主機和分散式平臺之間的資料採用日終批量或準實時方式同步。
在元件化、SOA架構特點下，元件之間的服務呼叫不可避免，因主機技術特點限制，其外呼能力較弱，將此類需要組合主機上存款借記卡服務和開放平臺服務的組合場景部署到分散式架構平臺，通過交易一致性事中和事後機制保證業務一致性。
3.分散式架構平臺研發與應用。如本文所述，將分散式處理的一些關鍵技術應用在基於X86的分散式架構平臺研發上，使其具備高併發、高可用、可擴充套件的能力。建設銀行基於分散式架構的應用已經成功開發和投產，以客戶積分管理應用為例，“新一代”3.2期投產後，積分管理的客戶數超過6000萬，賬戶數9000萬，經過分庫分表處理後，資料分佈到1024套表中，每套表約儲存12萬左右的賬戶記錄和相關明細資料，聯機日均交易量約為1300萬筆，峰值TPS約750，交易平均處理時間約60ms。
4.持續推進分散式架構平臺應用。分散式平臺的應用顯著提升了IT自主可控研發能力，降低了IT成本，下一步將從四個方面深化其應用：一是嘗試將貸記卡這類核心應用整體遷移到開放分散式平臺；二是推進主機上存款、借記卡、客戶資訊這類核心應用功能繼續向開放分散式平臺遷移；三是將一些具有“秒殺”交易特徵、突發交易量大的基於小型機的集中式處理系統向x86分散式平臺遷移；四是完善分散式架構災備方案，實現分散式架構平臺多活。
結語
實踐證明，商業銀行通過自主設計、自主研發的方式實現分散式技術的應用是可行的。銀行引入分散式技術，應對網際網路行業競爭，應發揮在網路資源、經營物件、資訊保安及線下服務的優勢，堅持以自身為主做“銀行+網際網路”、以開放的態度謀求合作性競爭、以“客戶體驗至上”為宗旨設計產品提供服務、以積極穩妥的態度推進分散式架構的建設，不斷提升銀行IT的管理和技術水平。