金融級IT架構：數字銀行的雲原生架構解密（簡體書）

當前，伴隨著移動互聯網的不斷發展、智能設備的不斷普及，人類社會正在加速邁入以開放、共享、協作、智能為特征的數字化時代，以云計算、大數據、人工智能、區塊鏈、物聯網、5G、虛擬現實等為代表的新一代信息技術蓬勃發展，正以前所未有的速度和力量，改變著人類社會的生產方式和人們的生活方式，推動著商業模式與技術的深度融合，科技作為第一生產力得到了進一步強化和發展，推動著全球社會形態、生產關係、經濟格局和競爭態勢發生深層次的變革。

在數字化時代，數據不僅變得越來越龐大，而且也更具多樣性，價值也越來越大，數據已成為驅動新經濟發展的“石油”，數據的重要性得到越來越多的共識。海量的數據中蘊藏著無限商機，洞悉數據未來，對數據進行有效的獲取、合理的分析和妥善高效的利用，企業將獲得更多的發展契機，形成競爭力，從而占領市場先機。國際數據公司（International Data Corporation）於2017年發布了《數據時代2025》白皮書，書中預測未來數據量的增長速度驚人，2025年全球的數據量將達到163ZB（Zettabyte，十萬億億字節，澤字節），數據來源以及數據量的劇增引起的應用趨勢也會產生變化，這是數據未來發展的大勢所趨。

中國互聯網絡信息中心（China Internet Network Information Center，CNNIC）2020年發布的第45次《中國互聯網絡發展狀況統計報告》顯示，我國網民規模為9.04億人，互聯網普及率達到64.5%，數量龐大的網民推動著中國的消費市場蓬勃發展，為數字經濟的發展奠定了堅實的用戶基礎。數字經濟中新業態、新模式不斷涌現，已成為經濟發展的新動力和新增長點。2020年春，在新冠肺炎疫情的影響下，很多行業遭遇了一場重大的生存考驗，受疫情影響，個人的生活消費習慣有很大的改變，“非接觸式”服務激增，對金融行業而言，很多人減少了去金融機構線下網點辦理業務的次數，盡可能選擇在線辦理業務，這也是一次前所未有的極端外部力量對金融產品、運營、風險管理、信息科技等進行的全方位的壓力測試。

危險往往與機遇相伴，這次疫情加速了金融機構的在線化和數字化轉型，部分數字化能力領先的金融機構取得了積極性的成果，金融服務正在逐步弱化對物理網點柜臺的依賴，《銀行4.0》作者布萊特·金（Brett King）提到的“銀行服務無處不在，就是不在銀行網點”正在變成現實，金融業數字化轉型是大勢所趨。在數字化時代的當下，金融需求日漸多樣化，業務創新日新月異，數字化進程對金融業的影響愈加深遠，金融行業需順應時勢，積極擁抱新技術，重構新業態，進行數字化、智能化、普惠化、開放化轉型，不斷提升數字經濟服務能力，使其覆蓋更多受眾。移動化的高普及率、龐大的用戶規模、巨大的人口紅利，使得我國金融行業所面臨的業務類型、數據量、並發量都與國外存在巨大的差異，對IT基礎設施和架構的要求也存在巨大的差異，銀行業與科技的融合日益加深，在推動銀行業深化轉型的同時也對銀行業信息科技風險、信息安全、業務連續性等方面的管理能力提出了更高的要求。

在數字化時代的當下，金融需求出現了場景化、碎片化、多樣化、長尾化、普惠化的新特點，百年未有的變化衝擊著傳統金融級IT架構。新金融級IT架構應該包含什麼樣的新能力？關鍵挑戰是什麼？如何進行穩妥升級轉型？新興技術如何支撐金融級架構演進？核心金融系統如何保證風險可控？業務架構如何適應數字化要求？信息安全建設如何為業務和技術發展保駕護航？我們希望本書可以幫助同行在了解浙江網商銀行（以下簡稱“網商銀行”）IT發展歷程的同時，也能獲得一些解答上述問題的啟發，期望能給同行帶來一些可參考、可借鑒、可落地的經驗。

網商銀行依托於阿裡巴巴集團和螞蟻集團多年來沉澱的云計算和分布式底層平臺技術，從籌建之初就將所有核心業務系統以分布式的架構創建於云平臺之上，是中國第一家將核心系統架構在云計算和分布式數據庫上的銀行，具備自主可控、彈性化和安全可信等諸多特性，實現了可伸縮、高可用的服務計算能力，能夠做到彈性資源分配與訪問管控，具有處理海量數據及高並發金融交易的能力，使網商銀行可以為用戶提供隨時隨地、便捷的金融服務，利用互聯網和大數據的優勢，給更多小微企業提供金融服務。

在移動互聯網背景下，銀行業務更新換代速度加快，業務需求研發迭代周期大大縮短，應用變更變得非常頻繁。網商銀行自成立以來，在技術演進方面一直密切跟蹤最新技術發展趨勢，在IT體系建設上持續開展了大量的探索和實踐工作，銳意進取，勇攀技術高峰，經歷了多輪技術“底盤”升級換代，由早期的“同城雙活”到“兩地三中心”再到如今的“三地五中心”，依托螞蟻集團在分布式架構領域多年的技術沉澱，特別是金融云架構、單元化機制、精細化路由控制、OceanBase分布式數據庫等技術，建成了云上的“異地多活”容災體系。“異地多活”容災體系的建成，使網商銀行具備“隨時隨地、按需擴容、隨時切換”的全業務容災能力，大大提升了業務連續性保障能力和用戶體驗水平。中國人民銀行印發的《金融科技（FinTech）發展規劃（2019—2021年）》提出合理布局云計算，統籌規劃云計算在金融領域的應用。隨著云計算技術的不斷發展，云原生技術日趨成熟，云基礎設施的重大變化帶來研發場景、軟件生產模式的一系列變革，網商銀行密切關注業內發展趨勢，從2019年開始規劃云原生和安全可信架構的落地，迎接云原生時代的到來，為業務發展提供安全、穩定、高效和敏捷的基礎設施。本書將從多個方面闡述網商銀行多年的實踐經驗，希望能最大程度上呈現“幹貨”，確保讀者“開卷有益”，助力行業技術發展。

最後，我謹代表本書的作者們，向所有陪伴網商銀行成長的用戶，以及網商銀行所用的阿裡巴巴集團和螞蟻集團技術產品的研發者和運維保障者們致敬，正是廣大網商銀行的用戶帶動了業務發展，進而驅動了技術發展，而正是技術產品的研發者和運維保障者們打造的技術方案、產品和沉澱的經驗成就了本書。感謝所有來訪網商銀行進行交流的同行，正是你們的到來孕育了本書，我們希望本書能彌補現場受限於多種因素而不能充分交流的遺憾。感謝所有參與和支持本書創作的人員，感謝參與本書出版的以張彥紅、高麗陽編輯為代表的電子工業出版社所有成員，沒有你們本書不會面世。謝謝大家。

蔣易民

網商銀行信息科技部基礎技術架構部負責人

2021年5月於杭州

第1章金融級架構面臨的挑戰

1.1 容災

1.1.1 數據容災

1.1.2 應用容災

1.1.3 業務容災

1.1.4 部署結構

1.2 容量

1.2.1 應用可伸縮

1.2.2 數據可伸縮

1.2.3 數據中心可伸縮

1.3 成本

1.4 安全架構挑戰

1.5 研發運維效率

1.6 技術風險防控

1.7 應對思路

1.7.1 微服務

1.7.2 “異地多活”單元化

1.7.3 彈性架構

1.7.4 云計算

1.7.5 云原生

1.7.6 安全架構

1.7.7 技術風險防控

第2章云基礎設施架構

2.1 金融基礎設施的機遇和挑戰

2.1.1 金融基礎設施的窘境

2.1.2 云計算助力數字金融

2.2 云產品選型

2.2.1 云服務器

2.2.2 云存儲

2.2.3 總結

2.3 云網絡規劃

2.3.1 網絡拓撲整體設計

2.3.2 專有網絡VPC

2.3.3 IP地址規劃

2.3.4 總結

2.4 云產品架構

2.4.1 整體架構

2.4.2 高可用架構

2.4.3 SWIFT架構

2.4.4 總結

2.5 云資源規劃

2.5.1 建設階段

2.5.2 運營階段

2.5.3 總結

第3章存儲架構

3.1 數據庫部署架構

3.1.1 分布式數據庫

3.1.2 “異地多活”之“三地五中心”

3.1.3 數據訪問路由策略

3.1.4 多集群部署

3.1.5 容器化部署

3.2 數據庫邏輯架構

3.2.1 分庫分表

3.2.2 數據源高可用

3.2.3 歷史庫

3.3 緩存架構

3.4 存儲鏈路分析

3.5 架構演進

3.6 數據安全

3.6.1 備份恢復

3.6.2 存儲加密

第4章云單元架構

4.1 為什麼需要云單元

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

4.1.2 分布式系統架構演進

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

4.1.4 云單元架構的誕生

4.2 云單元架構總覽

4.3 架構目標

4.3.1 跨地域彈性部署

4.3.2 全業務“多地多活”

4.3.3 一體化研發運維

4.3.4 海量交易處理能力

4.4 云單元架構的特征

4.4.1 架構特征

4.4.2 邏輯架構

4.5 單元化改造主要思想

4.5.1 分而治之

4.5.2 D-I-D原則

4.5.3 十三條原則

4.6 單元化流量路由

4.6.1 路由規則設計

4.6.2 HTTP流量路由

4.6.3 RPC流量路由

4.6.4 消息流量路由

4.6.5 調度流量路由

4.6.6 數據流量路由

4.7 應用與數據單元化

4.7.1 分布式應用

4.7.2 分布式數據

4.8 分布式中間件

4.8.1 基礎開發框架

4.8.2 微服務平臺

4.8.3 分布式數據訪問代理

4.8.4 分布式可靠事務服務

4.8.5 分布式消息隊列

4.8.6 分布式全鏈路跟蹤

4.9 業務單元化實踐案例

4.9.1 靈活多變的路由決策機制實現

4.9.2 如何優雅地過渡到單元化架構

4.9.3 如何實現跨地域單元數據一致性

4.10 總結與展望

第5章混合云彈性架構

5.1 彈出

5.1.1 無狀態彈出

5.1.2 有狀態彈出

5.2 彈回

第6章云原生架構

6.1 架構概覽

6.2 容器技術

6.2.1 不可變基礎設施

6.2.2 容器化實踐過程

6.2.3 集群混部應用

6.3 服務網格

6.3.1 MOSN

6.3.2 DBMesh

6.4 Serverless

6.4.1 Ark Serverless

6.4.2 模塊化開發

6.4.3 任務托管

6.5 云原生研發流程

6.5.1 云原生DevOps

6.5.2 關於配置化的研發效率

6.6 可信云原生

6.6.1 安全可信架構

6.6.2 安全容器

6.6.3 服務鑒權

6.6.4 鏈路加密

6.6.5 數據訪問鑒權

6.7 云原生運維

6.7.1 容器集群運維

6.7.2 Mesh運維

6.7.3 Sidecar運維

6.7.4 Mesh的技術風險防控

6.7.5 發布和運維平臺統一

6.8 云原生實戰場景

6.8.1 混部技術應用

6.8.2 應用鏡像化發布

6.8.3 服務網格技術應用

6.8.4 Serverless技術應用

6.8.5 安全可信技術應用

第7章技術風險防控架構

7.1 多級業務分區發布

7.2 全站自動化變更防控

7.3 資金安全

7.3.1 資金安全簡介

7.3.2 資金安全防線

7.3.3 資金安全防線運營

7.3.4 小結

7.4 全鏈路壓測

7.4.1 壓測鏈路與仿真

7.4.2 容量規劃

7.4.3 壓測風險識別

7.4.4 壓測風險管理

7.4.5 壓測實戰

7.4.6 自動化壓測

7.4.7 云原生全鏈路壓測

7.5 大促技術保障

7.5.1 大促活動保障臺

7.5.2 自動化預案

7.5.3 限流熔斷

第8章業務架構

8.1 數字化轉型下的銀行業務架構

8.1.1 數字化銀行設立初衷

8.1.2 數字化銀行頂層設計

8.1.3 數字化銀行落地過程

8.1.4 數字化銀行效果呈現

8.2 中臺戰略

8.2.1 中臺戰略概述

8.2.2 業務中臺

8.2.3 數據中臺

8.3 大數據與人工智能

8.3.1 數據化風控

8.3.2 智能流動性管理

8.3.3 智能化運營

8.4 金融開放

8.4.1 金融場景開放

8.4.2 金融機構協作

第9章安全可信架構 P369

9.1 安全架構概述

9.2 默認安全機制

9.2.1 問題背景

9.2.2 解決思路

9.2.3 實踐落地

9.3 可信縱深防御

9.3.1 問題背景

9.3.2 解決思路

9.3.3 實踐落地

9.4 威脅感知與響應

9.5 實戰演練檢驗

9.5.1 目標設定

9.5.2 紅隊攻擊規劃

9.5.3 實施演練

9.5.4 實戰演練規範

9.5.5 復盤

9.6 數字化與智能化

第10章未來展望 P403

附錄A 本書插圖索引 P406

4.8.1 基礎開發框架

基礎開發框架是一套用於分布式架構應用系統的快速、敏捷研發框架，擁有一整套全面的技術棧，能自動解決依賴下載、應用部署、健康檢查、運維監控等研發效率相關問題。研發人員使用該基礎開發框架，可將精力集中在業務代碼編寫上。基礎開發框架還能實現對其他常用中間件的集成管理，通過獨立可插拔的集成方式，對集成的中間件提供統一易用的編程接口，節約了開發時間，降低了後期維護成本。

開發框架在某種程度上也可以稱為應用框架，或者一定程度上可以看作應用容器，當然這不一定完全正確。然而應用框架和應用容器總是成對出現的，比如早期的EJB（Enterprise Java Beans，企業Java Beans）技術，EJB可以看作開發框架，但是需要運行在對應的EJB容器之上，例如Jboss、WebLogic、WebSphere等。由於EJB技術的臃腫，後面出現了像Spring、Guice這樣的優秀的輕量級應用框架，配套的也不再是重量級的EJB容器，而是像Tomcat、Jetty這樣的輕量級Servlet容器。

從EJB到Spring、Guice的演進帶來的是業務研發效率的極大提升，然而隨著互聯網的快速發展，業務的復雜度與日俱增，原本單一的應用架構開始向分布式架構演進，分布式架構轉型過程中業務系統無可避免地需要去集成眾多的分布式中間件，以達到分布式架構改造的目的。然而中間件的接入是存在一定復雜度和理解成本的，這會對研發效率造成一定的負面影響，原本提供單一IOC（Inversion of Control，控制反轉）、AOP（Aspect Oriented Programming，面向切面編程）、MVC（Model View Controller，模型-視圖-控制器）功能的Spring無法繼續滿足業務需求。面對挑戰，Spring框架也在快速發展。近些年來產生的SpringBoot面對當前場景給出了不錯的解決方案。與原先的Spring相比，SpringBoot省略了之前大量煩瑣的XML配置，自動裝配機制可以快速集成原本需要大量配置才可以支持的能力，而SpringBoot Starter的出現進一步擴展了這種自動化裝配能力，大量的第三方中間件組件、框架以Starter形式提供相關能力支持，業務如果需要引入每個中間件產品對應的能力，只需要依賴對應產品的Starter即可，再也不需要繁雜的配置以及理解成本，而且可以形成統一的接入規範，可以對公司技術體系的演進和發展起到很好的促進作用。

那麼一個優秀的應用框架到底是什麼樣的呢？這裡提出一個說法——“技術價值觀”，可以理解為，一個企業是否采納某種技術的評判標準，技術價值觀一定程度上左右了這家公司的技術發展和演進方向。和其他價值觀不同，大部分企業的技術價值觀都是一致或相似的，或者說有一個大家公認的標準，這個標準其實可以理解為每種技術在業界的主流發展和演進方向，比如SpringBoot、Kubernetes，它們代表了應用框架和調度的主流技術價值觀。網商銀行內部的應用框架同樣也遵從這個主流的技術價值觀，而且在這之上還有著大量的技術實踐和創新。內部大量使用的開發框架一共有兩個，一個是構建在OSGi（Open Service Gateway Initiative，開放服務網關協議）容器之上的框架技術，內部稱之為SOFA 4，對應的運行容器內部稱之為CloudEngine，另外一個開發框架稱為SOFABoot，SOFABoot構建在SpringBoot之上，是對SpringBoot的有效擴展和優化，同時也是內部特定需求下的產物。這裡重點介紹一下SOFABoot，因為流行的SpringBoot框架更為大家所熟知。

就像前面提到的，SpringBoot的自動裝配機制和Starter擴展機制已經給研發效率帶來了極大的提升，那為什麼還要創造一個SOFABoot框架？它又有哪些優勢？其實這裡並沒有從頭創造一個全新的框架，本質上SOFABoot就是SpringBoot，但是進行了相關功能的豐富和擴展，這主要涉及以下幾方面。

1. 類隔離的支持

類衝突無疑是Java開發者“最大的痛”，有過幾年經驗的Java開發人員應該都有較為豐富的類衝突解決經驗，規範的第二方、第三方依賴可以通過releaseNote進行版本升級，而某些管理不善的依賴只能靠版本試錯，或者逐個反編譯精確查找版本。更有某些場景中的間接依賴和直接依賴產生了版本衝突，解決這種衝突往往需要耗費大量時間，甚至在某些場景中不得不去推動相關依賴方進行升級才能解決，嚴重阻礙了業務的迭代效率。而SOFABoot自身集成了強大的、輕量級的類隔離框架可以完美解決這類問題，通過簡單的配置即可完成對衝突類的隔離，讓你可以專注於業務代碼的開發。

2. 多模塊隔離

大型項目的開發需要有良好的模塊劃分方案，然而傳統的模塊劃分均是以人為規約的形式進行的，而這在實際運行時是很難有約束力的。事實說明，在一個項目迭代的過程中很難長期遵守開發規約，因為一個長久的項目往往會經歷多個研發人員，每個人對研發規約的理解又是存在差異的，久而久之，邏輯的模塊劃分將無法起到很好的作用。說到模塊隔離，大家可能會想到OSGi，但是OSGi本身比較復雜，並不能為大部分互聯網公司所接受，而SOFABoot提供了一種輕量級的模塊隔離方案，每個模塊都是單獨的Spring上下文，每個模塊可以暴露哪些服務能按照規範進行配置，未暴露的服務其他模塊是無法進行調用的，而且獨立的Spring上下文設計給後續服務拆分提供了極大的便利，當前的一個模塊只需要少量的調整就可以作為一個單獨的項目進行開發部署。想一想如果是以邏輯模塊的方式進行劃分，項目拆分會多麼困難和復雜，因為內部服務也可能被多個其他模塊所依賴，光拆分前的梳理和改造就要花費大量的時間，成本無法估計。

3. 部分功能擴展

這裡主要說兩點，一是SOFABoot提供了Readiness檢查能力，SpringBoot提供的HealthCheck只能反映當前系統是否被監控，但是無法反映是否已經做好了可以接受請求的準備。這一點其實是很重要的，比如應用的平滑上下線就比較依賴這個功能，如果在應用還沒達到可以接收請求的狀態之前就把請求發過去，就會引起應用請求的報錯，而對於一個擁有大量容器的應用而言，為了提升發布速度，單個發布批次會包含較多的容器，如果這裡處理不好，就會引起服務調用方的抖動，甚至對業務造成影響。

二是支持了日志空間隔離，依賴日志空間隔離可以方便有效地對日志進行隔離管理，比如網商銀行內部的中間件系統通過接入日志隔離把每個產品的日志都單獨輸出到指定的目錄，有效防止了日志的相互污染，對問題排查和監控指標的接入都提供了極大的便利。

除了上面提到的兩方面，SOFABoot為了支持內部的某些特殊場景，還增加了很多不錯的功能，這裡不再一一贅述。除了SOFABoot這樣優秀的應用框架，開發框架還包含了很多高效的支持工具。比如擁有完善的IDEA研發插件，利用該插件可以快速生成各類型項目代碼，安全快速地進行相關組件的升級，快速進行應用代碼部署和自動化測試等。統一的技術棧維護了應用的基礎軟件依賴，讓我們可以方便快捷地進行統一的版本升級和安全問題修復。

最後再回到SOFABoot框架本身，SOFABoot為應用集成內部的中間件能力提供了極大的便利，通過制定一套標準的注解和XML XSD規範，應用只需要使用標準的注解或者XML元素進行配置，即可集成相關產品能力，整個過程完全屏蔽了分布式和單元化架構的復雜度，讓研發人員更加專注於業務邏輯，而不用關注底層框架的復雜性。所以說開發框架並不僅僅是應用框架和應用容器，也不僅僅是某一種技術，而是一整套用於提升業務研發效率的工具，是一個完整的研發生態圈。