將圍繞如下幾個(gè)方面展開：

• 工行 IT 架構(gòu)轉(zhuǎn)型中傳統(tǒng) OLTP 數(shù)據(jù)庫架構(gòu)面臨的挑戰(zhàn)和訴求。

• 構(gòu)建基于 MySQL 分布式企業(yè)級(jí)解決方案實(shí)踐歷程，包括技術(shù)選擇、高可用設(shè)計(jì)、兩地三中心容災(zāi)、運(yùn)維管理、資源使用效率等方面的思考和實(shí)踐經(jīng)驗(yàn)。

• 工行轉(zhuǎn)型的成效以及對(duì)后續(xù)工作的一些思考。

大型國有銀行，整體核心的系統(tǒng)都是大機(jī)+DB2 這樣的傳統(tǒng)架構(gòu)；針對(duì)現(xiàn)在的互聯(lián)網(wǎng)金融業(yè)務(wù)快速擴(kuò)張的需求，傳統(tǒng)的架構(gòu)面臨著比較大的挑戰(zhàn)。

主要集中在如下四個(gè)方面：

• 處理能力：因?yàn)楣ば羞@么大的體量，導(dǎo)致整體系統(tǒng)的規(guī)模比較龐大，這種垂直的單一的擴(kuò)展模式，不具備橫向處理能力，處理能力受到限制。

• 運(yùn)行的風(fēng)險(xiǎn)：隨著很多的業(yè)務(wù)從網(wǎng)點(diǎn)變成線上，新的業(yè)務(wù)提出了更高的業(yè)務(wù)連續(xù)性保障，包括 7×24 小時(shí)，傳統(tǒng)的架構(gòu)從架構(gòu)設(shè)計(jì)上無法做到這樣的支持。

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

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

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

在上面的轉(zhuǎn)型大背景下，數(shù)據(jù)作為核心，我們展開了對(duì)開放平臺(tái)的數(shù)據(jù)庫的架構(gòu)轉(zhuǎn)型，同時(shí)提出了幾個(gè)核心的策略：

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

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

還有就是運(yùn)維能力，提升數(shù)據(jù)庫的運(yùn)維自動(dòng)化智能化，更加開放的技術(shù)體系以利于自主掌控。

主要采取三方面策略：

• 集中式向分布式的轉(zhuǎn)型。

• 專有向通用的轉(zhuǎn)型，也就是去 IOE。

• 限制商業(yè)產(chǎn)品，擁抱開源。

整個(gè)轉(zhuǎn)型歷程，大概從 2015 年開始 IT 架構(gòu)轉(zhuǎn)型，但真正有進(jìn)展應(yīng)該是從 2016 年初到 2017 年這個(gè)時(shí)間。我們整個(gè)的發(fā)展歷程大概可以分三個(gè)階段：

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

2016 年初到 2017 年的過程，當(dāng)時(shí)結(jié)合人民銀行對(duì)于個(gè)人賬戶的管理要求，實(shí)行一類二類三類賬戶。

結(jié)合這樣的工作要求，把個(gè)人賬戶從主機(jī)下移到開放平臺(tái)，基于開放平臺(tái)的高性價(jià)比、可擴(kuò)展進(jìn)行了很多的探索，很多的技術(shù)驗(yàn)證。

當(dāng)驗(yàn)證了技術(shù)可行性之后，我們提出了一個(gè)開放平臺(tái)數(shù)據(jù)庫轉(zhuǎn)型的規(guī)劃，這個(gè)規(guī)劃對(duì)于我們行內(nèi)后面幾年的工作，對(duì)于數(shù)據(jù)庫的方案選型是非常大的影響。

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

第二階段：基礎(chǔ)研究和試點(diǎn)

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

在此期間，前面提到的原型也是在 2017 年 5 月份上線的，在生產(chǎn)線上跑起來了，把整個(gè)技術(shù)體系都進(jìn)行了驗(yàn)證。

第三階段：轉(zhuǎn)型實(shí)施及推廣

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

在整個(gè)過程中，同步對(duì) OLTP 的分布式數(shù)據(jù)庫進(jìn)行了研究，也對(duì)后面的工作指導(dǎo)提供了依據(jù)。

①方案選型調(diào)研

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

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

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

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

②分布式技術(shù)棧

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

這里簡單說一下：

• 分布式服務(wù)改造，針對(duì)我們傳統(tǒng)架構(gòu)耦合比較緊密的特點(diǎn)，通過服務(wù)化的改造，降低耦合度。降低耦合度的同時(shí)，還可以盡最大可能的避免分布式事務(wù)的產(chǎn)生。

• 分布式事務(wù)的框架，我們結(jié)合兩階段提交和分布式的消息，支持強(qiáng)一致性和最終一致性多種模式的支持，通過分布式事務(wù)框架解決分布式事務(wù)的問題。

• 分布式批量框架，在大規(guī)模的數(shù)據(jù)結(jié)點(diǎn)上進(jìn)行批量操作的一個(gè)整體的解決方案。

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

• 分布式消息平臺(tái)，實(shí)現(xiàn)這樣一個(gè)應(yīng)用級(jí)的數(shù)據(jù)交互。

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

③MySQL 高可用方案

在原型階段，當(dāng)時(shí)主流是 MySQL 5.6、5.7 才剛出來；對(duì)于高可用要求，行里的應(yīng)用是要做到同城切換，上海兩個(gè)園區(qū)要做到 RPO 是 0，RTO 非常小，同時(shí)異地北京有一個(gè)災(zāi)備中心，就是兩地三中心。

我們的 AB 類重點(diǎn)應(yīng)用必須具備這樣的同城兩個(gè)園區(qū)同時(shí)對(duì)外服務(wù)的能力。

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

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

①基礎(chǔ)研究和應(yīng)用試點(diǎn)

第二個(gè)階段是開源 MySQL 基礎(chǔ)研究和應(yīng)用試點(diǎn)，就是 2017 年。對(duì)于這些元素研究以后，在行里要發(fā)布第一個(gè)產(chǎn)品；把這個(gè)產(chǎn)品推上線，要做很多的工作：

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

我們的角色既要考慮到運(yùn)維，也要考慮到上游應(yīng)用，做好上面的銜接、對(duì)接和支持。

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

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

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

這個(gè)階段，行里決策了之后，我們 2017 年一下子上了 21 個(gè)應(yīng)用，211 個(gè)節(jié)點(diǎn)。

②分布式中間件應(yīng)用

2018 年開始轉(zhuǎn)型和實(shí)施，并且大量應(yīng)用上線；之前的基于應(yīng)用級(jí)的分布式解決方案，遇到了一些新的限制。

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

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

③運(yùn)維架構(gòu)流程完善

解決了應(yīng)用開發(fā)的復(fù)雜度，運(yùn)維怎么辦？高可用怎么辦？

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

④運(yùn)維管理能力沉淀

這時(shí)進(jìn)行運(yùn)維能力的提升，也迫在眉睫；因?yàn)榉植际诫S著實(shí)施的運(yùn)維節(jié)點(diǎn)的增加，運(yùn)維是一個(gè)很大的挑戰(zhàn)，那么多的節(jié)點(diǎn)，安裝、監(jiān)控、報(bào)警、故障、人工處理等非常麻煩。

我們的做法：

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

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

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

• 自動(dòng)巡檢，自動(dòng)化的巡檢和評(píng)分報(bào)告，對(duì)實(shí)例狀態(tài)進(jìn)行健康評(píng)分。

⑤統(tǒng)一運(yùn)維平臺(tái)建立

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

談到為什么要有自動(dòng)化和人工的兩種切換方式？一種新的事務(wù)上線之前，都會(huì)面臨一些挑戰(zhàn)和懷疑的，都是一個(gè)循序漸進(jìn)的過程，特別是是在金融行業(yè)，我們實(shí)現(xiàn)了多種高可用策略的靈活配置。

⑥故障自動(dòng)切換上線

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

包括決策的因素和決策的模型，最難的是還要應(yīng)對(duì)不同應(yīng)用場景的需求，有的時(shí)候說 RPO 優(yōu)先，有的 RTO 優(yōu)先。

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

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

①高可用方案改進(jìn)

同時(shí)實(shí)施過程中我們走的比較快了，一年幾百個(gè)節(jié)點(diǎn)，幾十個(gè)應(yīng)用。

在這個(gè)過程中，我們又對(duì)高可用方案進(jìn)行了持續(xù)的優(yōu)化，同時(shí)學(xué)習(xí)和借鑒互聯(lián)網(wǎng)包括分布式數(shù)據(jù)庫的一些方案。

我們把 1 主 2 備，本地 1 備和同城 1 備，擴(kuò)展成 1 主 3 備，通過半同步的機(jī)制，做到真正的在系統(tǒng)級(jí)去保證 RPO=0。

②異地災(zāi)備和存儲(chǔ)優(yōu)化

異地災(zāi)備和存儲(chǔ)方面，當(dāng)初跑的太快，方方面面有些沒有考慮那么完備。

剛才說了，我們?cè)谏虾５奖本┯幸粋€(gè)災(zāi)備。數(shù)據(jù)災(zāi)備剛開始，方案采用磁盤復(fù)制實(shí)現(xiàn)災(zāi)備，這個(gè)也是要支出軟件費(fèi)用，也比較耗錢。

還有就是冷備，無法熱切換，RTO 至少半個(gè)小時(shí)以上。這個(gè)方面我們改進(jìn)了，用了 MySQL 異步復(fù)制。

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

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

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

③MySQL 容器化探索

MySQL 的上容器，首先說一下為什么要搞這個(gè)事情？

因?yàn)楣ば幸粌赡贽D(zhuǎn)型過來，大規(guī)模的上 MySQL 數(shù)據(jù)庫，節(jié)點(diǎn)非常多，機(jī)房和設(shè)備成為一個(gè)瓶頸，再這么玩兒下去機(jī)房容量不足了。這個(gè)時(shí)候需要提升資源的使用效率。

在很多應(yīng)用里，因?yàn)樗某耙?guī)劃，一般為了穩(wěn)定運(yùn)行，基本上都提出資源申請(qǐng)的時(shí)候，都是物理機(jī)，為了滿足后面幾年的業(yè)務(wù)需求，大規(guī)模的申請(qǐng)物理機(jī)，但當(dāng)前應(yīng)用的交易量又不是那么大，浪費(fèi)是比較嚴(yán)重的。

這個(gè)時(shí)候我們提升資源的使用成為緊迫的問題。這個(gè)過程中為什么選擇 MySQL 的容器呢？

幾點(diǎn)考量：

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

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

• 行里在 Iaas、Paas 方面建設(shè)好多年了，我們無狀態(tài)的應(yīng)用服務(wù)其實(shí)全部上了 Paas，全部上了容器，在這方面有一些技術(shù)的積累，結(jié)合行內(nèi)對(duì)于云戰(zhàn)略的規(guī)劃，所以我們 MySQL 選擇了上容器。

上容器解決的兩個(gè)技術(shù)要點(diǎn)：

• 容器對(duì)數(shù)據(jù)的持久化支持。

• 對(duì)服務(wù)的暴露。

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

通過上容器，我們提供了一鍵式的環(huán)境供給能力，通過上容器把 Iaas、Paas 全部打通過了，能很快的把基礎(chǔ)環(huán)境，按照行內(nèi)的標(biāo)準(zhǔn)和模式很快的供應(yīng)出來。

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

我們實(shí)施了至少 120 多個(gè)應(yīng)用，2000 多個(gè)服務(wù)器節(jié)點(diǎn)，超過 2500 個(gè) MySQL 節(jié)點(diǎn)。

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

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

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

另外通過良好的架構(gòu)設(shè)計(jì)，我們可以滿足兩地三中心的架構(gòu)要求，做到同城 RPO=0，RTO<60s。

現(xiàn)在很多的“多活”，包括互聯(lián)網(wǎng)公司的架構(gòu)，都是最多能夠做到分片雙活的維度，兩邊同時(shí)提供對(duì)外服務(wù)，但是同時(shí)對(duì)于某一分片數(shù)據(jù)的寫入只能是單活的。

通過架構(gòu)轉(zhuǎn)型，我們?cè)谧灾髂芰Ψ矫?，初步建立了企業(yè)級(jí)的基于 MySQL 的分布式解決的自主能力：

• 首先是分布式框架+MySQL 的應(yīng)用級(jí)分布式解決方案，這個(gè)方案承載了我們很多的從主機(jī)下來的應(yīng)用。

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

在成本方面，我們?cè)谥鳈C(jī)上的成本投入明顯下降。這幾年我們的業(yè)務(wù)交易量每年以 20% 的速度增長，但是主機(jī)并沒有進(jìn)行擴(kuò)容，投入還逐年降低。

商業(yè)產(chǎn)品的數(shù)據(jù)庫的使用不僅實(shí)現(xiàn)零增長，還有所下降。從整個(gè)經(jīng)費(fèi)上來說，應(yīng)該有比較大的降幅。

介紹一下作為我們架構(gòu)設(shè)計(jì)原型的個(gè)人賬戶平臺(tái)，這是從主機(jī)上遷移下來的應(yīng)用。

當(dāng)時(shí)的交易要求高并發(fā)、低延時(shí)，日均交易量 3 億，這個(gè)應(yīng)用的內(nèi)部交易延時(shí)不能超過 100ms，要求 7×24 小時(shí)的聯(lián)機(jī)服務(wù)。

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

同時(shí)結(jié)合 MySQL 的管理平臺(tái)，對(duì)自動(dòng)化的切換能力進(jìn)行了包裝，同城的切換會(huì)面臨著比較大的挑戰(zhàn)：

• 本地的高可用切換是基于 SIP 的，它是對(duì)應(yīng)用透明的。

• 同城切換是對(duì)應(yīng)用不透明的。

于是我們?cè)O(shè)計(jì)了從服務(wù)器到數(shù)據(jù)庫的整體切換流程，數(shù)據(jù)庫要和應(yīng)用服務(wù)器進(jìn)行一些聯(lián)動(dòng)來實(shí)現(xiàn)同城自動(dòng)化切換。

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

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

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

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

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

結(jié)合我們行的 OLTP 的數(shù)據(jù)轉(zhuǎn)型，后續(xù)幾個(gè)方向是我們行要做大量工作的。

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

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

通過我們剛才的一些平臺(tái)也好，一些自主服務(wù)的建設(shè)也好，加強(qiáng)后面云化服務(wù)能力的建設(shè)。

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

那么我們現(xiàn)在除了這樣的一個(gè)業(yè)務(wù)級(jí)的，我們還需要一個(gè)系統(tǒng)級(jí)的來實(shí)現(xiàn)不同數(shù)據(jù)庫和數(shù)據(jù)庫系統(tǒng)級(jí)的準(zhǔn)實(shí)時(shí)的數(shù)據(jù)的交換和復(fù)制。

只有把數(shù)據(jù)流轉(zhuǎn)，把它活動(dòng)起來了，那么數(shù)據(jù)才能更好的發(fā)揮它的業(yè)務(wù)價(jià)值，我們行目前也在建設(shè)這一塊的數(shù)據(jù)復(fù)制平臺(tái)。

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

比如說如何用相對(duì)可以接受，相對(duì)較低的代價(jià)進(jìn)行 Oracle 的轉(zhuǎn)型，因?yàn)檎麄€(gè)數(shù)據(jù)庫、整個(gè)應(yīng)用重構(gòu)開發(fā)的代價(jià)還是非常非常大的，這個(gè)也是我們的后面需要探索和思考的事情。

對(duì)分布式數(shù)據(jù)庫來說，我們從 2015 年以來，就一直跟蹤著業(yè)界很多的分布式數(shù)據(jù)庫的產(chǎn)品。

我們應(yīng)用級(jí)的分布式解決方案也好，包括我們的分布式訪問層的解決方案也好，可能有些場景還真的是無法應(yīng)對(duì)的。

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