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

關鍵詞：擁抱開源；MySQL； 高可用； 分散式；數據拆分； DBLE； 管理平台；災備；容器；演講者介紹：林承軍，中國工商銀行軟體開發中心高級經理，多年來一直從事開放平台相關技術研究及實施工作，多次參與工行重點項目的原型技術研究、IT 架構轉型及優化提升，在分散式、高可用架構、數據高效訪問領域有豐富的實施經驗。近年來，牽頭 MySQL/分散式資料庫團隊工作，借鑒和引入業界成功經驗，通過自主研發 技術引入，迅速形成基於開源 MySQL 的企業級應用研發能力，初步建立了企業級解決方案，推動工行開放平台 OLTP 資料庫轉型的實施。本文目錄：一、資料庫轉型背景

1.1 傳統IT架構的挑戰

1.2 轉型的核心訴求和策略二、轉型的發展之路2.1 轉型路線圖2.1.1 三年轉型之路2.2 選型階段2.2.1 方案選型調研2.2.2 分散式技術線2.2.3 MySQL高可用方案2.3 實施推廣階段

2.3.1 基礎研究和應用試點

2.3.2 分散式中間件應用2.3.3 運維架構流程完善2.3.4 運維管理能力沉澱2.3.5 統一運維平台建立2.3.6故障自動切換上線2.4 事件中的改善優化2.4.1 高可用方案改進2.4.2 異地災備和訓處優化2.4.3 MySQL 容器化探索

三、轉型成效

3.1 轉型實施成果3.2 典型案例1：個人賬戶平台3.3典型案例2：信息輔助服務四、後期工作思路

一、資料庫轉型背景

1.1 傳統IT架構的挑戰

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

• 處理能力；因為工行這麼大的體量，導致整體系統的規模比較龐大，這種垂直的單一的擴展模式，不具備橫向處理能力，處理能力受到限制；
• 運行的風險；隨著很多的業務從網點變成線上，新的業務提出了更高的業務連續性保障，包括7×24小時，傳統的架構從架構設計上無法做到這樣的支持；
• 快速交付；傳統的開發模式應用內部模塊、應用與應用之間的耦合度非常高，使得軟體的開發和產品交付周期比較長；
• 成本控制；大型主機運營成本非常貴，買個機器幫你搞兩下就幾千萬上億的支出，再加上商業產品的License比較高，銀行議價能力又比較低；

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

1.2 轉型的核心訴求和策略

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

1. 第一，在業務支撐方面，做到高並發、可擴展、支持海量數據存儲及訪問。以及兩地三中心高可用容災。工行在國有大型銀行里應該是比較領先的實現兩地三中心容災體系；
2. 第二，降低使用成本，基於通用的廉價的硬體基礎設施，希望提升自己的管理控制能力，進行行內適配和定製。降低對商業產品依賴，提升議價能力；
3. 第三，運維能力，提升資料庫的運維自動化智能化，更加開放的技術體系以利於自主掌控。主要採取三方面策略：

• 一：集中式向分散式的轉型；
• 二：是專有向通用的轉型，也就是去IOE；
• 三：限制商業產品，擁抱開源；

二、 轉型的發展經歷

2.1 轉型路線圖

2.1.1 三年轉型之路

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

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

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

第二階段 基礎研究和試點

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

第三階段 轉型實施及推廣

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

2.2 選型階段

2.2.1 方案選型調研

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

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

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

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

2.2.2 分散式技術棧

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

• 分散式服務改造，針對我們傳統架構耦合比較緊密的特點，通過服務化的改造，降低耦合度。降低耦合度的同時，還可以盡最大可能的避免分散式事務的產生；
• 分散式事務的框架，我們結合兩階段提交和分散式的消息，支持強一致性和最終一致性多種模式的支持，通過分散式事務框架解決分散式事務的問題；
• 分散式批量框架，在大規模的數據結點上進行批量操作的一個整體的解決方案；
• 業務層面，在交易或者應用級層面進行數據核對及補償，有些場景就是在傳統的OLTP的情況下，也會對應用上下游進行核對和補償；
• 分散式消息平台，實現這樣一個應用級的數據交互；

同時我們也進行了運維的規劃和總設計。這裡引入了開源的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；

2.4.2 異地災備和存儲優化

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

我們剛才說了，我們在上海到北京有一個災備。數據災備剛開始方案，採用磁碟複製實現災備，這個也是要支出軟體費用，也比較耗錢。第二個是冷備，無法熱切換，RTO至少半個小時以上。這個方面我們改進了，用了MySQL非同步複製；

另外存儲方面沿用的集中存儲，一套集中存儲上面同時支撐六七十上百個MySQL實例，IO的性能非常容易成為瓶頸。在應對一些高並發場景的時候，因為IO性能不足，這方面我們就改進了，直接引入了SSD盤，基本上把MySQL、IO的瓶頸給解決了。在現在的場景下，IO一般不會成為瓶頸了。同時通過SSD的引入，交易的響應時間在相同條件下降低50%。

2.4.3 MySQL 容器化探索

MySQL的上容器，首先說一下為什麼要搞這個事情？因為工行一兩年轉型過來，大規模的上MySQL資料庫，節點非常多，機房和設備成為一個瓶頸，再這麼玩兒下去機房容量不足了。這個時候需要提升資源的使用效率。

在很多應用里，因為它的超前規劃，一般為了穩定運行，基本上都提出資源申請的時候，都是物理機，為了滿足後面幾年的業務需求，大規模的申請物理機，但當前應用的交易量又不是那麼大，浪費比較嚴重的。這個時候我們提升資源的使用成為緊迫的問題。這個過程中為什麼選擇MySQL的容器呢？幾點考量：

第一、行業化里的商業軟體都是用的VMware，

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

第三、行里在IAAS、PAAS方面建設好多年了，我們無狀態的應用服務其實全部上了PAAS，全部上了容器，在這方面有一些技術的積累，結合行內對於雲戰略的規劃，所以我們MySQL選擇了上容器。上容器解決的兩個技術要點：

• 第一個就是容器對數據的持久化支持；
• 第二個是對服務的暴露；

整體我們MySQL上容器，在現階段僅僅是把它作為一個虛擬化的技術，它的整個高可用，包括它的整個監控、整個的安裝部署都是通過我們之前提到的管理平台來實施的。通過上容器，我們提供了一鍵式的環境供給能力，通過上容器把IAAS、PAAS全部打通過了，能很快的把基礎環境，按照行內的標準和模式很快的供應出來。資源的使用效率提升提升了4到5倍。截止當前我們行內在MySQL上容器這塊，應該是有400多個節點。

三、轉型成效

3.1 轉型實施成果

我們實施了至少120多個應用，2000多個伺服器節點，超過2500個MySQL節點。實施的應用涉及很多核心業務，包括個人賬戶、對公賬戶、基金以及很多A類、B類的應用，大多都是主機上遷移過來的。其中還有少量應用是從Oracle遷移過來的，應用層也因此需要重構。

我們通過MySQL支持的核心交易達到日均7億的交易量，經歷過雙十一、2018年的雙十一和春節的高峰期的1.5萬的TPS。我們的架構現在通過橫向擴展可以達到幾萬的TPS。我們就是基於3萬TPS的設計目標進行了架構設計，理論上通過擴展設備還可以無限地增加。如果通過主機想達成這個目標，那麼挑戰就會比較大。

另外通過良好的架構設計，我們可以滿足兩地三中心的架構要求，做到同城RPO=0，RTO<60s。剛才有人問到同城雙活多活，現在很多的"多活"，包括互聯網公司的架構，都是最多能夠做到分片雙活的維度，兩邊同時提供對外服務，但是同時對於某一分片數據的寫入只能是單活的。

通過架構轉型，我們在自主能力方面，初步建立了企業級的基於MySQL的分散式解決的自主能力：首先是分散式框架+MySQL的應用級分散式解決方案，這個方案承載了我們很多的從主機下來的應用。其次是基於分散式中間件構成了所謂聯機交易的資料庫，這樣能應對一些不是很複雜的場景，通過良好設計的分庫分表方案就可以滿足需求。

在成本方面，我們在主機上的成本投入明顯下降。這幾年我們的業務交易量每年以20%的速度增長，但是主機並沒有進行擴容，投入還逐年降低。商業產品的資料庫的使用不僅實現零增長，還有所下降。從整個經費上來說，應該有比較大的降幅。

3.2 典型案例1：個人賬戶平台

介紹一下作為我們架構設計原型的個人賬戶平台，這是從主機上遷移下來的應用。當時的交易要求高並發、低延時，日均交易量3億，這個應用的內部交易延時不能超過100ms，要求7×24小時的聯機服務。

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

同時結合MySQL的管理平台，對自動化的切換能力進行了包裝，同城的切換會面臨著比較大的挑戰:本地的高可用切換是基於SIP的，它是對應用透明的；而同城切換是對應用不透明的。於是我們設計了從伺服器到資料庫的整體切換流程，資料庫要和應用伺服器進行一些聯動來實現同城自動化切換。

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

另外一個案例就是通過DBLE實現分散式資料庫。這是第一個數據量比較大的系統，它要求高並發、低延時，日均交易量2億，交易響應延時要求10ms以內，當時的業務數據量大概20T左右，還要求7×24小時的聯機服務。我們的架構是通過分散式中間件做MySQL的分庫分表，一共128個分片。我們對分片進行了合併部署，這看上去像是過度分片，但是資源使用上就收益很大。DBLE中間件在日間進行聯機服務，夜間進行批量變更，把主機上的一些數據同步下來。這個架構整體上實現了本地和同城完全自動化切換，RPO=0，RTO<30S。

四、後期工作思路

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

第一個是雲化服務。現在SaaS雲也好還是什麼雲也好，工行對於一些新的技術是保持跟蹤，當它有普遍性，很好的落地以後，可以使我們不會比互聯網慢一拍，在技術經過更多的打磨，我們認為它成熟以後再引用。在雲化服務方面，我們這邊結合像MySQL，像其它的一些資料庫，我們要加強雲化服務的建設。通過我們剛才的一些平台也好，一些自主服務的建設也好，加強後面雲化服務能力的建設。

第二個是數據統一交換。我們剛才提到消息平台，它實現了應用和應用之間的數據交換，這個是業務級的。那麼我們現在除了這樣的一個業務級的，我們還需要一個系統級的來實現不同資料庫和資料庫系統級的准實時的數據的交換和複製，只有把數據流轉，把它活動起來了，那麼數據才能更好的發揮它的業務價值，我們行目前也在建設這一塊的數據複製平台。

第三個就是Oracle的轉型。工行應該把Oracle這樣的一些特性用的非常極致；基本上都是存儲過程，當開發框架一確定，大家存儲過程都是用筆勾幾下或者拉幾下就可以產生很多的流程，但它同時和具體的資料庫綁定了，後面的維護、擴展都面臨比較大的挑戰。比如說如何用相對可以接受，相對較低的代價進行Oracle的轉型，因為整個資料庫、整個應用重構開發的代價還是非常非常大的，這個也是我們的後面需要探索和思考的事情。

第四個就是對分散式的資料庫。在分散式資料庫來說，我剛才說了，我們從2015年以來，就一直跟蹤著業界很多的分散式資料庫的產品。我們應用級的分散式解決方案也好，包括我們的分散式訪問層的解決方案也好，可能有些場景還真的是無法應對的。我們其實也在探索，隨著生態圈和國內技術的逐步成熟，我們也在考慮分散式資料庫技術的探索和引入的事情，同時從另外一個角度來說，在現在這種國際的關係形勢下，需要做一些技術的儲備，有自主支撐下來的能力。

*聲明：用戶故事來源於DTCC公開演講內容。

對宇宙行的架構解密還不過癮？

歡迎參加 6.15 分散式中間件DBLE用戶見面會，屆時我們會解密更多的技術細節！

推薦閱讀：