摘要： 最近斷斷續續花了差不多2到3周的時間閱讀完由電子工業出版社出版的《金融級IT架構：數字銀行的云原生架構解密》的這本書，作者是作者是網商銀行技術編委會。本書契合了當前銀行業分布式架構...

最近斷斷續續花了差不多2到3周的時間閱讀完由電子工業出版社出版的《金融級IT架構：數字銀行的云原生架構解密》的這本書，作者是作者是網商銀行技術編委會。

本書契合了當前銀行業分布式架構轉型趨勢，內容是經過實踐檢驗的領先技術介紹了網商銀行IT技術架構演進路線，涵蓋了分布式、單元化、彈性混合云、云原生多個基礎架構領域，同時介紹了技術風險、安全可信、業務架構等多方面的技術實踐經驗。

對于這本書實際很早搜索云原生相關書籍的時候就搜索到，但是一看標題是金融IT架構方面的因此沒有引起太多的重視，后面由華章圖書贈閱后才有幸閱讀到該書，讀完以后有一種相見恨晚的感覺。

對于網商銀行個人原來不熟悉，開始覺得奇怪為何網商銀行能夠寫出該書，后面上網一搜索才了解到網商銀行是由螞蟻集團作為大股東發起設立的中國第一家核心系統基于云計算架構的商業銀行。它作為銀監會批準的中國首批5家民營銀行之一，于2015年6月25日正式開業。所以網商銀行服務小微企業本身業務量也很大，同時由于螞蟻集團是大股東，因此在整個IT基礎設施和技術架構搭建中采用了阿里，螞蟻金服很大開源的技術組件和架構。或者說網商銀行很大技術人員本身就是前阿里的技術專家。

因此網商銀行技術編委會能夠寫出該書也就不奇怪了。

但是為啥是整個編委會而非單個作者，這部分覆蓋的內容相當廣泛，從IT基礎設施架構，到云原生，到安全可信，到中臺等。每一個單獨的章節內容都有足夠的深度，很難有一個人能夠都多有細分技術領域都掌握到如此程度。

而且基本上每個部分的內容一看就是來源于IT架構搭建的一線實踐所以，包括很多經驗點的分享也來源于大量實踐復盤，這就不是一般的技術書籍能夠所以到的點了。

根據該書的內容簡介我們也可以看到同樣的內容說明。

介紹了網商銀行成立至今的IT技術架構演進路線，涵蓋了分布式、單元化、彈性混合云、云原生多個基礎架構領域，同時介紹了技術風險、安全可信、業務架構等多方面的技術實踐經驗，我們希望和讀者分享網商銀行在金融級IT技術上做的獨特探索，跟大家探討數字化時代金融級IT架構的發展方向。

本書作者是網商銀行核心架構師，深度參與了相關技術方案從前期設計到后期投產的完整過程，內容清晰且權威。本書以網商銀行自身技術實踐為主線展開，講述的內容代表了領先的技術方向，相關技術經過了真實的生產環境錘煉，包含了網商銀行技術團隊獨到的實踐經驗，書中闡述的核心技術榮獲中國人民銀行頒發的 “銀行科技發展獎”二等獎。

這本書不僅僅是適合金融行業IT從業人員閱讀，也同樣適用于需要構建集團型大的IT基礎設施和云原生架構的人員閱讀。很多金融行業在分布式，高可用，彈性擴展，安全等方面的架構和實踐經驗積累完全適用于大型企業的數字化和云原生架構轉型。

下面對本書的一些關鍵內容做一些關鍵點的整理，本書的一些PPT配圖來源于本書撰寫作者之一蔣易民的公共技術分享。

網商銀行的三代架構演進過程

從這張圖來看，網商銀行主要經歷了三代架構的演進。

第一階段主要是基于云平臺+分布式架構建立起來的。整個的部署模式是同城雙活模式。到了2017-2018年的第二階段，在同城雙活的基礎上需要建設一個異地數據中心，希望這個異地的數據中心在日常過程中能承載業務流量，能與杭州數據中心同時對外提供服務。在滿足異地災備要求的同時考慮提升整個IT基礎設施的資產利用率，所以打造了單元化多活架構，它是一個三地五中心的部署結構。從2019年，網商銀行開始關注云原生架構，包括開始引進一些產品，設計建設相關能力。在這個過程中，我們也建設了混合云彈性架構，具備了在兩朵云之間調度資源的能力。

簡單所以整個演進路線關鍵技術點為：

數據垂直拆分，數據水平拆分，分布式架構構建，云計算平臺構建，單元化多活架構，彈性架構，彈性架構建設，混合云架構建設，云原生可信架構建設。

單元化架構

在這本書里面提到一個重要概念，即單元化架構。

每個單元是一個從流量層，應用層到數據層的完整，自治，獨立的生態系統，能夠為用戶提供絕大部分服務，數據訪問都盡量封閉在獨立的單元內完成。因此可以將一個單元部署到任何一個地域，同時單元和單元之前能夠互為備份。

大家看到這個的時候可能會聯系到分布式和微服務。

因為我在談微服務的時候也經常在強調重點是單體到微服務的拆分，每一個微服務都實現從數據層，邏輯層到應用層，從需求，設計，開發構建，編譯部署的獨立自治。但是這些都是在談軟件層面的單元化。

而單元化架構目標是實現軟件層面+硬件層面的共同單元化。有點類似多年前流行的一體機概念。軟硬一體化單元化更加方便了每個單元的跨地域，多數據中心移植能力，也進一步增強了IT基礎設施層面的高可用性和冗余。

從彈性計算到云原生

在傳統PaaS平臺的時候也談彈性計算和資源動態調度，但是傳統PaaS很難做到完全靈活，自動化，完全自動伸縮的彈性架構能力。

彈性一方面是自動化，一方面是要實現既可擴展又可收縮。

網商銀行從誕生起，IT系統就構建在私有云上，IaaS基于阿里云專有云底座建設，PaaS基于螞蟻集團的金融云構建，天然擁有了分布式計算能力。并具備了金融級別的安全，高可靠，高可用能力。

云原生技術包括了微服務，容器化，不可變基礎設施，聲明式API，服務網格等。云原生架構是基于云原生技術的一組架構原則和設計模式的集合，最關鍵的點就是把一些業務處理邏輯中非功能性的代碼剝離出來，從而讓云設施接管應用中原有的大量非功能特性（如彈性、韌性、安全、可觀測性、灰度等）。

從上面圖可以看到，傳統架構中任何一個代碼邏輯都包括了業務代碼，非功能性代碼和第三方依賴。而在云原生架構下，希望的是業務和技術分離，業務功能開發人員只開發業務功能代碼，而平臺類開發人員負責各種非功能性需求和可觀測性的實現。

大量非功能的特性，包括彈性、容量、安全可觀測性、灰度等都會逐漸下沉到底層的基礎設施，特別像高可用能力、容災能力、容量保障、安全特性，還有一些可運維的特性，逐漸讓基礎設施去接管。這種情況下可以看出，在我們在部署上會發生的一些變化。從圖的右下角看到，容器會進行進一步的拆分，拆成應用一個進程，邊車（sidecar）一個進程。

在這本書讀完后給我的另外一個最大的感受就是。

在傳統IT架構轉型，微服務化，和云原生技術發展過程中。為了實現彈性和靈活擴展，實現分布式，實現去中心化，ServiceMesh服務網格應用勢在必行。

特別是在通過容器云和Kurbernetes實現了容器資源的調度編排，不可變基礎設施后，為動態的下發邊車代理，將Sidecar和業務容器打包到一個POD進行管理成為了可能。這也大大地推進了Mesh網格化技術的發展。

在徹底的網格化后你會看到了，除了南北流量還需要上層的負載均衡設備來解決外，其它問題都可以通過邊車代理和去中心化方式來解決流量分配和路由，對接口服務和流量的安全，日志，限流熔斷等各種治理能力。

網商銀行早期也經歷過富容器，這種較重，包含了所有的應用發布部署需要的依賴，不限于一些關鍵的RPC、消息、數據庫等SDK。最小的部署單元也是一個容器，在云原生里做進一步劃分。

容器會區分為APP的容器，跟Sidecar 的容器。根據現在的實踐來看，主要是包含Service Mesh里面MOSN的容器，還有DBMesh的容器。這兩個容器解決的是 RPC、消息，還有數據庫跟緩存層面的轉發。

這種模式有一個最大的好處，就是MOSN跟DBMesh可以獨立演進，即可以不需要在上層業務容器配合的情況下，自己完成一些升級跟發布。

在Mesh化架構里面，實際網速銀行分為了兩個不同的Sidecar，其一是解決東西流量和服務治理的MOSN，另外一個就是DBMesh代理。

DBMesh代理是很重要的一個思路。

簡單來說就是在數據庫分布式，或數據庫進行了水平和垂直拆分后，傳統的架構邏輯思路是在拆分出來的各個單元上面在增加一個DaaS統一數據訪問層。但是DaaS層本身的部署又是集中化部署的，即所有的到底層數據庫的流量全部要經過DaaS層的APP服務器，那么DaaS層本身又變成了一個中心化的節點。

因此最佳方案應該是DaaS層的能力作為一個獨立容器Mesh化到各個POD組里面去。

流量隔離和流量調撥

云原生架構的核心價值是可以實現流量的精細化隔離。

在整個架構徹底Mesh化后，可以看到在Sidecar邊車代理處可以很好的處理對流量的路由，流量的隔離和精細化控制能力。

基于新的云原生能力，在流量轉發的過程，可以在流量通過MOSN邊車代理時進行標記，讓它路由到指定的一些容器上，就可以做到不同業務請求下，它會路由到不同的容器集群里，業務之間的相互影響就得到進一步降低。

最典型的是生產遇到的熱點賬戶問題，很容易導致全行的交易抖動。如果我們可以識別不同的業務所導致的熱點，可以做到有效的隔離，發生熱點時不會影響到非產生熱點的其他業務場景。

在新的云原生架構之下，基于mosn可以打造更細粒度流量調撥，從數據中心層面進一步下沉到單個應用級別。可以找一些不敏感的應用服務先切流，避免影響到關鍵業務內容。

在沒有進行Mesh化前，如果僅僅是通過負載均衡設備或網關來做這么精細化的流量隔離往往很難實現，這也是Mesh化帶來的一個另外一個關鍵能力。

從全鏈路壓測到混沌工程

對于云原生架構的復雜性，引入混沌工程是一個必然趨勢。

2018年，混沌工程（Chaos Engineering）成為CNCF的一個新的技術領域。

對于混沌工程部分CNCF基金會將其納入到可觀測性部分。在2020年8月完成了可觀測性技術調查，最終用戶社區的成員被問及他們評估、試驗并隨后采納了哪些可觀察性解決方案。對283個數據點進行排序和復查，確定最終位置。

混沌工程的一些關鍵點。

其一就是混沌工程不是僅僅在測試環境做，而是在生產環境直接模擬。也就是說測試環境難以完全模擬生產環境，那么就需要在生產環境進行節點故障模擬，也確認整個IT架構在生產環境的穩定性。

其二就是真正融合了業務并發性能測試和可靠性測試兩方面的內容。而在傳統測試中這兩者往往是分離的，很難在測試環境中完全模擬。

其三就是故障模擬本身的不確定性，第一就是故障本身產生的不確定性和隨機性，第二就是各種故障本身場景組合的不確定性。

云原生下的分布式架構復雜度，引入混沌工程是一個必然趨勢，就像我在前面談云原生和微服務的時候談到，引入ServiceMesh來進行微服務治理也是必然趨勢。

混沌工程當前是一個蓬勃發展的技術領域，也越來越受到重視。也是當前應對分布式架構復雜度下提出的一套切實可行，嚴謹的工程實踐原則，方法和工具。混沌工程基于反脆弱的思想，模擬故障只是手段，而核心目標仍然是提升系統的穩定性和可觀測性，及早地發現各種風險，并進行優化解決。

任何一個生產的業務系統，都不應該是出現故障后的問題驅動，而應該是主動發現，主動防御的風險驅動機制。這就是混沌工程在云原生架構下的巨大價值和作用。

這本書對全鏈路壓測做了簡單的介紹和方法實戰，但是從全鏈路壓測逐步升級到混沌工程方法論，是應對云原生架構復雜性的一個必然轉變。

對于云原生架構，實際在原來的文章我也談了幾個關鍵的技術點能力值得深入研究，其中主要包括了如下內容。

• 混沌工程和可觀測性
• ServiceMesh和去中心化服務治理
• 高度靈活自動化的彈性擴展架構
• 分布式中間件和分布式事務
• 一體化研發運維平臺和DevOps
• AIOps
• 流量治理
• 安全可信架構

以上內容將是云原生架構和技術發展，并逐步走向成熟的關鍵內容。

當然這本書也有一些不足，由于本身是處于多個技術團隊，多人的作品，感覺每個章節講述的內容之間的邏輯關聯關系存在不嚴謹的情況，同時也會在不同的章節出現描述同樣內容的情況。這是多人合著情況下經常會遇到的問題。

但是還是要說明下本書和簡單拼湊還是有差異，瑕不掩瑜，整體的框架內容還是完整的，很多實踐的內容和經驗分享都值得仔細學習并借鑒。再次推薦該書。特別是中大企業面對數字化轉型，云原生的IT技術總監和架構師閱讀。