渤海銀行網際網路金融核心雲原生資料庫應用與實踐

摘要：銀行類企業使用雲的方式無非有三種：分別是自建雲、公有云和專有云。不管是哪種方式，都會面臨一個最重要工作，那就是資料庫上雲。問題是，為什麼很多企業選擇雲原生資料庫?自建雲原生資料庫會面臨哪些挑戰?如何正確選擇雲原生路線?本文將根據雲原生資料庫在渤海銀行的實踐進行分析，梳理出雲原生資料庫建設的關鍵點，謹防踩坑。

本期分享嘉賓：渤海銀行總行科技部高階經理 曹嘯

簡介：擁有近十年的金融科技領域工作經驗，曾就職於頭部國有大行和股份制商業銀行。在銀行科技系統開發條線和運維條線均有豐富經驗，重點技術領域集中在各類資料庫的架構設計與生產運維。近些年主攻開源資料庫、國產資料庫、雲端計算技術等領域，對雲原生資料庫、開源資料庫的底層執行機制和原始碼分析亦有所研究。

放眼望去，銀行類企業使用雲的方式無非有三種：分別是自建雲、公有云和專有云。

所謂“自建雲”，就是以開源技術為核心，基於銀行自有的IDC進行搭建，期間會使用到虛擬化技術和K8S容器技術，自主可控程度很高，運維成本相對較高，對技術人員的要求也高。因為，小到每一臺伺服器以及上面的作業系統軟體，大到雲平臺的整個IaaS和PaaS層都是銀行自己搭建。

而公有云，是指銀行會選擇購買第三方雲廠商的服務，伺服器、產品都是部署在雲廠商的基礎設施上，所有底層技術都由雲廠商完成，這種方式的優勢是比較簡單便捷，運維要求很低。但是，這種方式也有一個弊端，那就是定製化程度比較高，銀行只能跟著雲廠商的架構走，對於很多關鍵業務或者是重要性級別比較高的系統來說，並不適用。另外，由於業務性質要求，銀行的關鍵業務不可能全部部署在公有云上。

專有云，部分企業也稱為是混合雲，其實基本形態都差不多，就是公有云的業務模式在銀行機房內進行完整輸出，包括會通過雲原生技術能力為銀行各項業務提供服務。專有云帶來的最大優勢是，降低了自建雲平臺的難度，讓技術人員更聚焦於業務應用開發，配套的運維體系也相對完整，雲運維的難度較低。問題是，銀行業務上雲沒有十全十美，專有云雖然是大多數銀行的最佳選擇，銀行自主可控的能力比較高;但是，由於相對比較封閉，想要了解內部應用的每一個細節和邏輯，需要花費大量時間。同時，由專有云提供商提供運維服務的銀行，自主可控的難度較高，同時定製化的程度又比較低。

為什麼選擇雲原生資料庫?

銀行核心業務上雲，最重要的工作，就是資料庫上雲。那麼，我們該如何理解諸多企業都在推崇的雲原生資料庫?和傳統資料庫相比，雲原生資料庫有哪些優勢?

綜合來看，我們可以從5個方面來對比：

1、 併發處理能力。

基於雲原生本身的特性，在彈性擴充套件、高效能支援方面有出色表現，所以高併發的處理能力也比傳統資料庫更強一些。當前，銀行網際網路業務高速發展，傳統資料庫的單機模式以及相關的硬體資源配置，已經很難滿足業務量快速增長的需求。

2、 可擴充套件性。

雲原生資料庫一般都是自帶高可擴充套件性和資料重分佈能力，而且對業務的影響也比較低。相對而言，傳統資料庫的可擴充套件性較難。之前，銀行同業也基於Oracle、 MySQL等做過資料庫彈性擴容機制的嘗試，但由於技術能力和傳統資料庫的技術架構受限，實現起來比較難。

3、 架構統一性。

雲原生資料庫有著先天的技術統一性和融合性，憑藉雲內資料庫體系和相關邏輯，可依賴雲平臺能力解決架構統一性問題。但是，如果是傳統資料庫，各個產品的使用以及特殊場景的融合能力，需要單獨考慮，比如：AP資料庫、TP資料庫或者快取資料庫路徑融合，需要對應哪個產品，只有深度掌握和了解，才能做更好的融合。

4、 運維複雜度。

雲原生提供的產品種類繁多，關聯性強，但問題排查能力比較低，需要依賴雲原生能力;而傳統資料庫在運維上相對更容易，基於現有的硬體、IO、記憶體和CPU，比較容易定位產品問題，便於縱向深度探索。當然，最終運維水平如何，還依賴於人的能力。

5、 場景靈活性。

在場景靈活性方面，雲原生資料庫相比傳統資料庫更低一些，因為所有能力都是相對封裝，可定製化和DIY的能力比傳統資料庫差。

問題是，瞭解了雲原生資料庫和傳統資料庫的差異化能力以後，我們應該如何去構建雲原生資料庫?渤海銀行的一些經驗，或許能為更多銀行類的企業帶來參考和借鑑作用。

從2018年開始，渤海銀行引入專有云，經過三年多的技術平臺建設以及運營體系的不斷完善，目前已基本形成了應用改造上雲的標準流程體系，先後有些關鍵和一般業務類系統都已經逐漸完成上雲，目前已經上雲的最重要的系統就是網際網路金融核心業務系統，承載了絕大多數的網際網路業務和對外介面。未來的計劃是進一步完善多中心專有云體系，構建同城多活、多地多中心的雲體系。

雲原生資料庫建設如何按照規劃搭建?

那麼，從實踐的角度來看，雲原生資料庫建設該如何按照規劃逐步落地?

首先，要完成同城三機房佈局，鞏固異地機房建設，形成同城三中心、多地多中心的架構。並且，同城中心生產雲有2個主機房，計算節點是雙活，包括快取和MQ雙活或者主備模式，能夠支援同城機房的快速切換。其中，資料庫應用同城三副本，可以更好地滿足對RPO和RTO的要求;儲存層主要還是用同城雙活，異地機房整體上是冷備架構，所以對應用層、計算層、分佈層都做了整體測試;開發測試雲和生產雲是同構狀態，主要用來跨同城三中心，支援應用開發測試上雲的版本升級以及全平臺應用。

其次，在關鍵業務系統承載方面，建立網際網路金融核心資料庫體系與網際網路業務中臺，關鍵的網際網路業務系統都要通過網際網路金融核心進行業務流的展開，包括傳統銀行所有的電子渠道、手機銀行、企業網銀等等。目前，該系統已經完成了雲上建設和雲上投產，由於業務系統本身很複雜，所以對資料庫技術有著更高要求。

如圖所示，業務邏輯層包括賬戶中心、認證中心、產品中心、配置中心，都是微服務中心;向上是OLAP體系，包括流計算、列儲存、BI和訊息佇列，用來進行實時分析;向下是資料快取層，也是應用層關聯到資料庫的過渡層，資料庫用的是雲原生的快取資料庫。其中，關係型資料庫是兩種架構：一種是分散式;另一種是主備叢集，都是通過資料庫中間層的方式進行管理。資料遷移模組是雲下資料庫如Oracle向雲上關係型資料庫進行資料遷移的通道;資料整合模組是實現資料共享與互聯互通的有效方式;資料同步模組支撐了各個系統實時資料同步的各類需求;集中監控模組對所有資料庫產品進行統一管理和監控。

雲原生資料庫實踐如何避免踩坑?

大體來看，雲原生資料庫實踐不是“拍腦門行為”，而是要依靠平臺架構思維從建立雲平臺之初就對資料庫體系進行整體規劃。

具體而言，企業應該關注三個重點：

第一，雲專有網路與經典網路的融合;專有云平臺在進行部署的時候，一般會用專有網路。問題是，專有網路如何與原有IDC經典網路進行融合，這是一個難以迴避的課題，必須在最初規劃的時候就解決掉。渤海銀行的建設思路是，減少不必要的網路交換機與防火牆限制，避免雲上雲下系統相互訪問的時候，在資料庫網路節點上產生不必要的開支。如果網路融合做得不好，資料庫的整個鏈路會產生一定的網路延遲，對業務的影響非常大。

第二，根據資料庫產品特性和業務應用場景提前規劃資料庫產品部署方式。現在，大部分雲廠商都能提供多種部署方式，包括容器的部署、虛機的部署、裸機的部署等等。那麼，關係型資料庫如何部署需要根據實際場景進行規劃，目標是發揮各類資料庫產品的特長，提升全域性的效能，提高資源使用率。

第三，雲內外相互系統的訪問規則要提前設定好。雲內外的相互訪問資料庫和資料庫間的場景需要提前規劃好，梳理出相應的場景，後續應用上雲和遷雲改造的過程中，要進行場景限制，不能對應用上雲天馬行空，隨意更改架構，而是要在場景範圍內去做架構設計。最終的建設目標是，降低資料庫鏈路產生異常的概率，便於對後續問題的排查，進而提升雲上雲下應用相互訪問的效率。

眾所周知，銀行在使用傳統資料庫的時候都有很多規範，在專案開發的時候要嚴格遵守。其實，雲原生資料庫也一樣，只不過雲原生資料庫需要使用多種架構對應多套開發規範。比如：交易型資料庫、快取型資料庫和大資料產品等，都有自己的通用規範;在雲原生體系下，也要遵循相應的通用規則。

與此同時，銀行關鍵業務對連續性有高標準要求，同城和異地容災能力尤為重要。與傳統架構相比，雲架構的同城容災能力實現起來更為複雜，難度也更大，其中資料庫容災體系的規劃和建設是重中之重。

關於容災體系建設，不管是國內的頭部廠商，還是新興廠商，對銀行業務的理解以及系統架構的部署，還有進一步提升空間，尤其在同城容災、異地容災體系的建設和規劃方面，還相對比較初級，所以選用雲原生體系、雲原生資料庫，一定是要在最初架構設計的時候做出同城容災、異地容災選擇。

容災架構的選擇：一個是叢集內的容災;一個是叢集間的容災。叢集內的容災，就是在同城跨機房環境中採用MySQL主從或者Oracle RAC之類的架構進行部署。一個叢集的各個節點都被打散，分散到各個不同的機房，其實這種方式有優勢也有劣勢。優勢，是可以用資料庫叢集原生的容災能力實現同城高可用，實現難度是很小的，幾乎沒有二次開發的地方，切換能力也可以複用;劣勢，是把叢集拉大的同時，大大增加了叢集各個節點之間的距離，提高了節點間的通訊延遲。對比多家銀行的機房環境，同城機房大多距離是40-70公里之間，相應的光纖距離就是50-100公里左右，所以對叢集節點拉開的影響到底有多大，需要具體評估。因為延遲會直接影響到資料庫各個節點之間的通訊，也會影響到業務交易響應時間。叢集間的容災，是指資料庫多個叢集之間去做一個兩叢集或者三叢集的資料同步，保障各個機房資料的可用性。但是，做叢集切換的時候，資料的一致性比較難保證。

值得一提的是，銀行關鍵業務系統容災，對RPO和RTO都有嚴格要求。比如：RPO大小衡量的就是同城切換可能會丟失多長時間的資料，RPO=0的要求就是一定不能丟失任何資料，RTO代表著整個資料庫同城切換以後對外恢復的時間是多長，一般是幾秒或者十幾秒。

一般情況下，專有云架構的同城容災需要從全平臺層面進行控制，包括會採用三機房的應用和資料庫部署架構，因此相較於傳統架構技術難度更大，同時需保證同城RPO為零，可全量保留所有資料。

容災體系建設，還有一個最大的難點，就是應用的關聯關係。傳統銀行業體系包括國有大行、股份制銀行、城商行，大部分機構目前處於架構轉型階段，很多大行的關鍵業務還跑在IBM大型機上，全國範圍來看肯定是長期保持雲架構和傳統架構的並用。不管是自建雲還是專有云方式，雲上關聯訪問場景必然存在，這中間除了應用鏈路、訪問效率問題，容災體系建設存在很大挑戰。因為多數情況下雲上應用和雲下應用切換的規則和邏輯不同，當單邊發生切換的時候，怎樣保持系統間互訪?同時如何保持各業務的連續性?

渤海銀行的方案是，通過全域性的DNS改造和全域性的域名解析，來解決應用系統關聯問題。目前，商業化專有云基本上已經能夠全部實現雲內全面DNS訪問，資料庫叢集和中介軟體產品通過域名也都能夠訪問，但銀行傳統架構下大部分的應用都是通過IP直聯的訪問方式或者VIP的方式。DNS改造就是採用單一域名對應多個服務IP或VIP的方式，實現叢集發生切換時即便VIP發生了變化，多個VIP只要有一個處於活躍狀態就能夠成功解析，無論雲上雲下應用怎樣切換，相互訪問的規則都不變。

總結：其實，根據經驗來看，雲原生資料庫也好，雲架構也好，並沒有統一選型標準。企業如何選擇雲架構和看待雲原生，都應結合自身實際情況進行分析和判斷。