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

工行 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.6、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 億的交易量，經歷過雙十一、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 年以來，就一直跟蹤著業界很多的分布式數據庫的產品。

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

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