01

為什么需要云單元架構

云單元架構是在微服務架構上發展起來的解決 IT 系統擴展性及業務連續性的技術架構，它并不是隨著微服務架構一起誕生的，而是 IT 系統發展到一定規模且對業務連續性有高要求的情況下需要具備的技術能力。

從集中式架構到分布式架構

傳統的集中式 IT 系統架構如下圖所示，由小型機（比如 IBM 的 P 系列等）、存儲設備（EMC 的 VNX 系列等）、硬件負載均衡設備（典型的比如 F5）等基礎設施構成，這些硬件設備具備很強的穩定性，因此在金融行業這些產品具有很高的市場占用率。

隨著金融行業新業務的不斷擴展，集中式架構的弊端逐漸顯現出來，比如小型機雖然性能足夠強大，但是面對突增的業務，處理能力往往很難快速提升。F5這類硬件負載均衡設備，雖然單機處理能力足夠強大，但是成本高昂，無法進行大規模冗余化配備以保障其可用能力。此外，類似 EMC 這樣的高端存儲設備，在面向海量數據的情況下，單位存儲成本巨大，在擴展性上也無法與采用 PC 的分布式存儲相比。因此，在金融行業的一些新業務場景甚至部分非核心系統上，原有的架構已經開始嘗試向分布式架構演進，如下圖所示。在分布式系統架構下，普通的 PC 機取代了小型機，用來部署應用系統，通過多機部署，應用系統的冗余能力大幅提升，單機故障的影響也隨之大幅降低。在流量負載上，分布式架構往往會引入軟負載能力，通過軟件實現流量的負載均衡，確保在流量路由層面也具備更好的冗余能力。在數據庫層面，隨著 MySQL 這類開源數據庫的廣泛使用，在金融行業分布式系統架構演進過程中，這種類型的數據庫也逐漸取代了一部分 Oracle 數據庫，成為應用系統數據存儲的關鍵組件。

分布式系統架構演進

分布式系統架構的演進并不是一蹴而就的，根據業務在不同發展階段的需求，分布式系統的架構需要根據實際情況做出相應的變化。通常，一個分布式系統架構的演進往往會經歷這些歷史階段：單體架構、應用與數據庫服務器拆分、緩存/搜索的能力引入、數據庫讀寫分離、數據庫水平/垂直拆分、應用拆分、微服務化等。當然，并不是所有的系統都會經歷全部這些階段，一些較為核心的系統可能會跳過前面幾個階段，直接用已經成熟的微服務架構來搭建服務。

02

微服務架構下的容災和容量問題

容災問題

分布式架構在一定程度上將業務系統的計算能力和數據進行拆分，并通過負載均衡系統將流量按照一定規則路由到不同的節點進行處理，因此，在分布式架構下系統的處理能力不再是“單點”的。隨著微服務架構的升級，應用變得更加輕量化，系統的單機“自愈”能力能夠得到充分的利用，應用在出現一些單機問題時往往可以通過快速重啟等手段迅速恢復業務。但是，單機恢復能力并不一定在任何故障場景中都能適用，在出現城市級斷電或者網絡故障等極端場景中，應用系統往往不是一臺機器出現問題，而是這個區域的所有服務都出現問題。這個時候，如果沒有一種災備恢復機制，保障所有服務可快速切換到新的服務區域，業務系統的恢復時長將會變得非常不可控。因此，核心系統的同城/異地災備能力建設顯得尤為重要。為了使業務系統具備更高的風險抵抗能力，在進行機房選址時，往往會選擇一個距離較遠（超過 1000 千米）的機房作為其中的一個災備機房，如下圖所示。當發生城市級故障時，業務系統需要具備隨時可切換至城市二機房的能力。但現實情況是，由于城市二機房長時間沒有流量進行常態化驗證，業務流量切換過去以后并不能百分之百保障業務處理沒有問題，因此，這種情況下的容災切換往往需要冒著較大的風險。

容量問題

在分布式系統架構下，應用服務的服務器隨著用戶需求的增長不斷進行橫向擴展，單個應用的機器數變得越來越多，由于用戶流量是通過負載均衡隨機分配給每臺機器的，因此這個應用的每臺機器都會跟數據庫建立起一定數量的連接，這就導致隨著應用容器的增長，終有一天應用訪問會達到數據庫的連接數上限。如下圖所示，單個 DB 承載的連接數通常跟操作系統的線程數上限有一定關系，假設每臺機器增加 100 個連接，單個 DB 的連接總數總有一天會被占滿。

03

云單元架構的誕生

云單元架構是指在多機房部署架構下，對業務處理能力進行邏輯上的單元劃分，使業務流量按照一定規則分配到各個單元中，同時盡量確保用戶流量始終收斂在一個單元內完成的架構。在云單元架構下，每個單元的流量會按照特定的規則分配到不同的應用容器中，同時通過分庫分表規則路由到不同的數據庫分庫，如下圖所示。由于每個單元的容器數量有限，因此，單元內的服務器擴容不會導致數據庫達到連接數上限。同時，通過單元的新增，又可以保障系統容量可以進行理論上的無限擴展。

云單元架構總覽

云單元架構的核心是通過單元化部署使整體架構具備異地多數據中心并行計算能力，同時基于金融級的分布式關系型數據庫，通過多機房部署實現城市級故障下數據無損容災切換。通過云單元架構擴展能力，業務可以在不同地域的 IDC（Internet Data Center，互聯網數據中心）中部署多個 LDC（Logic Data Center，邏輯數據中心），且每個 LDC 單元都是“活”的，日常承接線上真實業務流量，以確保每個邏輯單元的穩定性與業務正確性。當故障發生時，可以進行 LDC 單元之間的快速切換，一個 LDC 單元對應的災備 LDC 單元也是一個“活”的單元。為確保異地機房能日常承載業務流量，實現了跨機房的服務注冊與發現能力，提供了跨機房的服務調用路由邏輯，從入口流量到分布式服務、中間件和底層數據庫，全鏈路消除了單點，使整體服務都具備了跨機房、跨地域的擴展能力。網商銀行總體架構如下圖所示。

04

云單元架構目標

云單元架構的設計目標主要包含以下幾個方面：（1）具備系統跨地域、快速彈性部署的能力；（2）具備流量可隨時動態調配的全業務“多地多活”的能力；（3）具備一體化研發運維能力；（4）具備海量業務并行處理的能力。

跨地域彈性部署

在分布式服務設計領域，一個云單元就是滿足某個分區所有業務操作的自包含集合體。這個集合體可以按照用戶、地域、業務類型等不同維度進行單元化的數據拆分和獨立部署。基于這種單元化的部署能力，可以靈活地進行多地、多數據中心的建設，如下圖所示。

有了對邏輯單元的快速搭建和部署以及一鍵單元建站能力，在未來面臨大容量需求時，可以通過在云計算平臺上快速進行資源調度，構建新的處理單元來部署應用與數據庫，然后將流量與數據“彈出”到新的單元，快速提升系統容量。當流量消失后，再將流量與數據“彈回”，釋放云計算平臺上的資源，動態地擴充單機房容量。當單機房容量不夠時，通過增加新的異地 IDC 機房擴充總體容量，總體容量不受距離、地域以及物理資源的限制，真正實現了彈性、單元化的部署能力。多機房流量分布如下圖所示。

全業務“多地多活”

云單元架構的核心目標之一是保障銀行在多個城市（不同城市之間距離超過1000 千米）的邏輯單元都具備處理全量業務的能力，只有這樣才能充分利用各城市的存儲、計算等資源，同時又能在出現城市級故障時，某個邏輯單元的用戶可以被其他城市的 IDC 所接管，繼續為用戶提供服務。

在形成單元化彈性部署的能力的基礎上，不同邏輯單元之間可以將分區對應的流量根據邏輯單元資源的負載情況靈活調整，通過流量調撥，將不同用戶的請求分發到不同的數據中心進行處理，所有數據中心同時承載業務流量，達到全業務“多地多活”服務模式。這種模式結合異地機房的資金清算專線鏈路的打通，可以保證任一機房級故障均不影響銀行業務的整體對外服務。全業務“異地多活”模式如下圖所示。

一體化研發運維

在建設“多地多活”技術架構體系的過程中，原有研發平臺已經不能適應新的架構體系，需要建設新研發協作平臺來支持架構升級，同時顯著提升需求迭代效率，以及質量、風險控制水平和產能。通過打造全新的一站式研發協作平臺，實現了端到端的全流程、全角色的持續交付管理，將需求迭代、代碼開發、發布管控等流程并行處理，并在關鍵節點上建立了同步機制，業務需求方、產品設計人員、項目管理人員、開發測試人員能夠統一在一個研發協作流程中，完成高效協同工作。研發人員在平臺上可以靈活地獲取測試需要的服務器資源，平臺提供一鍵部署研發服務器的能力，支持快速搭建項目環境，高效地在多個環境中完成基礎配置變更（主要是中間件的一些配置），在完成流程審批后，可以將該版本發布到多個環境中，從線下到線上全流程無縫對接，構建一站式持續交付能力，減小“異地多活”技術架構體系在配置修改、環境構建和發布部署等方面帶來的復雜度。

海量交易處理能力

隨著 IoT（物聯網）技術的迅猛發展，未來將從互聯網時代步入萬物互聯時代，無處不在的交易終端和無數新的交易場景，會繼續帶來金融交易量的指數級增長。什么樣的架構與技術可以處理萬物互聯時代的海量交易，是需要未雨綢繆的。

云單元架構要解決的一個核心問題是海量交易的處理能力問題，大多數業務并不是一誕生就具備海量用戶的，交易量是逐漸增長的，那么在架構上我們既需要具備一定的前瞻性，又需要具備針對不同量級的業務進行分級實施。比如在設計上要支持全行單日百億筆以上的處理量，實現上會支持 10 億筆處理量，部署上會支持 3 億～5 億筆處理量。

在數字化時代的當下，金融需求出現了場景化、碎片化、多樣化、長尾化、普惠化的新特點，百年未有的變化沖擊著傳統金融級IT架構。

• 新金融級IT架構應該包含什么樣的新能力？

• 關鍵挑戰是什么？

• 如何進行穩妥升級轉型？

• 新興技術如何支撐金融級架構演進？

• 核心金融系統如何保證風險可控？

• 業務架構如何適應數字化要求？

• 信息安全建設如何為業務和技術發展保駕護航？

為了幫助同行在了解浙江網商銀行（以下簡稱“網商銀行”）IT發展歷程的同時，也能獲得一些解答上述問題的啟發，網商銀行技術編委會特地寫就了《金融級IT架構：數字銀行的云原生架構解密》一書，期望能給同行帶來一些可參考、可借鑒、可落地的經驗。

如果你想了解更多金融級IT架構的構建細節，本書一定不可錯過！

往期推薦

漫畫：據說很多搞軟件的羨慕硬件工程師

一線大廠的企業云原生成本優化實踐指南

源三：聊聊注冊中心在螞蟻集團的降本提效之路

聊聊技術人的“績效考核”

敏捷效能提升的五大要素與誤區

總結

以上是生活随笔為你收集整理的数字化转型下的银行云单元架构的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。