<object id="3iwlw"><noframes id="3iwlw"></noframes></object>

      <th id="3iwlw"></th>

    1. <rp id="3iwlw"></rp>
      <rp id="3iwlw"></rp>

    2. <button id="3iwlw"></button>
      云計算·大數據 頻道

      渤海銀行互聯網金融核心云原生數據庫應用與實踐

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

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

      圖片

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

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

        所謂“自建云”,就是以開源技術為核心,基于銀行自有的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經典網絡進行融合,這是一個難以回避的課題,必須在最初規劃的時候就解決掉。渤海銀行的建設思路是,減少不必要的網絡交換機與防火墻限制,避免云上云下系統相互訪問的時候,在數據庫網絡節點上產生不必要的開支。如果網絡融合做得不好,數據庫的整個鏈路會產生一定的網絡延遲,對業務的影響非常大。

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

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

      圖片

        眾所周知,銀行在使用傳統數據庫的時候都有很多規范,在項目開發的時候要嚴格遵守。其實,云原生數據庫也一樣,只不過云原生數據庫需要使用多種架構對應多套開發規范。比如:交易型數據庫、緩存型數據庫和大數據產品等,都有自己的通用規范;在云原生體系下,也要遵循相應的通用規則。

      圖片

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

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

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

      圖片

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

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

      圖片

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

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

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

      2
      相關文章
        漂亮的苏酥全文阅读