如何設計高可用的MySQL架構？

將圍繞以下幾個方面展開：

• 工行 IT 架構轉型中傳統 OLTP 數據庫架構面臨的挑戰和訴求。

• 構建基於 MySQL 分佈式企業級解決方案實踐歷程，包括技術選擇、高可用設計、兩地三中心容災、運維管理、資源使用效率等方面的思考和實踐經驗。

• 工行轉型的成效以及對後續工做的一些思考。

 

數據庫轉型背景

 

傳統 IT 架構的挑戰

 

大型國有銀行，總體核心的系統都是大機+DB2 這樣的傳統架構；針對如今的互聯網金融業務快速擴張的需求，傳統的架構面臨着比較大的挑戰。

主要集中在以下四個方面：

• 處理能力：由於工行這麼大的體量，致使總體系統的規模比較龐大，這種垂直的單一的擴展模式，不具有橫向處理能力，處理能力受到限制。

• 運行的風險：隨着不少的業務從網點變成線上，新的業務提出了更高的業務連續性保障，包括 7×24 小時，傳統的架構從架構設計上沒法作到這樣的支持。

• 快速交付：傳統的開發模式應用內部模塊、應用與應用之間的耦合度很是高，使得軟件的開發和產品交付週期比較長。

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

 

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

 

轉型的核心訴求和策略

 

在上面的轉型大背景下，數據做爲核心，咱們展開了對開放平臺的數據庫的架構轉型，同時提出了幾個核心的策略：

首先，在業務支撐方面，作到高併發、可擴展、支持海量數據存儲及訪問，以及兩地三中心高可用容災。工行在國有大型銀行裏應該是比較領先的實現了兩地三中心容災體系。

 

其次，下降使用成本，基於通用的廉價的硬件基礎設施，但願提高本身的管理控制能力，進行行內適配和定製。下降對商業產品依賴，提高議價能力。

 

還有就是運維能力，提高數據庫的運維自動化智能化，更加開放的技術體系以利於自主掌控。

 

主要採起三方面策略：

• 集中式向分佈式的轉型。

• 專有向通用的轉型，也就是去 IOE。

• 限制商業產品，擁抱開源。

 

轉型的發展經歷

 

三年轉型之路

 

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

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

 

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

 

結合這樣的工做要求，把我的帳戶從主機下移到開放平臺，基於開放平臺的高性價比、可擴展進行了不少的探索，不少的技術驗證。

 

當驗證了技術可行性以後，咱們提出了一個開放平臺數據庫轉型的規劃，這個規劃對於咱們行內後面幾年的工做，對於數據庫的方案選型是很是大的影響。

 

這個規劃肯定咱們行裏要建設基於開源的 MySQL OLTP 數據庫解決方案。

 

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

 

2017 年全年，咱們基於開源的 MySQL 數據庫進行產品的研究和能力的建設，以及初步能力的建設，包括基礎研究和應用的試點。

 

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

 

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

 

2018 年開始大規模的實施和推廣，在這個過程當中基於開源的 MySQL 數據庫，咱們逐步創建起了一個企業級的數據庫服務能力，包括引入了分佈式的中間件，在高可用、運維能力的提高，資源使用率的提高，MySQL 的雲化及自主服務的建設等等。

 

在整個過程當中，同步對 OLTP 的分佈式數據庫進行了研究，也對後面的工做指導提供了依據。

 

選型階段

 

①方案選型調研

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

 

NewSQL 數據庫方案，是不少的互聯網企業或者一些小型企業有所使用的，可是我行在選擇技術的時候是很是謹慎的，以及要作很是多驗證，在當時並不符合咱們系統設計的考量點。

 

基於開源的分佈式 OLTP 方案，業界有不少豐富的案例，並且在互聯網企業裏面獲得了很好的實踐，在業界資源案例都很豐富，是同時能應對我行的高併發、彈性擴展需求的。

 

因此咱們最終肯定從分佈式架構的角度去解決整個架構的挑戰，不只僅只從單一的數據庫的層面解決這個問題。

 

②分佈式技術棧

基於這樣的一個原型探索，咱們構建了一系列的分佈式架構技術棧，包括分佈式服務、分佈式事務框架、分佈式批量框架、分佈式緩存、交易數據覈對及補償、分佈式消息、配置中心、開發及運維管理。

 

這裏簡單說一下：

• 分佈式服務改造，針對咱們傳統架構耦合比較緊密的特色，經過服務化的改造，下降耦合度。下降耦合度的同時，還能夠盡最大可能的避免分佈式事務的產生。

• 分佈式事務的框架，咱們結合兩階段提交和分佈式的消息，支持強一致性和最終一致性多種模式的支持，經過分佈式事務框架解決分佈式事務的問題。

• 分佈式批量框架，在大規模的數據結點上進行批量操做的一個總體的解決方案。

• 業務層面，在交易或者應用級層面進行數據覈對及補償，有些場景就是在傳統的 OLTP 的狀況下，也會對應用上下游進行覈對和補償。

• 分佈式消息平臺，實現這樣一個應用級的數據交互。

 

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

 

③MySQL 高可用方案

在原型階段，當時主流是 MySQL 5.六、5.7 纔剛出來；對於高可用要求，行裏的應用是要作到同城切換，上海兩個園區要作到 RPO 是 0，RTO 很是小，同時異地北京有一個災備中心，就是兩地三中心。

 

咱們的 AB 類重點應用必須具有這樣的同城兩個園區同時對外服務的能力。

 

在原型設計階段，咱們基於 MySQL 的半同步複製，來作這樣的一個切換，實現 RPO=0，解決主庫故障自動切換到備庫，同城爲了保障 RPO=0，在原型階段進行了應用的雙寫，來進行數據的核對和補充。

 

這裏順便提一下，MySQL 5.7 相對 5.6 的改進很是大的，這是一款真正能夠適合金融行業的數據庫產品，它在數據回放方面，在性能方面都有比較大的改進和提高。

 

實施推廣階段

 

①基礎研究和應用試點

 

第二個階段是開源 MySQL 基礎研究和應用試點，就是 2017 年。對於這些元素研究之後，在行裏要發佈第一個產品；把這個產品推上線，要作不少的工做：

 

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

 

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

 

包括應用的開發規範，它的性能能力評估，上線須要多少設備，容量是多大，還要對 Oracle 等老架構給予指引和幫助，代碼寫很差還要弄個檢查工具等等。

 

運維方面就是要提供各類安裝部署的便利化，而後行內和行內的監控系統進行對接，制定不少的指標和參數，如何和行裏進行對接，而後新問題的分析等等一系列的問題。

 

在這個階段咱們實現了同城 RPO=0，RTO=分鐘級目標，RPO 爲 0 的切換，問題可監控，實現了人工或自動的一鍵式切換。

這個階段，行裏決策了以後，咱們 2017 年一會兒上了 21 個應用，211 個節點。

 

②分佈式中間件應用

 

2018 年開始轉型和實施，而且大量應用上線；以前的基於應用級的分佈式解決方案，遇到了一些新的限制。

部分應用不想設計的過度複雜，這個時候引入了開源分佈式中間件 DBLE，引入它的目的就是爲了簡化開發的工做量。

 

經過引入這樣一個 DBLE 來支持垂直數據分片、水平數據分片、混合分片等場景的支持，還支持簡單的跨庫聚集查詢提供相似集中庫的操做體驗，這個時候開發場景就簡化了，給了應用更多的選擇，簡化了應用開發的複雜度。

 

③運維架構流程完善

 

解決了應用開發的複雜度，運維怎麼辦？高可用怎麼辦？

咱們結合 DBLE 和運維管理平臺，實現整平臺聯動，支持從高可用、監控告警、安裝部署、自動化補數等等一系列的解決方案。

 

④運維管理能力沉澱

 

這時進行運維能力的提高，也迫在眉睫；由於分佈式隨着實施的運維節點的增長，運維是一個很大的挑戰，那麼多的節點，安裝、監控、報警、故障、人工處理等很是麻煩。

咱們的作法：

• 先提供一個自動化的安裝部署，實現批量安裝部署，批量串行還不行，時間太長了，要並行，並行過高了，網絡的流量會受到比較大的影響，因此這個方面有不少的場景都須要打磨。

• 監控告警，監控告警裏有事件等級，分各類等級，這些須要靈活的定製，創建基線告警，創建應急流程。

• 故障的分析，完善日誌記錄、採集和分析，創建故障分析規範。

• 自動巡檢，自動化的巡檢和評分報告，對實例狀態進行健康評分。

 

⑤統一運維平臺創建

 

咱們經過這樣一個統一的運維管理平臺，把全部的節點都歸入進來了，實現一鍵式的安裝、版本的升級、參數的配置。而且實現了多種高可用策略配置，包括自動、人工一鍵式切換。

談到爲何要有自動化和人工的兩種切換方式？一種新的事務上線以前，都會面臨一些挑戰和懷疑的，都是一個按部就班的過程，特別是是在金融行業，咱們實現了多種高可用策略的靈活配置。

 

⑥故障自動切換上線

 

咱們創建了一個自動化、高可用的決策系統。你們知道人工決策到自動切換，雖然只是邁出一步，可是面臨着很大的挑戰：

 

包括決策的因素和決策的模型，最難的是還要應對不一樣應用場景的需求，有的時候說 RPO 優先，有的 RTO 優先。

 

有的要求三分鐘搞定，有的說 10 秒鐘 5 秒鐘我都難受。你要有這樣的模型適配這樣的場景，這是很是大的挑戰。

在總體上面基於 MySQL 的複製技術，咱們有半同步複製和多數派共識機制實現冗餘備份。基於 MySQL binlog 日誌實現自動數據補全，保障數據的一致性。

 

實踐中的改善優化

 

①高可用方案改進

 

同時實施過程當中咱們走的比較快了，一年幾百個節點，幾十個應用。

在這個過程當中，咱們又對高可用方案進行了持續的優化，同時學習和借鑑互聯網包括分佈式數據庫的一些方案。

 

咱們把 1 主 2 備，本地 1 備和同城 1 備，擴展成 1 主 3 備，經過半同步的機制，作到真正的在系統級去保證 RPO=0。

 

②異地災備和存儲優化

 

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

 

剛纔說了，咱們在上海到北京有一個災備。數據災備剛開始，方案採用磁盤複製實現災備，這個也是要支出軟件費用，也比較耗錢。

 

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

 

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

在應對一些高併發場景的時候，由於 IO 性能不足，這方面咱們就改進了，直接引入了 SSD 盤，基本上把 MySQL、IO 的瓶頸給解決了。

 

在如今的場景下，IO 通常不會成爲瓶頸了。同時經過 SSD 的引入，交易的響應時間在相同條件降低低 50%。

 

③MySQL 容器化探索

 

MySQL 的上容器，首先說一下爲何要搞這個事情？

 

由於工行一兩年轉型過來，大規模的上 MySQL 數據庫，節點很是多，機房和設備成爲一個瓶頸，再這麼玩兒下去機房容量不足了。這個時候須要提高資源的使用效率。

 

在不少應用裏，由於它的超前規劃，通常爲了穩定運行，基本上都提出資源申請的時候，都是物理機，爲了知足後面幾年的業務需求，大規模的申請物理機，但當前應用的交易量又不是那麼大，浪費是比較嚴重的。

 

這個時候咱們提高資源的使用成爲緊迫的問題。這個過程當中爲何選擇 MySQL 的容器呢？

幾點考量：

• 行業化裏的商業軟件都是用的 VMware。

• VMware 在 IO 方面，在系統性能方面都有比較大的損耗。

• 行裏在 Iaas、Paas 方面建設好多年了，咱們無狀態的應用服務其實所有上了 Paas，所有上了容器，在這方面有一些技術的積累，結合行內對於雲戰略的規劃，因此咱們 MySQL 選擇了上容器。

 

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

• 容器對數據的持久化支持。

• 對服務的暴露。

 

總體咱們 MySQL 上容器，在現階段僅僅是把它做爲一個虛擬化的技術，它的整個高可用，包括它的整個監控、整個的安裝部署都是經過咱們以前提到的管理平臺來實施的。

 

經過上容器，咱們提供了一鍵式的環境供給能力，經過上容器把 Iaas、Paas 所有打經過了，能很快的把基礎環境，按照行內的標準和模式很快的供應出來。

 

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

 

轉型成效

 

①轉型實施成果

 

咱們實施了至少 120 多個應用，2000 多個服務器節點，超過 2500 個 MySQL 節點。

 

實施的應用涉及不少核心業務，包括我的帳戶、對公帳戶、基金以及不少 A 類、B 類的應用，大多都是主機上遷移過來的。其中還有少許應用是從 Oracle 遷移過來的，應用層也所以須要重構。

 

咱們經過 MySQL 支持的核心交易達到日均 7 億的交易量，經歷過雙11、2018 年的雙十一和春節的高峯期的 1.5 萬的 TPS。

 

咱們的架構如今經過橫向擴展能夠達到幾萬的 TPS。咱們就是基於 3 萬 TPS 的設計目標進行了架構設計，理論上經過擴展設備還能夠無限地增長。若是經過主機想達成這個目標，那麼挑戰就會比較大。

 

另外經過良好的架構設計，咱們能夠知足兩地三中心的架構要求，作到同城 RPO=0，RTO<60s。

 

如今不少的「多活」，包括互聯網公司的架構，都是最多可以作到分片雙活的維度，兩邊同時提供對外服務，可是同時對於某一分片數據的寫入只能是單活的。

 

經過架構轉型，咱們在自主能力方面，初步創建了企業級的基於 MySQL 的分佈式解決的自主能力：

• 首先是分佈式框架+MySQL 的應用級分佈式解決方案，這個方案承載了咱們不少的從主機下來的應用。

• 其次是基於分佈式中間件構成了所謂聯機交易的數據庫，這樣能應對一些不是很複雜的場景，經過良好設計的分庫分表方案就能夠知足需求。

 

在成本方面，咱們在主機上的成本投入明顯降低。這幾年咱們的業務交易量每一年以 20% 的速度增加，可是主機並無進行擴容，投入還逐年下降。

 

商業產品的數據庫的使用不只實現零增加，還有所降低。從整個經費上來講，應該有比較大的降幅。

 

②典型案例 1：我的帳戶平臺

 

介紹一下做爲咱們架構設計原型的我的帳戶平臺，這是從主機上遷移下來的應用。

 

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

 

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

 

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

• 本地的高可用切換是基於 SIP 的，它是對應用透明的。

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

 

因而咱們設計了從服務器到數據庫的總體切換流程，數據庫要和應用服務器進行一些聯動來實現同城自動化切換。

 

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

另一個案例就是經過 DBLE 實現分佈式數據庫。

 

這是第一個數據量比較大的系統，它要求高併發、低延時，日均交易量 2 億，交易響應延時要求 10ms 之內，當時的業務數據量大概 20T 左右，還要求 7×24 小時的聯機服務。

 

咱們的架構是經過分佈式中間件作 MySQL 的分庫分表，一共 128 個分片。咱們對分片進行了合併部署，這看上去像是過分分片，可是資源使用上就收益很大。

 

DBLE 中間件在日間進行聯機服務，夜間進行批量變動，把主機上的一些數據同步下來。

 

這個架構總體上實現了本地和同城徹底自動化切換，RPO=0，RTO<30S。

 

後期工做思路

 

結合咱們行的 OLTP 的數據轉型，後續幾個方向是咱們行要作大量工做的。

 

雲化服務

 

如今 SaaS 雲也好仍是什麼雲也好，工行對於一些新的技術是保持跟蹤，當它有廣泛性，很好的落地之後，可使咱們不會比互聯網慢一拍，在技術通過更多的打磨，咱們認爲它成熟之後再引用。

 

在雲化服務方面，咱們這邊結合像 MySQL，像其它的一些數據庫，咱們要增強雲化服務的建設。

 

經過咱們剛纔的一些平臺也好，一些自主服務的建設也好，增強後面雲化服務能力的建設。

 

數據統一交換

 

咱們剛纔提到消息平臺，它實現了應用和應用之間的數據交換，這個是業務級的。

 

那麼咱們如今除了這樣的一個業務級的，咱們還須要一個系統級的來實現不一樣數據庫和數據庫系統級的準實時的數據的交換和複製。

 

只有把數據流轉，把它活動起來了，那麼數據才能更好的發揮它的業務價值，咱們行目前也在建設這一塊的數據複製平臺。

 

Oracle 的轉型

 

工行應該把 Oracle 這樣的一些特性用的很是極致；基本上都是存儲過程，當開發框架一肯定，你們存儲過程都是用筆勾幾下或者拉幾下就能夠產生不少的流程，但它同時和具體的數據庫綁定了，後面的維護、擴展都面臨比較大的挑戰。

 

好比說如何用相對能夠接受，相對較低的代價進行 Oracle 的轉型，由於整個數據庫、整個應用重構開發的代價仍是很是很是大的，這個也是咱們的後面須要探索和思考的事情。

 

對分佈式的數據庫

 

對分佈式數據庫來講，咱們從 2015 年以來，就一直跟蹤着業界不少的分佈式數據庫的產品。

 

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

 

咱們也在探索，隨着生態圈和國內技術的逐步成熟，咱們也在考慮分佈式數據庫技術的探索和引入的事情，同時從另一個角度來講，在如今這種國際的關係形勢下，須要作一些技術的儲備，有自主支撐下來的能力。