作者介紹

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

本文將介紹工行 IT 架構轉型中，傳統(tǒng) OLTP 數(shù)據(jù)庫架構面臨的挑戰(zhàn)和訴求，構建基于 MySQL 分布式企業(yè)級解決方案實踐歷程，包括技術選擇、高可用設計、兩地三中心容災、運維管理、資源使用效率等方面的思考和實踐經驗，同時也介紹了工行轉型的成效以及對后續(xù)工作的一些思考。

一、數(shù)據(jù)庫轉型背景

1、傳統(tǒng)IT架構的挑戰(zhàn)

大型國有銀行，整體核心的系統(tǒng)都是大機+DB2這樣的傳統(tǒng)架構;針對現(xiàn)在的互聯(lián)網金融業(yè)務快速擴張的需求，傳統(tǒng)的架構面臨著比較大的挑戰(zhàn)，主要集中在四個方面：

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

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

快速交付;傳統(tǒng)的開發(fā)模式應用內部模塊、應用與應用之間的耦合度非常高，使得軟件的開發(fā)和產品交付周期比較長;

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

在這種情況下進行IT架構轉型，整體的訴求是優(yōu)化應用架構、數(shù)據(jù)架構、技術架構，建立靈活開放、高效協(xié)同、安全穩(wěn)定的IT架構體系，強化對業(yè)務快速創(chuàng)新發(fā)展的科技支撐。

 

 

2、轉型的核心訴求和策略

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

首先，在業(yè)務支撐方面，做到高并發(fā)、可擴展、支持海量數(shù)據(jù)存儲及訪問。以及兩地三中心高可用容災。工行在國有大型銀行里應該是比較領先的實現(xiàn)兩地三中心容災體系。

其次，降低使用成本，基于通用的廉價的硬件基礎設施，希望提升自己的管理控制能力，進行行內適配和定制。降低對商業(yè)產品依賴，提升議價能力。

還有就是運維能力，提升數(shù)據(jù)庫的運維自動化智能化，更加開放的技術體系以利于自主掌控。主要采取三方面策略：

集中式向分布式的轉型;

是專有向通用的轉型，也就是去IOE;
限制商業(yè)產品，擁抱開源;

 

 

二、 轉型的發(fā)展經歷

1、三年轉型之路

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

第一階段：原型的研發(fā)和探索

2016年初到2017年的過程，當時結合人民銀行對于個人賬戶的管理要求，實行一類二類三類賬戶。

結合這樣的工作要求，把個人賬戶從主機下移到開放平臺，基于開放平臺的高性價比、可擴展進行了很多的探索，進行了很多的技術驗證。

當驗證了技術可行性之后，我們提出了一個開放平臺數(shù)據(jù)庫轉型的規(guī)劃，這個規(guī)劃對于我們行內后面幾年的工作，對于數(shù)據(jù)庫的方案選型是非常大的影響。

這個規(guī)劃確定我們行里要建設基于開源的MySQL OLTP數(shù)據(jù)庫解決方案。

第二階段：基礎研究和試點

2017年整年，我們基于開源的MySQL數(shù)據(jù)庫進行產品的研究和能力的建設，以及初步能力的建設，包括基礎研究和應用的試點。

在此期間，前面提到的原型也是在2017年5月份上線的，在生產線上跑起來了，把整個技術體系都進行了驗證。

第三階段：轉型實施及推廣

2018年開始大規(guī)模的實施和推廣，在這個過程中基于開源的MySQL數(shù)據(jù)庫，我們逐步建立起了一個企業(yè)級的數(shù)據(jù)庫服務能力，包括引入了分布式的中間件，在高可用、運維能力的提升，資源使用率的提升，MySQL的云化及自主服務的建設等等。

在整個過程中，同步對OLTP的分布式數(shù)據(jù)庫進行了研究，也對后面的工作指導提供了依據(jù);

 

 

2、選型階段

1)方案選型調研

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

NewSQL數(shù)據(jù)庫方案，是很多的互聯(lián)網企業(yè)或者一些小型企業(yè)有所使用的，但是我行在選擇技術的時候是非常謹慎的，以及要做非常多驗證，在當時并不符合我們系統(tǒng)設計的考量點。

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

所以我們最終確定從分布式架構的角度去解決整個架構的挑戰(zhàn)，不僅僅只從單一的數(shù)據(jù)庫的層面解決這個問題。

 

 

2)分布式技術棧

基于這樣的一個原型探索，我們構建了一系列的分布式架構技術棧，包括分布式服務、分布式事務框架、分布式批量框架、分布式緩存、交易數(shù)據(jù)核對及補償、分布式消息、配置中心、開發(fā)及運維管理。

這里簡單說一下：

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

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

分布式批量框架，在大規(guī)模的數(shù)據(jù)結點上進行批量操作的一個整體的解決方案;

業(yè)務層面，在交易或者應用級層面進行數(shù)據(jù)核對及補償，有些場景就是在傳統(tǒng)的OLTP的情況下，也會對應用上下游進行核對和補償;

分布式消息平臺，實現(xiàn)這樣一個應用級的數(shù)據(jù)交互;

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

 

 

3)MySQL高可用方案

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

我們的AB類重點應用必須具備這樣的同城兩個園區(qū)同時對外服務的能力。

在原型設計階段，我們基于MySQL的半同步復制，來做這樣的一個切換，實現(xiàn)RPO=0，解決主庫故障自動切換到備庫，同城為了保障RPO=0，在原型階段進行了應用的雙寫，來進行數(shù)據(jù)的核對和補充。

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

 

 

3、實施推廣階段

1)基礎研究和應用試點

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

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

我們的角色既要考慮到運維，也要考慮到上游應用，做好上面的銜接、對接和支持。

包括應用的開發(fā)規(guī)范，它的性能能力評估，上線需要多少設備，容量是多大，還要對Oracle等老架構給予指引和幫助，代碼寫不好還要弄個檢查工具等等。

運維方面就是要提供各種安裝部署的便利化，然后行內和行內的監(jiān)控系統(tǒng)進行對接，制定很多的指標和參數(shù)，如何和行里進行對接，然后新問題的分析等等一系列的問題。

在這個階段我們實現(xiàn)了同城RPO=0，RTO=分鐘級目標，RPO為0的切換，問題可監(jiān)控，實現(xiàn)了人工或自動的一鍵式切換。

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

 

 

2)分布式中間件應用

2018年開始轉型和實施，并且大量應用上線;之前的基于應用級的分布式解決方案，遇到了一些新的限制。

部分應用不想設計的過分復雜，這個時候引入了開源分布式中間件DBLE，引入它的目的就是為了簡化開發(fā)的工作量。

通過引入這樣一個DBLE來支持垂直數(shù)據(jù)分片、水平數(shù)據(jù)分片、混合分片等場景的支持，還支持簡單的跨庫匯集查詢提供類似集中庫的操作體驗，這個時候開發(fā)場景就簡化了，給了應用更多的選擇，簡化了應用開發(fā)的復雜度。

 

 

3)運維架構流程完善

解決了應用開發(fā)的復雜度，運維怎么辦?高可用怎么辦?

我們結合DBLE和運維管理平臺，實現(xiàn)整平臺聯(lián)動，支持從高可用、監(jiān)控告警、安裝部署、自動化補數(shù)等等一系列的解決方案。

 

 

4)運維管理能力沉淀

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

我們的做法：

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

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

第三是故障的分析，完善日志記錄、采集和分析，建立故障分析規(guī)范。

第四是自動巡檢，自動化的巡檢和評分報告，對實例狀態(tài)進行健康評分。

 

 

5)統(tǒng)一運維平臺建立

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

談到為什么要有自動化和人工的兩種切換方式?

一種新的事務上線之前，都會面臨一些挑戰(zhàn)和懷疑的，都是一個循序漸進的過程，特別是是在金融行業(yè)，我們實現(xiàn)了多種高可用策略的靈活配置。

 

 

6)故障自動切換上線

我們建立了一個自動化、高可用的決策系統(tǒng)。大家知道人工決策到自動切換，雖然只是邁出一步，但是面臨著很大的挑戰(zhàn)：

包括決策的因素和決策的模型，最難的是還要應對不同應用場景的需求，有的時候說RPO優(yōu)先，有的RTO優(yōu)先;有的要求三分鐘搞定，有的說10秒鐘5秒鐘我都難受。你要有這樣的模型適配這樣的場景，這是非常大的挑戰(zhàn)。

在整體上面基于MySQL的復制技術，我們有半同步復職和多數(shù)派共識機制實現(xiàn)冗余備份�；�于MySQL binlog日志自動數(shù)據(jù)補全，保障數(shù)據(jù)的一致性。

 

 

4、實踐中的改善優(yōu)化

1)高可用方案改進

同時實施過程中我們走的比較快了，一年幾百個節(jié)點，幾十個應用。

在這個過程中，我們又對高可用方案進行了持續(xù)的優(yōu)化，同時學習和借鑒互聯(lián)網包括分布式數(shù)據(jù)庫的一些方案，我們把一主兩備，本地1備和同城1備，擴展成1主3備，通過半同步的機制，做到真正的在系統(tǒng)級去保證RPO=0;

 

 

2)異地災備和存儲優(yōu)化

異地災備和存儲方面，當初跑的太快，方方面面有些沒有考慮那么完備。

我們剛才說了，我們在上海到北京有一個災備。數(shù)據(jù)災備剛開始方案，采用磁盤復制實現(xiàn)災備，這個也是要支出軟件費用，也比較耗錢。

還有就是冷備，無法熱切換，RTO至少半個小時以上。這個方面我們改進了，用了MySQL異步復制。

另外存儲方面沿用的集中存儲，一套集中存儲上面同時支撐六七十上百個MySQL實例，IO的性能非常容易成為瓶頸。

在應對一些高并發(fā)場景的時候，因為IO性能不足，這方面我們就改進了，直接引入了SSD盤，基本上把MySQL、IO的瓶頸給解決了。

在現(xiàn)在的場景下，IO一般不會成為瓶頸了。同時通過SSD的引入，交易的響應時間在相同條件下降低50%。

 

 

3)MySQL 容器化探索

MySQL的上容器，首先說一下為什么要搞這個事情?

因為工行一兩年轉型過來，大規(guī)模的上MySQL數(shù)據(jù)庫，節(jié)點非常多，機房和設備成為一個瓶頸，再這么玩兒下去機房容量不足了。這個時候需要提升資源的使用效率。

在很多應用里，因為它的超前規(guī)劃，一般為了穩(wěn)定運行，基本上都提出資源申請的時候，都是物理機，為了滿足后面幾年的業(yè)務需求，大規(guī)模的申請物理機，但當前應用的交易量又不是那么大，浪費比較嚴重的。

這個時候我們提升資源的使用成為緊迫的問題。這個過程中為什么選擇MySQL的容器呢?

幾點考量：

行業(yè)化里的商業(yè)軟件都是用的VMware;

VMware在IO方面，在系統(tǒng)性能方面都有比較大的損耗;

行里在IAAS、PAAS方面建設好多年了，我們無狀態(tài)的應用服務其實全部上了PAAS，全部上了容器，在這方面有一些技術的積累，結合行內對于云戰(zhàn)略的規(guī)劃，所以我們MySQL選擇了上容器。

上容器解決的兩個技術要點：

容器對數(shù)據(jù)的持久化支持;

對服務的暴露。

整體我們MySQL上容器，在現(xiàn)階段僅僅是把它作為一個虛擬化的技術，它的整個高可用，包括它的整個監(jiān)控、整個的安裝部署都是通過我們之前提到的管理平臺來實施的。

通過上容器，我們提供了一鍵式的環(huán)境供給能力，通過上容器把IAAS、PAAS全部打通過了，能很快的把基礎環(huán)境，按照行內的標準和模式很快的供應出來。

資源的使用效率提升提升了4到5倍。截止當前我們行內在MySQL上容器這塊，應該是有400多個節(jié)點。

 

 

三、轉型成效

1、轉型實施成果

我們實施了至少120多個應用，2000多個服務器節(jié)點，超過2500個MySQL節(jié)點。

實施的應用涉及很多核心業(yè)務，包括個人賬戶、對公賬戶、基金以及很多A類、B類的應用，大多都是主機上遷移過來的。其中還有少量應用是從Oracle遷移過來的，應用層也因此需要重構。

我們通過MySQL支持的核心交易達到日均7億的交易量，經歷過雙十一、2018年的雙十一和春節(jié)的高峰期的1.5萬的TPS。

我們的架構現(xiàn)在通過橫向擴展可以達到幾萬的TPS。我們就是基于3萬TPS的設計目標進行了架構設計，理論上通過擴展設備還可以無限地增加。如果通過主機想達成這個目標，那么挑戰(zhàn)就會比較大。

另外通過良好的架構設計，我們可以滿足兩地三中心的架構要求，做到同城RPO=0，RTO<60s�，F(xiàn)在很多的“多活”，包括互聯(lián)網公司的架構，都是最多能夠做到分片雙活的維度，兩邊同時提供對外服務，但是同時對于某一分片數(shù)據(jù)的寫入只能是單活的。

通過架構轉型，我們在自主能力方面，初步建立了企業(yè)級的基于MySQL的分布式解決的自主能力：

首先是分布式框架+MySQL的應用級分布式解決方案，這個方案承載了我們很多的從主機下來的應用;

其次是基于分布式中間件構成了所謂聯(lián)機交易的數(shù)據(jù)庫，這樣能應對一些不是很復雜的場景，通過良好設計的分庫分表方案就可以滿足需求。

在成本方面，我們在主機上的成本投入明顯下降。

這幾年我們的業(yè)務交易量每年以20%的速度增長，但是主機并沒有進行擴容，投入還逐年降低。商業(yè)產品的數(shù)據(jù)庫的使用不僅實現(xiàn)零增長，還有所下降。從整個經費上來說，應該有比較大的降幅。

 

 

2、典型案例1：個人賬戶平臺

介紹一下作為我們架構設計原型的個人賬戶平臺，這是從主機上遷移下來的應用。

當時的交易要求高并發(fā)、低延時，日均交易量3億，這個應用的內部交易延時不能超過100ms，要求7×24小時的聯(lián)機服務。

我們實施的架構是高可用架構同城分片雙活。實施效果是日均交易量超1億以上，本地高可用做到自動化切換，RPO=0，RTO<30S。同城高可用切換也是60秒內切換。

同時結合MySQL的管理平臺，對自動化的切換能力進行了包裝，同城的切換會面臨著比較大的挑戰(zhàn)：

本地的高可用切換是基于SIP的，它是對應用透明的;

同城切換是對應用不透明的。

于是我們設計了從服務器到數(shù)據(jù)庫的整體切換流程，數(shù)據(jù)庫要和應用服務器進行一些聯(lián)動來實現(xiàn)同城自動化切換。

3、典型案例2：信息輔助服務

 

 

另外一個案例就是通過DBLE實現(xiàn)分布式數(shù)據(jù)庫。

這是第一個數(shù)據(jù)量比較大的系統(tǒng)，它要求高并發(fā)、低延時，日均交易量2億，交易響應延時要求10ms以內，當時的業(yè)務數(shù)據(jù)量大概20T左右，還要求7×24小時的聯(lián)機服務。

我們的架構是通過分布式中間件做MySQL的分庫分表，一共128個分片。我們對分片進行了合并部署，這看上去像是過度分片，但是資源使用上就收益很大。

DBLE中間件在日間進行聯(lián)機服務，夜間進行批量變更，把主機上的一些數(shù)據(jù)同步下來。

這個架構整體上實現(xiàn)了本地和同城完全自動化切換，RPO=0，RTO<30S。

四、后期工作思路

結合我們行的OLTP的數(shù)據(jù)轉型，后續(xù)幾個方向是我們行要大量工作的。

1、云化服務

現(xiàn)在SaaS云也好還是什么云也好，工行對于一些新的技術是保持跟蹤，當它有普遍性，很好的落地以后，可以使我們不會比互聯(lián)網慢一拍，在技術經過更多的打磨，我們認為它成熟以后再引用。

在云化服務方面，我們這邊結合像MySQL，像其它的一些數(shù)據(jù)庫，我們要加強云化服務的建設。

通過我們剛才的一些平臺也好，一些自主服務的建設也好，加強后面云化服務能力的建設。

2、數(shù)據(jù)統(tǒng)一交換

我們剛才提到消息平臺，它實現(xiàn)了應用和應用之間的數(shù)據(jù)交換，這個是業(yè)務級的。

那么我們現(xiàn)在除了這樣的一個業(yè)務級的，我們還需要一個系統(tǒng)級的來實現(xiàn)不同數(shù)據(jù)庫和數(shù)據(jù)庫系統(tǒng)級的準實時的數(shù)據(jù)的交換和復制，只有把數(shù)據(jù)流轉，把它活動起來了，那么數(shù)據(jù)才能更好的發(fā)揮它的業(yè)務價值，我們行目前也在建設這一塊的數(shù)據(jù)復制平臺。

3、Oracle的轉型

工行應該把Oracle這樣的一些特性用的非常極致;基本上都是存儲過程，當開發(fā)框架一確定，大家存儲過程都是用筆勾幾下或者拉幾下就可以產生很多的流程，但它同時和具體的數(shù)據(jù)庫綁定了，后面的維護、擴展都面臨比較大的挑戰(zhàn)。

比如說如何用相對可以接受，相對較低的代價進行Oracle的轉型，因為整個數(shù)據(jù)庫、整個應用重構開發(fā)的代價還是非常非常大的，這個也是我們的后面需要探索和思考的事情。

4、對分布式的數(shù)據(jù)庫

在分布式數(shù)據(jù)庫來說，我剛才說了，我們從2015年以來，就一直跟蹤著業(yè)界很多的分布式數(shù)據(jù)庫的產品。

我們應用級的分布式解決方案也好，包括我們的分布式訪問層的解決方案也好，可能有些場景還真的是無法應對的。

我們其實也在探索，隨著生態(tài)圈和國內技術的逐步成熟，我們也在考慮分布式數(shù)據(jù)庫技術的探索和引入的事情，同時從另外一個角度來說，在現(xiàn)在這種國際的關系形勢下，需要做一些技術的儲備，有自主支撐下來的能力。

 

標簽： [db:TAGG]

版權申明：本站文章部分自網絡，如有侵權，請聯(lián)系：west999com@outlook.com
特別注意：本站所有轉載文章言論不代表本站觀點！
本站所提供的圖片等素材，版權歸原作者所有，如需使用，請與原作者聯(lián)系。