關於中小行核心系統分散式應用架構

02-05

當今互聯網時代，不管規模大小，但凡要上新一代核心系統前都會遇到是否應該建設分散式核心的技術辯論。可以說，正是因為互聯網技術、互聯網思維的突飛猛進，在一定程度上推動著中國金融體系自我改變，也使得中國的信息技術開始走到世界的台前。10年前銀行核心系統還是外國的好，現在國內的銀行核心系統在技術平台和業務模型各方面都已經優於海外產品。

回到本文主題，在我們僅千萬級客戶的銀行核心系統選型中，是否也應該加入當前的互聯網技術狂歡大潮，上一套全新的分散式核心應用？首先我們來對比分析不同應用架構模式的特點。

一、傳統主從架構

如上圖所示，早期應用系統大多採用熱備方式，平時都在一台超高性能的主機上運行所有核心模塊，當發生故障時再由另一台備用主機接替服務。這種架構下，通常要求單台伺服器具有支撐峰值業務量4倍+的性能水平，否則就將銀行的正常業務開展將面臨嚴重威脅。基本上在6年前建成的核心系統較多採用此架構。

二、集群架構

隨著Java的廣泛應用，國內銀行逐漸接受基於JAVA的核心應用，即使不是基於JAVA開發的核心產品，已大多已經具備集群化部署、服務化設計的架構思想。n

如上圖所示，核心各模塊仍然在同一個應用內，採用並置式集群部署，這樣一來通過增加應用伺服器數量即可擴展處理能力。資料庫層面也大多採用集群部署（例如ORACLEnRAC），使得資料庫的並行處理能力和冗餘性都得到提升。這種架構在解決性能可伸縮性的同時，技術複雜度並沒有顯著增加，每次交易請求處理鏈上的各模塊、各業務處理邏輯在實踐上仍傾向於在一個伺服器本地完成，以保證事物的簡單性，使得在部署大量應用伺服器的同時，不會導致事物不一致問題。這很符合傳統銀行對交易實時一致性的嚴格要求。

三、分散式架構

近段時間互聯網化非常流行，銀行核心系統的互聯網架構長成什麼樣呢？目前從技術平台上來看，「互聯網化」的重點並非是把銀行核心放在互聯網、雲端運行，而是參考先進的互聯網分散式架構的一系列設計思路，設計適合銀行的核心系統架構。

在技術上，當前新型分散式核心系統架構主要著力於服務分層、服務分區、關聯服務調用解耦以及資料庫分庫分表等方面，換句話說相對於把所有模塊、服務都一攬子打包成一個應用然後再複製N套做成集群的架構模式，這一代的架構重點在於對核心內部服務進一步層次化、細粒化，然後按層次、模塊分別打包成獨立的小應用，每一小應用作為一個獨立的部署單元，分離後的小應用之間可通過遠程請求方式或共享服務組件方式完成跨應用調用。

如上圖所示，核心系統內部服務走向微粒化、單一化、標準化，並根據粒度進行分層，上層完成對下層的服務組合。在設計服務時，不需關注所依賴的服務是否在本地，統一通過註冊中心（或多級註冊中心）完成服務定址並調用。實際銀行在實施時，由於銀行自身的訪問壓力不足以需要複雜的多級、多片式服務分布部署，因此仍然會因對事務的一致性嚴格要求，在進行應用分包時儘可能包含所有依賴的服務，使其整個依賴鏈都在同一應用內部，這就使得分散式系統平台退化到了具備分組服務控制能力的集群應用架構，這一退化不僅規避了事物一致性問題，更重要的是後期運維成本也並沒有實質增加。

綜上，在技術平台上，核心系統架構可以做得非常複雜，然而於我們來說並沒有什麼實際用處，理性的選擇就是積極地設計更先進、更完善的平台，謹慎地規劃決策目標應用和部署架構。

本文是在互聯網與金融大混沌的背景下，淺談銀行與互聯網接軌的IT路徑中需要探討的分散式架構問題。不得不說，實際上這不是我認為的新形勢下新一代銀行核心架構的重點所在。