今天分享的主題是工行“去 O”數(shù)據(jù)庫選型與分布式架構(gòu)設(shè)計(jì)。

[[330692]]

圖片來自 Pexels

本次分享分為三個(gè)章節(jié)：

• 金融行業(yè)的需求核心與策略
• 工行數(shù)據(jù)庫選型的發(fā)展歷程，即方案選型歷程
• 轉(zhuǎn)型中遇到的各種心酸坑

金融行業(yè)的核心需求與策略

傳統(tǒng) IT 架構(gòu)挑戰(zhàn)

大家可能都知道，工行最早是基于 IBM 大型主機(jī)搭建的核心系統(tǒng)，以及基于 Oracle 和 IBM WAS 搭建的 OLTP 系統(tǒng)，在分布式體系大熱之前處于同業(yè)領(lǐng)先地位。

當(dāng)然現(xiàn)在也是處于同業(yè)領(lǐng)先的，但是科技成本也相對較高，所謂的一份價(jià)錢一分貨就是這個(gè)道理。

 

但是隨著分布式技術(shù)的成熟，傳統(tǒng)的 IT 架構(gòu)面臨著四大挑戰(zhàn)：

①從處理能力層面來看，傳統(tǒng)應(yīng)用(也叫巨石型應(yīng)用)系統(tǒng)規(guī)模龐大，采用集中式架構(gòu)設(shè)計(jì)，使用單一系統(tǒng)垂直擴(kuò)展模式，擴(kuò)展能力相對來說是有限的。

另一方面，大數(shù)據(jù)時(shí)代引發(fā)海量數(shù)據(jù)分析處理和存儲(chǔ)處理的問題，對擴(kuò)展性、可靠性和吞吐量提出了較高要求。

②從運(yùn)行風(fēng)險(xiǎn)層面來看，客戶對金融行業(yè)的系統(tǒng)有著更高的業(yè)務(wù)連續(xù)性保障要求，對不可用問題實(shí)際上是零容忍的，比如要求 7*24 小時(shí)業(yè)務(wù)不能中斷。

③從快速交付層面來看，傳統(tǒng)巨石型應(yīng)用實(shí)際上與快速交付是相悖的，應(yīng)用內(nèi)部模塊、應(yīng)用與應(yīng)用之間耦合度高，使得軟件開發(fā)和產(chǎn)品服務(wù)交付周期長，無法滿足業(yè)務(wù)快速上線的需求，從而逐漸泯然眾人矣，淹沒在茫茫的金融行業(yè)洪流中。

大家可以看到不論是金融科技還是科技金融，一大堆的金融公司已經(jīng)淹沒在前浪里。

④從成本控制來看，大型主機(jī)運(yùn)營費(fèi)用昂貴，商業(yè)產(chǎn)品 License 費(fèi)用高，買個(gè)機(jī)器和服務(wù)隨隨便便就幾千萬上億的支出，真的是太貴了，所以隨著業(yè)務(wù)系統(tǒng)做大做強(qiáng)，產(chǎn)品成本可能會(huì)成為壓死駱駝的最后一根稻草。

為此，我們可以首先得出三點(diǎn)需求：

• 應(yīng)該優(yōu)化應(yīng)用架構(gòu)、數(shù)據(jù)架構(gòu)和技術(shù)架構(gòu)。
• 應(yīng)該建設(shè)靈活開放、高效協(xié)同、安全穩(wěn)定的 IT 架構(gòu)體系。
• 能夠強(qiáng)化對業(yè)務(wù)快速創(chuàng)新發(fā)展的科技支撐。

雙十一壓力

說到這里，就不得不吐槽阿里的“雙十一”，將購買壓縮到一天，對顧客和金融系統(tǒng)來說造成雙重壓力，相較而言，京東的 618 就比較人性化，每天都可以剁手。

我們可以看下雙十一的峰值變化情況，從 2009 年開始，峰值只有 400 筆/秒，相較主機(jī)而言，有很大的差距，當(dāng)然這也與他們當(dāng)時(shí)的名氣小有關(guān)。

 

但是 2015 年開始，借著云化和分布式的大旗，以及當(dāng)時(shí) BAT 的領(lǐng)頭羊地位，僅 4 年時(shí)間，就從 2015 年的 14 萬筆/秒迅速攀升至 2019 年的 54 萬 4 千筆/秒。

這就給金融行業(yè)的系統(tǒng)建設(shè)帶來了四個(gè)問題：

①高并發(fā)問題，我們可以看到，阿里為了提升峰值，做了大量的緩存，鼓勵(lì)使用花唄，降低與外系統(tǒng)的交互，但是依然對金融行業(yè)產(chǎn)生額外的壓力。

②高可靠性要求，確保系統(tǒng)穩(wěn)定可靠，客戶可以穩(wěn)定支付成功，避免因不佳的客戶體現(xiàn)導(dǎo)致用戶流失。

③高成本壓力，大幅擴(kuò)容的設(shè)備，以及隨之產(chǎn)生的運(yùn)維成本，以及昂貴的商業(yè) liscence，給金融行業(yè)帶來一定的成本負(fù)擔(dān)。

④同業(yè)競爭要求，大家都在做競品分析，和同行進(jìn)行比較，所以別人 ok，你掛了，你面子上還掛的住么，所以各機(jī)構(gòu)在雙十一前進(jìn)行大量的模擬測試，類似于高考前的黑暗日子。

金融行業(yè)分布式的核心訴求及策略

為此，金融行業(yè)分布式的核心訴求及策略可以總結(jié)為以下五點(diǎn)：

 

①應(yīng)該具備企業(yè)級的業(yè)務(wù)支撐能力，支持高并發(fā)、可擴(kuò)展和海量數(shù)據(jù)庫存儲(chǔ)及訪問;原則上應(yīng)支持同城雙活，實(shí)現(xiàn)集中式向分布式的轉(zhuǎn)型。工行的兩地三中心容災(zāi)體系在國有大型銀行中屬于第一梯隊(duì)。

②應(yīng)能大幅降低使用成本，可以基于通用的廉價(jià)的 X86 硬件基礎(chǔ)設(shè)施;降低商業(yè)產(chǎn)品依賴，擁抱開源產(chǎn)品，互聯(lián)網(wǎng)企業(yè)已經(jīng)給我們做了一個(gè)很好的參考。

③應(yīng)該提升數(shù)據(jù)庫的運(yùn)維自動(dòng)化和智能化能力，支持與自身系統(tǒng)進(jìn)行適配性定制，工行即實(shí)現(xiàn)了行內(nèi)系統(tǒng)適配定制。

④金融行業(yè)還應(yīng)考慮到社會(huì)聲譽(yù)性要求，客戶對金融行業(yè)的期望很高，特別是對銀行等金融組織，所以要求也更加嚴(yán)格，原則上應(yīng)該是 7*24 小時(shí)的不間斷服務(wù)。

像當(dāng)年支付寶在 2015 年的支付癱瘓事件僅僅上了下熱搜，但是 2013 年工行因?yàn)?IBM 主機(jī) Bug 的問題卻上了新聞聯(lián)播，這就是所謂的愛之深責(zé)之切吧。

⑤要考慮到政治因素風(fēng)險(xiǎn)，雖然全球化要求技術(shù)無國界，但是從去年開始的貿(mào)易戰(zhàn)，以及美國的實(shí)體管制清單，我們可以看到技術(shù)是有國界的。

近期 HashiCorp 發(fā)布公告，其企業(yè)版產(chǎn)品禁止中國使用已經(jīng)引發(fā)了一種擔(dān)憂。說起 HashCorp ，大家可能不一定熟悉，但是其旗下有大名鼎鼎的產(chǎn)品 Consul，可以簡化分布式環(huán)境中的服務(wù)注冊與發(fā)現(xiàn)流程，大家一定耳熟能詳。

最后中國人民銀行在 2019 年 8 月 23 日發(fā)布了《金融科技(FinTech)發(fā)展規(guī)劃(2019-2021)》中提到“做好分布式數(shù)據(jù)庫金融應(yīng)用的長期規(guī)劃，加大研發(fā)與應(yīng)用投入力度，妥善解決分布式數(shù)據(jù)庫產(chǎn)品在數(shù)據(jù)一致性、實(shí)際場景驗(yàn)證、遷移保障規(guī)范、新型運(yùn)維體系等方面的問題，這也給金融行業(yè)指明了方向。

選型的發(fā)展歷程(方案選型歷程)

接下來，給大家介紹下如何選型以及工行的選型歷程。

工行分布式轉(zhuǎn)型發(fā)展歷程

大家可以看下工行分布式的發(fā)展歷程：

 

其大致可分為 2 個(gè)關(guān)鍵階段，2016 年初-2017 年末為基礎(chǔ)研究及試點(diǎn)階段，之后為轉(zhuǎn)型實(shí)施及推廣階段。

大致有如下五個(gè)關(guān)鍵時(shí)點(diǎn)：

• 2016 年初工行進(jìn)行分布式體系研究，建立了基于 Dubbo 框架的分布式生態(tài)服務(wù)。
• 2016 年底借著人民銀行對于個(gè)人賬戶的管理要求，實(shí)行三類賬戶的場景，開始了基于分布式的 OLTP 數(shù)據(jù)庫研究，并確定了基于開源 MySQL 的 OLTP 數(shù)據(jù)庫解決方案，因?yàn)?MySQL 8.0 的不成熟，所以我們采用了 MySQL 5.7。
• 2017 年末，我們完成開源 MySQL 初步能力體系的建設(shè)，涵蓋了基礎(chǔ)研究、配套方法論、應(yīng)用試點(diǎn)等等。
• 2018 年開始大規(guī)模的實(shí)施和推廣，我們逐步建立企業(yè)級的數(shù)據(jù)庫服務(wù)能力，包括引入了分布式的中間件，在高可用、運(yùn)維能力的提升，資源使用率的提升，MySQL 上云及自主服務(wù)的建設(shè)等等，同時(shí)開啟了對 OLTP 的分布式數(shù)據(jù)庫進(jìn)行了研究。
• 2019 年 11 月我們實(shí)現(xiàn)了國產(chǎn)分布式數(shù)據(jù)庫產(chǎn)品 GaussDB 試點(diǎn)上線。

方案選型調(diào)研

大家可以看下工行的選型過程，希望可以給大家?guī)硪欢ǖ膮⒖迹?/p>

 

工行的技術(shù)規(guī)劃是相當(dāng)嚴(yán)謹(jǐn)?shù)?，所以?dāng)時(shí)我們從五個(gè)層次進(jìn)行了考量：OLTP 分布式數(shù)據(jù)庫、NewSQL 數(shù)據(jù)庫、支持分布式架構(gòu)、自主可控、開源抑或商業(yè)。

當(dāng)時(shí)我們的第一個(gè)疑問是，到底是選 NoSQL、NewSQL 還是關(guān)系型數(shù)據(jù)庫。

當(dāng)時(shí) MongoDB、Redis、Cassandra、HBASE 等 NoSQL 數(shù)據(jù)庫開始在某些場景下大熱，但是可用場景不滿足我們的 OLTP 業(yè)務(wù)場景需求。

NewSQL 隨著 Google 的 Spanner 和 F1 開始進(jìn)入大家的視野，但是國內(nèi)可以考據(jù)的只有相關(guān)的 paper;國產(chǎn)的 TiDB 也是小荷初露尖尖角，但是畢竟還是幼兒期。

而 DB-Egines 發(fā)布的《2016 年全球數(shù)據(jù)庫大盤點(diǎn)》，Oracle、MySQL 和 SQL Server 三大數(shù)據(jù)庫產(chǎn)品遙遙領(lǐng)先。

MySQL 當(dāng)時(shí)在互聯(lián)網(wǎng)公司的名氣是越來越響，谷歌、淘寶、百度、騰訊、豆瓣、網(wǎng)易、臉書等都使用了 MySQL。

一方面 MySQL 提供了免費(fèi)版，另一方面 Oracle 收購 Sun 后，可以很明顯的看到 MySQL 越來越規(guī)范，5.5、5.6、5.7 均可以看到很明顯的提升，5.7 號稱性能是 5.6 的 3 倍，5.6 號稱是 5.5 的 2 倍。

為此，我們經(jīng)過謹(jǐn)慎的驗(yàn)證，選取了 MySQL 作為分布式數(shù)據(jù)庫的第一選型，畢竟業(yè)界有很多豐富的案例。

而且在互聯(lián)網(wǎng)企業(yè)里面得到了很好的實(shí)踐，在業(yè)界資源案例和周邊產(chǎn)品都很豐富，能應(yīng)對我行的高并發(fā)、彈性擴(kuò)展需求。

同時(shí)其具有如下特點(diǎn)：

• 開源，基于 GPL(GNU 通用許可證)可以免費(fèi)使用修改，當(dāng)時(shí)很多公司都基于 MySQL 進(jìn)行了深入定制，但是在與他們的交流過程中，發(fā)現(xiàn)版本歸并真的是一種夢魘。
• 高可用，具有優(yōu)秀的架構(gòu)設(shè)計(jì)及相當(dāng)豐富的周邊產(chǎn)品，實(shí)現(xiàn)了企業(yè)級的高可用性和高擴(kuò)展性。
• 免費(fèi)，有效降低企業(yè)運(yùn)行成本。
• 趨勢，產(chǎn)品成熟度、排名一直遙遙領(lǐng)先，占行業(yè)應(yīng)用的比重增大，產(chǎn)業(yè)鏈豐富，從業(yè)人員有規(guī)模效應(yīng)。

然后我們選擇了 MySQL 5.7，其相較之前的版本有六個(gè)優(yōu)點(diǎn)：

• InnoDB 增強(qiáng)，在線修改 ibp，快速擴(kuò)展 VARCHAR，UNDO 可回收，可關(guān)閉死鎖檢測。
• 復(fù)制增強(qiáng)，多源復(fù)制，基于 WRITESET 的并行復(fù)制，增強(qiáng)半同步，在線設(shè)置 repl filter。
• 優(yōu)化器增強(qiáng)，幾乎重構(gòu)優(yōu)化器，EXPLAIN 增強(qiáng)，引入 Optimizer Hints。
• 安全性增強(qiáng)，新增密碼過期機(jī)制，支持賬號鎖定等。
• 功能增強(qiáng)，默認(rèn)開啟 PFS，新增 sys schema 等。
• 其他增強(qiáng)，支持多個(gè)觸發(fā)器，新增 Query Rewrite，支持設(shè)置 SQL 執(zhí)行最長時(shí)間。

方案技術(shù)棧

 

基于 MySQL 選型，還應(yīng)考慮一系列的分布式架構(gòu)技術(shù)棧，包括分布式服務(wù)、分布式事務(wù)框架、分布式批量框架、分布式緩存、交易數(shù)據(jù)核對及補(bǔ)償、分布式消息、配置中心、開發(fā)及運(yùn)維管理。

這里提醒下大家，在選型上沒有最好的產(chǎn)品，只有最適合自己的產(chǎn)品：

①分布式事務(wù)，業(yè)界實(shí)際上有多種解決方案，2PC(2 階段式事務(wù)提交)、3PC、TCC 和 SAGA 模型等等，我們這 4 種方案我行都有應(yīng)用在使用，互為補(bǔ)充，滿足不同業(yè)務(wù)場景對事務(wù)強(qiáng)一致性或最終一致性的要求。

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

③分布式消息，我們選取了 Kafka 作為分布式消息中間件。

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

⑤運(yùn)維層面，我行建立了統(tǒng)一的運(yùn)維管理平臺(tái)，納入所有數(shù)據(jù)庫節(jié)點(diǎn)，實(shí)現(xiàn)一鍵式的數(shù)據(jù)庫安裝、版本升級、基線參數(shù)配置等等。并且實(shí)現(xiàn)了多種高可用策略配置，包括自動(dòng)、人工一鍵式切換。

為什么要有自動(dòng)化和人工的兩種切換方式?這里我要解釋下，一種新的事務(wù)上線之前，都會(huì)面臨一些挑戰(zhàn)和懷疑的，都是一個(gè)循序漸進(jìn)的過程，特別是是在金融行業(yè)，自動(dòng)真的好么?萬一搞錯(cuò)了怎么辦?決策因素和模型是否設(shè)計(jì)正確?設(shè)計(jì)正確了是否編碼正確?

最難的是還要應(yīng)對不同應(yīng)用場景的需求，有的應(yīng)用要求 RPO 優(yōu)先，有的應(yīng)用又要求 RTO 優(yōu)先。

我們之前經(jīng)過充分調(diào)研，預(yù)見到該種情況，所以我們提供了多種高可用策略的靈活配置，以便滿足不同應(yīng)用的個(gè)性化要求。

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

其他考量

除此以外，數(shù)據(jù)庫選型后，還應(yīng)完善相關(guān)體系，規(guī)范設(shè)計(jì)、開發(fā)、測試和運(yùn)維，實(shí)現(xiàn)管控的體系化和自動(dòng)化，才能避免眼高手低，減少生產(chǎn)安全風(fēng)險(xiǎn)。

 

①在設(shè)計(jì)層面，在驗(yàn)證功能、新特性和配置基線，數(shù)據(jù)備份恢復(fù)的基礎(chǔ)上，我們參考了愛可生、阿里等公司的規(guī)約，建立了 MySQL 設(shè)計(jì)指引，可以說，我們是站在巨人的肩膀上成長的。

加強(qiáng)元數(shù)據(jù)管理，提出元數(shù)據(jù)完備性、明確性、具象性和前瞻性的要求，建立應(yīng)用的元數(shù)據(jù)標(biāo)準(zhǔn)，統(tǒng)一數(shù)據(jù)架構(gòu)設(shè)計(jì)，架構(gòu)師設(shè)計(jì)表結(jié)構(gòu)時(shí)均基于元數(shù)據(jù)進(jìn)行設(shè)計(jì)，提升數(shù)據(jù)架構(gòu)質(zhì)量。

此外，我們還開發(fā)了表結(jié)構(gòu)設(shè)計(jì)工具，將其融合在 Excel 中，實(shí)現(xiàn)對元數(shù)據(jù)的自動(dòng)應(yīng)用，支持自動(dòng)生成腳本，簡化架構(gòu)師的貫標(biāo)操作，將人員成熟度的要求降至最低，提升設(shè)計(jì)效能和質(zhì)量。

②在開發(fā)層面，我們制訂了開發(fā)規(guī)范和 SQL 調(diào)優(yōu)指引，同時(shí)基于 sonar 開發(fā)了 MySQL 檢查工具，支持對基于 myBatis 的 mapper 文件進(jìn)行解析，提前發(fā)現(xiàn) SQL 不規(guī)范的寫法。

同時(shí)將 sonarlint 插件納入開發(fā)人員必備插件，實(shí)現(xiàn)規(guī)則的云化部署和本地聯(lián)動(dòng)掃描分析，將規(guī)范融入開發(fā)過程中，提升開發(fā)人員的 SQL 編寫能力。

③在測試層面，我們自研壓力測試服務(wù)平臺(tái)，盡量減少性能瓶頸，提前發(fā)現(xiàn) SQL 性能問題。

④在運(yùn)維層面，感覺應(yīng)該是最重要的一個(gè)層面，我們需要考慮自動(dòng)化部署、監(jiān)控告警、故障分析、自動(dòng)巡檢以及 SRE 平臺(tái)，還有數(shù)據(jù)遷移、備份恢復(fù)、配置管理、版本升級、多租戶等等。

隨著節(jié)點(diǎn)的增加，運(yùn)維實(shí)際上是一個(gè)很大的挑戰(zhàn)，幾千幾萬個(gè)節(jié)點(diǎn)，安裝、監(jiān)控、報(bào)警、故障、人工處理等非常麻煩。

必須要實(shí)現(xiàn)自動(dòng)化的安裝部署，進(jìn)行批量安裝部署，同時(shí)批量串行還不行，時(shí)間太長了，要并行，并行太高了，網(wǎng)絡(luò)的流量又會(huì)受到很大的影響，所以很多場景都需要細(xì)細(xì)打磨，還要按照博弈論的思路建立納什均衡。

監(jiān)控告警里有事件等級，如何劃分各種等級，都需要靈活定制支持，建立基線告警，建立應(yīng)急流程。

像華為等公司都有基于設(shè)備的網(wǎng)絡(luò)拓?fù)鋱D，問題在哪個(gè)節(jié)點(diǎn)，可以快速分析和定位，所以說運(yùn)維是一個(gè)很麻煩的事情，像故障分析，完善日志記錄、采集和分析，建立故障分析規(guī)范。

自動(dòng)巡檢，自動(dòng)化的巡檢和評分報(bào)告，對實(shí)例狀態(tài)進(jìn)行健康評分。在這個(gè)階段我們實(shí)現(xiàn)了同城 RPO=0，RTO=分鐘級目標(biāo)，RPO 為 0 的切換，問題可監(jiān)控，實(shí)現(xiàn)了人工或自動(dòng)的一鍵式切換。

最后我們不得不提到 SRE，很多人會(huì)聯(lián)想到運(yùn)維工程師、系統(tǒng)工程師，其實(shí)不然，SRE 本質(zhì)上仍然是軟件工程師。

SRE 最早在十多年前 Google 提出并應(yīng)用，近幾年逐步在國內(nèi)外 TOP 互聯(lián)網(wǎng)公司都開始廣泛應(yīng)用。

其中 Google 締造了 SRE，并奠定了其權(quán)威的地位，而 Netflix 將 SRE 的實(shí)踐做到了極致，Netflix 僅有的個(gè)位數(shù)的 Core SRE 支持了 190 個(gè)國家、數(shù)億用戶、數(shù)萬微服務(wù)實(shí)例業(yè)務(wù)規(guī)模的運(yùn)維。

像數(shù)據(jù)庫瓶頸，頂配數(shù)據(jù)庫空間仍然無法支撐業(yè)務(wù)半年發(fā)展;慢 SQL 數(shù)量爆發(fā)式增長，應(yīng)用穩(wěn)定性岌岌可危;人工運(yùn)維風(fēng)險(xiǎn)極高;人工運(yùn)維頻率高，研發(fā)幸福感下降這些大家都會(huì)遇到的問題也會(huì)逐漸地遇到。

他山之石，可以攻玉，我們完全可以把別人的挫折拿過來，避免自己走彎路。

MySQL 上云

在逐步推進(jìn)的過程中，完善選型體系建設(shè)后，為了確保資源的有效利用，上云實(shí)際上是一種必然的選擇。

從工行來看，經(jīng)歷 1-2 年的發(fā)展，MySQL 數(shù)據(jù)庫節(jié)點(diǎn)就已經(jīng)增至幾千套，機(jī)房和設(shè)備實(shí)際上已成為一個(gè)瓶頸，再這么玩兒下去機(jī)房容量不足了，所以必須提升資源的使用效率。

 

我行新建應(yīng)用時(shí)，一般都會(huì)進(jìn)行 1-3 年的一個(gè)超前規(guī)劃，業(yè)界也是同樣的做法，為了穩(wěn)定運(yùn)行，避免出現(xiàn)資源瓶頸，基本上提交資源申請時(shí)，都選擇物理機(jī)。

但是大規(guī)模的申請物理機(jī)，而當(dāng)前應(yīng)用的交易量又無法達(dá)標(biāo)，所以資源浪費(fèi)非常嚴(yán)重。

根據(jù)評測，相較 Oracle，MySQL 數(shù)據(jù)庫實(shí)例單體性能容量較小，數(shù)據(jù)容量普遍小于 500G，同時(shí)超過一定容量的就要進(jìn)行分庫，但是一臺(tái)物理機(jī)部署 1 個(gè)數(shù)據(jù)庫的方式并未發(fā)生變化，MySQL 的服務(wù)器資源密度較低。

同時(shí)運(yùn)維效率低，在服務(wù)器、存儲(chǔ)、網(wǎng)絡(luò)等基礎(chǔ)設(shè)施環(huán)節(jié)的運(yùn)維和交付仍然需要大量手工操作。

業(yè)界普遍的做法就是將 MySQL 上云，實(shí)現(xiàn)云化部署，借助成熟的云體系實(shí)現(xiàn)彈性伸縮和動(dòng)態(tài)擴(kuò)容。

工行有個(gè)優(yōu)勢，IAAS 和 PAAS 云處于同業(yè)領(lǐng)先地位，有著豐富的經(jīng)驗(yàn)積累，為此結(jié)合行內(nèi)對于云戰(zhàn)略的規(guī)劃，MySQL 上云是一種必然趨勢。

我們提供了 MySQL 的容器鏡像，提供了一鍵式的環(huán)境供給能力，通過上容器把 IAAS、PAAS 全部打通，支持快速搭建符合行內(nèi)標(biāo)準(zhǔn)的基礎(chǔ)環(huán)境，提升環(huán)境支持能力。

工行基于 K8S、SDN、IAAS 建設(shè)持久性的狀態(tài)容器運(yùn)行集群，通過 SDN 實(shí)現(xiàn)容器網(wǎng)絡(luò)資源的自動(dòng)化申請，通過底層擴(kuò)展 K8S 實(shí)現(xiàn)容器的固定 IP，業(yè)界一般會(huì)采用 K8S Operator 實(shí)現(xiàn)容器的有狀態(tài)資源綁定，也包含了固定 IP 綁定。

保守估計(jì)，資源的使用效率至少提升了 4 到 5 倍。而且，我們的工作成果也相當(dāng)喜人，截止當(dāng)前工行的 MySQL 云化部署節(jié)點(diǎn)已達(dá) 4300 多個(gè)。

工行實(shí)施效果

我們可以看下工行的轉(zhuǎn)型成效，首先看下數(shù)據(jù)：

 

①我們已實(shí)施 200 多個(gè)應(yīng)用，高災(zāi)備等級應(yīng)用占比高達(dá) 53%。

②6000 多個(gè) MySQL 節(jié)點(diǎn)，高災(zāi)備等級應(yīng)用占比高達(dá) 87.31%。

③實(shí)施的應(yīng)用涉及很多核心業(yè)務(wù)，包括個(gè)人、對公、基金以及很多高災(zāi)備等級應(yīng)用，大多數(shù)為主機(jī)下平臺(tái)遷移應(yīng)用，少量應(yīng)用是從 Oracle 遷移過來的，因?yàn)楣ば袑? PLSQL 存儲(chǔ)過程用到了極致，所以應(yīng)用層也因此需要重構(gòu)。

④我們通過 MySQL 支持的核心交易可以達(dá)到日均 7 億的交易量，經(jīng)歷過雙十一和春節(jié)的多重考驗(yàn)，峰值 TPS 至少可以達(dá)到 1.5 萬 TPS，同時(shí)支持橫向擴(kuò)展，理論上通過擴(kuò)展設(shè)備還可以無限地增加。

而如果通過主機(jī)想達(dá)成這個(gè)目標(biāo)，那么挑戰(zhàn)就會(huì)比較大，這就是建摩天大廈和建排屋的區(qū)別。

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

⑥在自主能力方面，初步建立了企業(yè)級的基于 MySQL 的分布式解決的自主能力：首先是分布式框架+MySQL 的應(yīng)用級分布式解決方案，該方案承載了我行很多主機(jī)下平臺(tái)應(yīng)用。

其次是基于分布式中間件 DBLE(原型為 MyCat，后經(jīng)愛可生公司優(yōu)化為 DBLE，同時(shí)我行進(jìn)行了深度優(yōu)化和開發(fā))建立數(shù)據(jù)訪問層，支持應(yīng)對一些不是很復(fù)雜的場景，通過良好設(shè)計(jì)的分庫分表方案即可滿足需求。

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

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

典型實(shí)施案例：信息輔助服務(wù)

介紹一下我行的典型案例：信息輔助系統(tǒng)。

從應(yīng)用場景分析其需求，需要支持高并發(fā)、低延時(shí)，日均交易量為 2 億，交易響應(yīng)延時(shí)要求 10ms 以內(nèi)，業(yè)務(wù)數(shù)據(jù)量大概 20T 左右，要求 7×24 小時(shí)的聯(lián)機(jī)服務(wù)，這就對應(yīng)用的高可用提出了新的要求。

 

為此，通過統(tǒng)一運(yùn)維管理平臺(tái)，吸納所有節(jié)點(diǎn)，實(shí)現(xiàn)一鍵式的安裝、版本的升級、參數(shù)的配置。

①設(shè)計(jì)層面通過分布式數(shù)據(jù)中間件 DBLE，進(jìn)行分庫分表，規(guī)劃了 128個(gè) 分片，并對分片進(jìn)行了合并部署，雖然相較于阿里的 1024 分片來說較少，但是我們使用了一致性 hash 算法，在資源使用上收益很大。

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

③目前我們的高可用架構(gòu)采用一主三從(1 主庫、1 本地半同步庫、2 同城半同步庫)架構(gòu)，基于 MySQL 的半同步復(fù)制，實(shí)現(xiàn)園區(qū)級的 RPO=0。

通過 DBLE 中間件和管理平臺(tái)聯(lián)動(dòng)完成實(shí)現(xiàn)了本地和同城的自動(dòng)化切換，RPO=0，RTO<60S，完全滿足工行的業(yè)務(wù)要求。

最后補(bǔ)充說明下，為了實(shí)現(xiàn)數(shù)據(jù)庫層面的高可用， DBLE 到數(shù)據(jù)庫的訪問同一配置為實(shí) IP。

④這里我補(bǔ)充下我們高可用的發(fā)展史，其實(shí)我們對高可用方案進(jìn)行了持續(xù)的優(yōu)化。

同時(shí)學(xué)習(xí)和借鑒互聯(lián)網(wǎng)包括分布式數(shù)據(jù)庫的一些方案，從 1 主 2 備，本地 1 備和同城 1 備，擴(kuò)展成 1 主 3 備，通過半同步的機(jī)制，做到真正的在系統(tǒng)級去保證 RPO=0。

⑤在異地災(zāi)備方面。最開始采用磁盤復(fù)制實(shí)現(xiàn)災(zāi)備，一方面成本比較高，另一方面是冷備，無法熱切換，RTO 至少半個(gè)小時(shí)以上。所以我們后期用了 MySQL 異步復(fù)制。

在存儲(chǔ)方面采用集中存儲(chǔ)，一套集中存儲(chǔ)上面需要同時(shí)支撐上百個(gè) MySQL 實(shí)例，IO 性能直接成為瓶頸，為了應(yīng)對高并發(fā)場景時(shí)的 IO 瓶頸，我們直接引入 SSD 盤，基本上把 MySQL 的 IO 瓶頸給解決了。

轉(zhuǎn)型中遇到的各種心酸坑

最后我們說下我行轉(zhuǎn)型過程中遇到的心酸坑。

其實(shí)如果使用過 MySQL 5.7 的企業(yè)，肯定都遇到過相似的問題，比如超過 MySQL 的默認(rèn)閑置時(shí)間導(dǎo)致的連接超時(shí)、dependent subquery 導(dǎo)致的語句效率差、字符集亂碼等等。

以及 MySQL 的自身 Bug，比如 Intel PAUSE 指令周期的迭代引發(fā) MySQL 的性能瓶頸。

畢竟免費(fèi)的午餐并不是那么完美，總是會(huì)有或多或少的問題需要規(guī)避。

 

我這里說下讓我痛心疾首的幾個(gè)心酸坑吧：

坑一：慢 SQL 數(shù)量爆發(fā)式增長，應(yīng)用隱患逐步暴露，在阿里等互聯(lián)網(wǎng)公司和我行都是一個(gè)痛點(diǎn)，值得大家警醒和重視。

我行 OLTP 之前為 Oracle 數(shù)據(jù)庫，借助于 Oracle 良好的優(yōu)化器，大家習(xí)慣于 5 張表左右的連接，但是遷移至 MySQL 后，習(xí)慣沒有及時(shí)轉(zhuǎn)換過來，一個(gè)慢 SQL 可能就導(dǎo)致服務(wù)不可用，降低用戶幸福指數(shù)。

為此我們規(guī)劃了三個(gè)方面的改善措施：

①設(shè)計(jì)層面制定了規(guī)范，強(qiáng)調(diào)數(shù)據(jù)設(shè)計(jì)的合理性，組織 DBA 進(jìn)行內(nèi)部復(fù)核，提前規(guī)避設(shè)計(jì)問題，比如 3NF、BCNF 的設(shè)計(jì)遵循、可控性冗余處理(空間換時(shí)間或時(shí)間環(huán)空)等等，通過輔助工具的自動(dòng)化手段，從源頭扼殺風(fēng)險(xiǎn)。

②開發(fā)層面我們基于 Sonar 開發(fā)了自動(dòng)化檢查工具，支持分析 mapper 文件，既然開發(fā)人員沒空看規(guī)范，那我們工具輔助，增加質(zhì)量門禁，強(qiáng)制將規(guī)范融合至開發(fā)過程中，進(jìn)一步降低風(fēng)險(xiǎn)。

但是對新人可能不友好，以前看到一個(gè)新人的朋友圈的哭訴，被質(zhì)量門禁卡的無法提交代碼，一直苦逼的加班整改。

③運(yùn)維層面我們建立了 SRE 平臺(tái)，監(jiān)測慢 SQL 語句，并分批次要求整改，將結(jié)果都擺在臺(tái)面上，真的不是我們不給力，而是應(yīng)用開發(fā)不給力啊。

坑二：在 MySQL 5.7 中，表的 TRUNCATE 操作存在 Bug，對應(yīng)編號 68184，會(huì)阻塞整個(gè)數(shù)據(jù)庫實(shí)例上的所有其他交易。

所以對大表進(jìn)行 TRUNCATE 操作會(huì)影響整個(gè) MySQL 數(shù)據(jù)庫的處理性能，即使是訪問不想關(guān)的表也會(huì)收到影響。

此時(shí)你就會(huì)收到一群開發(fā)人員的請求，哎呀，數(shù)據(jù)庫夯住了，求救啊，實(shí)際上解決方案也很簡單，因?yàn)?Drop 語句不受影響，所以映射為 DROP+CREATE 的操作即可規(guī)避該 Bug，而 MySQL 8.0 也將其進(jìn)行了同樣的映射。

所以我們將其固化到設(shè)計(jì)開發(fā)規(guī)范中，提醒相關(guān)人員進(jìn)行注意，同時(shí)在工具中增加 TRUNCATE 關(guān)鍵字識別檢查，做到提前預(yù)防。

坑三：MySQL 的超時(shí)中斷，wait_timeout 參數(shù)，即 MySQL 客戶端的數(shù)據(jù)庫連接閑置最大時(shí)間值(秒)，我行設(shè)置為 1 小時(shí)。

如果長連接的空閑時(shí)間超過該參數(shù)設(shè)置時(shí)間，數(shù)據(jù)庫連接就會(huì)被 MySQL 主動(dòng)斷開，而中間件的連接池的連接就處于“假活“狀態(tài)。

一般的建議方法就是增加心跳監(jiān)測，使用 dbcp 設(shè)置 testWhileIdle、validationQuery 等參數(shù)，如果跟我行一樣使用 WAS 的，在 WAS 控制臺(tái)上設(shè)置時(shí)效超時(shí)的參數(shù)即可。

坑四：Replce Into 引發(fā)的自增列主鍵沖突 Bug，對應(yīng)編號 73563，主庫在執(zhí)行 replace 操作時(shí)，如果有數(shù)據(jù)沖突，會(huì)轉(zhuǎn)換為一筆 delete+一筆 insert。

所以主庫無問題，但是 binglog 記錄的為 update 操作，備庫重做 update 動(dòng)作，更新主鍵，但由于 update 動(dòng)作不會(huì)更新自增列值，導(dǎo)致更新后記錄值大于自增列值。

當(dāng)此時(shí)發(fā)生主備切換時(shí)，備庫提升為主庫，插入的自增列主鍵會(huì)取自增列的值，從而引發(fā)主鍵沖突。

解決方案也屬于應(yīng)急方案，可以在發(fā)生問題時(shí)，通過 ALTER 語句將自增列增加。

另一種解決方案，可以在 replace into 之后開啟一個(gè)新的事務(wù)，插入一條無意義的記錄然后刪除掉，可以保證主備一致。

最后一種解決方案，是直接用雪花算法計(jì)算遞增序列號。

作者：魏亞東

簡介：中國工商銀行軟件開發(fā)中心三級經(jīng)理，資深架構(gòu)師。杭州研發(fā)部數(shù)據(jù)庫專家牽頭人和開發(fā)中心安全團(tuán)隊(duì)成員，負(fù)責(zé)技術(shù)管理、數(shù)據(jù)庫和安全相關(guān)工作。2009 年加入中國工商銀行軟件開發(fā)中心，致力于推動(dòng)管理創(chuàng)新、效能提升，提供全面技術(shù)管控，推動(dòng)自動(dòng)化實(shí)施，實(shí)現(xiàn)業(yè)務(wù)價(jià)值的高質(zhì)量快速交付;同時(shí)作為技術(shù)專家，為生產(chǎn)安全提供技術(shù)支持。

編輯：陶家龍

出處：轉(zhuǎn)載自微信公眾號 DBAplus 社群(ID：dbaplus)，本文根據(jù)魏亞東老師在〖deeplus 直播第 225 期〗線上分享演講內(nèi)容整理而成。