中國IDC服務網

 找回密碼
 立即注冊
搜索
熱搜: 活動 交友 discuz
中國IDC服務網 首頁 技術流 查看內容

工商銀行MySQL數據庫架構解密

2019-5-14 14:39| 發布者: 156| 查看: 6748| 評論: 0

摘要:本文根據DTCC數據庫大會分享內容整理而成,將介紹工商銀行 IT 架構轉型中傳統 OLTP 數據庫架構面臨的挑戰和訴求,構建基于 MySQL 分布式企業級解決方案實踐歷程,包括技術選擇、高可用設計、兩地三中心容災、運維管理、資源使用效率等方面的思考和實踐經驗,同時也介紹了工行轉型的成效以及對后續工作的一些思考。

關鍵詞:擁抱開源;MySQL; 高可用; 分布式;數據拆分; DBLE; 管理平臺;災備;容器;

演講者介紹:林承軍,中國工商銀行軟件開發中心高級經理,多年來一直從事開放平臺相關技術研究及實施工作,多次參與工行重點項目的原型技術研究、IT 架構轉型及優化提升,在分布式、高可用架構、數據高效訪問領域有豐富的實施經驗。近年來,牽頭 MySQL/分布式數據庫團隊工作,借鑒和引入業界成功經驗,通過自主研發 技術引入,迅速形成基于開源 MySQL 的企業級應用研發能力,初步建立了企業級解決方案,推動工行開放平臺 OLTP 數據庫轉型的實施。

一、數據庫轉型背景

1.1 傳統IT架構的挑戰

大型國有銀行,整體核心的系統都是大機+DB2這樣的傳統架構;針對現在的互聯網金融業務快速擴張的需求,傳統的架構面臨著比較大的挑戰,主要集中在四個方面:

l   處理能力;因為工行這么大的體量,導致整體系統的規模比較龐大,這種垂直的單一的擴展模式,不具備橫向處理能力,處理能力受到限制;

l   運行的風險;隨著很多的業務從網點變成線上,新的業務提出了更高的業務連續性保障,包括7×24小時,傳統的架構從架構設計上無法做到這樣的支持;

l   快速交付;傳統的開發模式應用內部模塊、應用與應用之間的耦合度非常高,使得軟件的開發和產品交付周期比較長;

l   成本控制;大型主機運營成本非常貴,買個機器幫你搞兩下就幾千萬上億的支出,再加上商業產品的License比較高,銀行議價能力又比較低;

 

在這種情況下進行IT架構轉型,整體的訴求是優化應用架構、數據架構、技術架構,建立靈活開放、高效協同、安全穩定的IT架構體系,強化對業務快速創新發展的科技支撐。


1.2 轉型的核心訴求和策略

在上面的轉型大背景下,數據作為核心,我們展開了對開放平臺的數據庫的架構轉型,同時提出了幾個核心的策略:

l   第一,在業務支撐方面,做到高并發、可擴展、支持海量數據存儲及訪問。以及兩地三中心高可用容災。工行在國有大型銀行里應該是比較領先的實現兩地三中心容災體系;

l   第二,降低使用成本,基于通用的廉價的硬件基礎設施,希望提升自己的管理控制能力,進行行內適配和定制。降低對商業產品依賴,提升議價能力;

l   第三,運維能力,提升數據庫的運維自動化智能化,更加開放的技術體系以利于自主掌控。主要采取三方面策略:

  一:集中式向分布式的轉型;

  二:是專有向通用的轉型,也就是去IOE;

  三:限制商業產品,擁抱開源;

 

這是我們當時采取的策略。結合近期的國家提出安全可靠的工作要求,對國內的生態和服務商也是比較好的挑戰和機會。



二、 轉型的發展經歷

2.1 轉型路線圖

2.1.1 三年轉型之路

整個轉型歷程,大概從2015年開始IT架構轉型,但真正有進展應該是從2016年初到2017年這個時間。我們整個的發展歷程大概可以分三個階段:

第一階段 原型的研發和探索

l   2016年初到2017年的過程,當時結合人民銀行對于個人賬戶的管理要求,實行一類二類三類賬戶;結合這樣的工作要求,把個人賬戶從主機下移到開放平臺,基于開放平臺的高性價比、可擴展進行了很多的探索,進行了很多的技術驗證。當驗證了技術可行性之后,我們提出了一個開放平臺數據庫轉型的規劃,這個規劃對于我們行內后面幾年的工作,對于數據庫的方案選型是非常大的影響。這個規劃確定我們行里要建設基于開源的MySQL OLTP數據庫解決方案。

第二階段 基礎研究和試點

l   2017年整年,我們基于開源的MySQL數據庫進行產品的研究和能力的建設,以及初步能力的建設,包括基礎研究和應用的試點。在此期間,前面提到的原型也是在2017年5月份上線的,在生產線上跑起來了,把整個技術體系都進行了驗證。

第三階段 轉型實施及推廣

l   2018年開始大規模的實施和推廣,在這個過程中基于開源的MySQL數據庫,我們逐步建立起了一個企業級的數據庫服務能力,包括引入了分布式的中間件,在高可用、運維能力的提升,資源使用率的提升,MySQL的云化及自主服務的建設等等。在整個過程中,同步對OLTP的分布式數據庫進行了研究,也對后面的工作指導提供了依據;


2.2 選型階段

2.2.1 方案選型調研

在選型階段,我們基于業務場景進行了大量的方案調研。坦率的說,工行軟件開發中心在2014—2016年持續關注著行業內數據庫的發展和生態的發展,在這個過程中我們對很多的產品進行了一些研究和摸底的測試。

NewSQL數據庫方案,是很多的互聯網企業或者一些小型企業有所使用的,但是我行在選擇技術的時候是非常謹慎的,以及要做非常多驗證,在當時并不符合我們系統設計的考量點;

基于開源的分布式OLTP方案,業界有很多豐富的案例,而且在互聯網企業里面得到了很好的實踐,在業界資源案例都很豐富。是同時能應對我行的高并發、彈性擴展需求的;

所以我們最終確定從分布式架構的角度去解決整個架構的挑戰,不僅僅只從單一的數據庫的層面解決這個問題。



2.2.2 分布式技術棧

基于這樣的一個原型探索,我們構建了一系列的分布式架構技術棧,包括分布式服務、分布式事務框架、分布式批量框架、分布式緩存、交易數據核對及補償、分布式消息、配置中心、開發及運維管理。這里簡單說一下:

l   分布式服務改造,針對我們傳統架構耦合比較緊密的特點,通過服務化的改造,降低耦合度。降低耦合度的同時,還可以盡最大可能的避免分布式事務的產生;

l   分布式事務的框架,我們結合兩階段提交和分布式的消息,支持強一致性和最終一致性多種模式的支持,通過分布式事務框架解決分布式事務的問題;

l   分布式批量框架,在大規模的數據結點上進行批量操作的一個整體的解決方案;

l   業務層面,在交易或者應用級層面進行數據核對及補償,有些場景就是在傳統的OLTP的情況下,也會對應用上下游進行核對和補償;

l   分布式消息平臺,實現這樣一個應用級的數據交互;

同時我們也進行了運維的規劃和總設計。這里引入了開源的MySQL數據庫來解決數據最終落地的問題


2.2.3 MySQL高可用方案

在原型階段,當時主流是MySQL5.6,5.7才剛出來;對于高可用要求,行里的應用是要做到同城切換,上海兩個園區要做到RPO是0,RTO非常小,同時異地北京有一個災備中心,就是兩地三中心。

我們的AB類重點應用必須具備這樣的同城兩個園區同時對外服務的能力。在原型設計階段,我們基于MySQL的半同步復制,來做這樣的一個切換,實現RPO=0,解決主庫故障自動切換到備庫,同城為了保障RPO=0,在原型階段進行了應用的雙寫。來進行數據的核對和補充;

這里順便提一下,MySQL5.7相對5.6的改進非常大的,這是一款真正可以適合金融行業的數據庫產品,它在數據回放方面,在性能方面都有比較大的改進和提升;


2.3 實施推廣階段

2.3.1 基礎研究和應用試點

第二個階段是開源MySQL基礎研究和應用試點,就是2017年。對于這些元素研究以后,在行里要發布第一個產品;把這個產品推上線,要做很多的工作:

產品的基礎研究,我需要驗證功能、新特性和配置基線,數據備份恢復,還要結合它的特性來設計應用的高可用,提供開發的技術規范;

我們的角色既要考慮到運維,也要考慮到上游應用,做好上面的銜接、對接和支持。包括應用的開發規范,它的性能能力評估,上線需要多少設備,容量是多大,還要對Oracle等老架構給予指引和幫助,代碼寫不好還要弄個檢查工具等等。運維方面就是要提供各種安裝部署的便利化,然后行內和行內的監控系統進行對接,制定很多的指標和參數,如何和行里進行對接,然后新問題的分析等等一系列的問題。在這個階段我們實現了同城RPO=0,RTO=分鐘級目標,RPO為0的切換,問題可監控,實現了人工或自動的一鍵式切換。

這個階段,行里決策了之后,我們一下子上了21個應用,211個節點,這是2017年。


2.3.2 分布式中間件應用

2018年開始轉型和實施,并且大量應用上線;之前的基于應用級的分布式解決方案,遇到了一些新的限制;部分應用不想設計的過分復雜,這個時候引入了開源分布式中間件DBLE,引入它的目的就是為了簡化開發的工作量,通過引入這樣一個DBLE來支持垂直數據分片、水平數據分片、混合分片等場景的支持,還支持簡單的跨庫匯集查詢提供類似集中庫的操作體驗,這個時候開發場景就簡化了,給了應用更多的選擇,簡化了應用開發的復雜度。


2.3.3 運維架構流程完善

解決了應用開發的復雜度,運維怎么辦?高可用怎么辦,我們結合DBLE和運維管理平臺,實現整平臺聯動,支持從高可用、監控告警、安裝部署、自動化補數等等一系列的解決方案;


2.3.4 運維管理能力沉淀

這時進行運維能力的提升,也迫在眉睫;因為分布式隨著實施的運維節點的增加,運維是一個很大的挑戰,那么多的節點,安裝、監控、報警、故障、人工處理等非常麻煩;

我們首先提供一個自動化的安裝部署,實現批量安裝部署,批量串行還不行,時間太長了,要并行,并行太高了,網絡的流量會受到比較大的影響,所以這個方面有很多的場景都需要打磨。

第二是監控告警,監控告警里有事件等級,分各種等級,這些需要靈活的定制,建立基線告警,建立應急流程。

第三是故障的分析,完善日志記錄、采集和分析,建立故障分析規范。

第四是自動巡檢,自動化的巡檢和評分報告,對實例狀態進行健康評分。


2.3.5 統一運維平臺建立

我們通過這樣一個統一的運維管理平臺,把所有的節點都納入進來了,實現一鍵式的安裝、版本的升級、參數的配置。并且實現了多種高可用策略配置,包括自動、人工一鍵式切換。

談到為什么要有自動化和人工的兩種切換方式?一種新的事務上線之前,都會面臨一些挑戰和懷疑的,都是一個循序漸進的過程,特別是是在金融行業,我們實現了多種高可用策略的靈活配置。


2.3.6 故障自動切換上線

我們建立了一個自動化、高可用的決策系統,大家知道人工決策到自動切換,雖然只是邁出一步,但是面臨著很大的挑戰,包括決策的因素和決策的模型,最難的是還要應對不同應用場景的需求,有的時候說RPO優先,有的RTO優先,有的要求三分鐘搞定,有的說10秒鐘5秒鐘我都難受,你要有這樣的模型適配這樣的場景,這是非常大的挑戰。在整體上面基于MySQL的復制技術,我們有半同步復職和多數派共識機制實現冗余備份。基于MySQL binlog日志自動數據補全,保障數據的一致性。


2.4 實踐中的改善優化

2.4.1 高可用方案改進

同時實施過程中我們走的比較快了,一年幾百個節點,幾十個應用。在這個過程中,我們又對高可用方案進行了持續的優化,同時學習和借鑒互聯網包括分布式數據庫的一些方案,我們把一主兩備,本地1備和同城1備,擴展成1主3備,通過半同步的機制,做到真正的在系統級去保證RPO=0;


12下一頁

鮮花

握手

雷人

路過

雞蛋

最新評論

小黑屋|中國IDC服務網 ( 京ICP備13032931-1號 京公網安備11010802009381 QQ:1390064848,電話:4006678502,郵箱:[email protected] )

GMT+8, 2019-12-6 00:53 , Processed in 0.052039 second(s), 14 queries .

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

返回頂部
87期双色球中奖号码