誰說數據庫不適合Docker？解讀 MySQL DB Mesh的創造性實踐

　　作者 | 關賀宇

　　編輯 | Yonie

　　以 Docker 為代表的容器技術正在以一種不可阻擋的趨勢席卷全球，但真正的落地過程依然十分坎坷。6 月 20 日北京，在 2019 企業容器創新大會上，業內首家覆蓋業務全流程、運營全體系的移動信貸整體技術服務商飛貸金融科技的副總裁陳定瑋分享了飛貸的數據庫生產容器化及 Istio 應用的經驗。基于飛貸金融科技容器化道路的實踐與經驗，InfoQ 記者也專訪了陳定瑋，并將其分享和思考整理如下。

　　傳統的 IT 流程、基礎架構和運維模式已經無法滿足金融行業的業務發展需求，傳統銀行早已意識到轉型的迫切性，但如何落地，其實對銀行的智慧挑戰很大。同時，客戶對于金融服務的期望和要求日益增加，對于銀行在全渠道體驗、定制化內容、智能數據、實時、便捷及移動等方面的服務，不斷提出更高要求。

　　傳統金融行業的痛點

　　如何快速響應用戶需求

　　金融行業信息化建設的關鍵是及時響應業務需求，適應不同商業環境的 IT 架構，滿足不同部門、客戶和合作伙伴的各種需求。然而，傳統的研發模型已經成為應用交付和迭代速度的瓶頸。

　　煙囪式架構如何向分布式架構無痛轉型

　　在 IT 基礎架構層面，很多金融企業都是「煙囪式」架構，「煙囪式」架構帶來的最大問題是數據孤島， 不同的應用系統之間的數據無法實現共享。并且，在金融走向普惠、擁抱長尾市場的過程中，傳統金融 IT 架構無法支撐巨量涌入的長尾客戶。

　　高復雜環境下如何確保系統的高可用性

　　金融 IT 運維人員的壓力之大眾所周知，這源于金融行業對業務連續性和可用性的嚴苛要求。隨著金融信息化的不斷發展，金融 IT 環境正在變得越來越復雜：應用紛繁復雜、IT 架構異構、系統規模日益增大……這些都導致運維的難度越來越大，運維部門需要全新的思路來應對復雜環境下 IT 系統運維的壓力。

　　以 Docker 為代表的容器技術正在以一種不可阻擋的趨勢席卷全球，其最大的過人之處在于它統一了云的交付件，從而給企業 IT 轉型帶來變革性的思路，賦予企業 IT 快速響應和持續創新的能力。

　　容器技術的不斷發展和成熟為傳統金融企業的容器化建設提供了新思路，但真正的落地過程依然十分坎坷。正如飛貸金融科技副總裁陳定瑋在接受 InfoQ 記者采訪時提到的，“其實，現在任何行業對容器的看法基本一致，都是非常認可的。從金融行業的角度，認可歸認可，但大部分的實踐還是基于邊緣系統，而真正的核心系統想要落實容器化建設，中間要經歷一段時間的陣痛。這就導致雖然大家都看好容器的發展趨勢，但由于金融行業本身的特殊性，還是有很多企業不敢貿然行動。”

　　不敢貿然進行容器化建設的原因有幾點：

　　一是人的因素。銀行的科技人員是否足夠了解并掌握容器技術，如果運維人員不具備這樣的技術能力，是沒辦法在進行容器化建設的。

　　二是金融行業的特殊性。銀行對于新技術的引入非常審慎，由于追求安全第一的行業特殊性，金融行業與互聯網行業相比，即使對新技術的“熱情”很高漲也無法很快推行到核心系統。現在一些比較大的銀行，渴望嘗試新的技術和應用，但目前仍處在經驗積累階段，還是只能在邊緣系統嘗試。只有當容器及相關技術在邊緣系統運用得非常成熟和完善以后，才有可能慢慢地去取代核心系統，進而將新技術推廣到核心部分。而且由于傳統銀行系統體量大，復雜度高，“包袱”重，探索出真正適合金融行業的技術方案和路線，需要經過一個很長的時間技術迭代。

　　陳定瑋提到，“金融企業做容器化建設是一種必然趨勢，但是整個進程的速度關鍵在于技術決策者，也就是 CTO 或者科技主管。他們對于新技術的運用以及怎么運用這件事情如果想得比較清楚，那么新技術的推動速度就會大大加快。”

　　飛貸的容器化之路

　　飛貸的容器化建設，起點很特別——公司內部所有的系統都是自研開發。容器化建設其實是對基礎架構層的重新打造，自研系統的優勢就在于對原系統和架構的改動不用經過第三方。陳定瑋提到，“如果飛貸是采用第三方系統，那么每次新技術引進都需要跟合作方去談，但問題是傳統的軟件系統對于基礎架構這一層的事情并不太關注，這會在一定程度上阻礙基礎架構層的技術改進。另外，飛貸的技術基因與其他公司有些不同，我們非常看重基礎架構層的建設，因為這是整個飛貸金融科技賴以生存的一部分。從業務層面來看，飛貸本身有 C 端業務，并且是在解決 C 端用戶遇到的問題和痛點的過程中，形成了最佳的解決方案，然后賦能給金融客戶，這是飛貸與其他軟件企業的不同，我們的商業模式里是有實體運作的經驗，經過了生產歷練且成效不錯。”

　　容器化建設有兩點顯著的好處：一是彈性伸縮，二是容器化建設后，架構變小，這樣系統恢復部署 / 運維速度會加快。

　　飛貸對于整個容器技術的理解和做法是：通過容器化去改變 RD 整個開發模式。 有些企業在做容器化時，往往只是把虛擬化的技術替換成容器而已，但是實質上里面的東西沒有變，這樣容器技術根本起不到效用。比如，如果僅僅是將虛擬機換為容器，雖然系統容器啟動時間會大幅縮短，由幾分鐘變為幾十秒，但是系統的容器化構建編排需要幾個小時，這樣整個系統的交付體系效率并沒有提升，甚至是變得更慢。 整體效率考量才是企業做容器化想要達成的目的和結果。

　　飛貸的容器化建設不只是把 CloudStack 換成容器，而是把整個應用程序及研發流程，根據容器的規范和要求也做了大量的調整與重構，所以整個分布式系統的應用與部署才能變得更加高效。

　　陳定瑋提到，“我們的容器化建設其實相當于重新開發了一套系統，之所以付出這么多努力去做這件事，除了看重容器化對于系統整體效率的提升以外，還在于通過容器技術可以解決很多實際問題，比如最重要的一點是節省了成本，這里面包括人力成本、效率以及硬件投入成本等，這往往是技術管理者最關注的地方。對于新技術是否采用的出發點，都是以成本去考量。飛貸整個容器化建設完成之后，物理資源成本相比私有云節省 40%，人力成本可以再節約 60%，研發投入可以再節省 40%，還有容器本身快速應用部署帶來的效率的提升，比如可以在短時間內快速搭建出上百套現有環境，更快地服務 B 端用戶。容器化對于飛貸而言意義重大。”

　　飛貸容器化建設的痛點

　　飛貸的客戶主要由 B 端和 C 端構成，而促使飛貸進行容器化建設的動力來自于 B 端客戶的需求。

　　飛貸采用混合云結構，私有云用 CloudStack 搭建，現有虛擬機規模在 3000~4000 臺，如果沒有做容器云平臺，那么幫助 B 端客戶搭建一套框架體系大概要花費 1~2 周的時間。當容器云平臺搭建成以后，一天時間就可以部署上百套系統。同樣的環境下，效益提升了 10 倍以上，物理資源也節省了 40%——也就是說，用原來的做法需要 100 臺服務器，但是用容器之后只需要 60 臺。

　　陳定瑋提到，“B 端客戶要在飛貸的平臺上運行業務，就相當于將飛貸整個技術平臺租給企業客戶，由飛貸負責運維。這里面有兩種模式：一種是我們提供金融云的服務，根據客戶需求去定制化流程和服務；另一種是將飛貸的系統部署在 B 端。但這會存在一個問題，由于是分布式部署上百或上千臺服務器，我們幫客戶部署完，除了網路調通以外，他們后續的運維會非常復雜，不僅浪費資源，而且效率很低，但痛點就在于 B 端客戶對資源的管控非常嚴格，導致后續在運維上比較棘手。”

　　做容器化以后，可以實現統一管理、統一調度，并且容器本身具有非常高的彈性伸縮的能力，因而在資源投入上會減少很多，這就滿足了 B 端客戶管控資源的需求。而且在容器化以后，不僅部署速度極大提升，也可以在一個管控界面上去追蹤所有的應用與服務，從而節省人力的投入，這是 B 端客戶的技術人員也比較認可的方式。

　　飛貸容器云平臺建設思路

　　容器云平臺架構

　　對于飛貸的容器云平臺的建設思路，陳定瑋坦言，其實任何新技術的引入都要從三點來考慮：

　　是否勇于嘗試新技術；

　　新技術能否結合實際來運用；

　　評估技術成熟度和技術團隊掌握能力，這里面包括兩點，一是評估新技術是否足夠成熟；二是判斷技術團隊是否有能力掌握。

　　早在 2015 年，陳定瑋和他的技術團隊開始研究容器技術，并做了相應的調研評估。2016 年開始試點，把容器 1.0 版本上到研發和測試環境。2017 年，開始調研和使用 K8S ，“其實在 2016 年的時候，我們也嘗試了很多方案，但是當時容器技術在大規模應用編排管理上不夠成熟，所以那個時候我們不太敢上生產，而且那時候容器運維、安全防護方面也不是很完善，這兩個原因導致容器技術遲遲沒有開始上生產”。

　　到了 2017 年， K8S 迅速成為容器集群管理的主流平臺。陳定瑋和團隊于是開始去調研和使用 K8S。“我們一定要對新技術有一定的掌握度，到了 2018 年，基于 K8S 和容器 2.0 版本，我們做了 MySQL 容器化測試。2018-2019 年，我們一直在做的就是改造所有的系統，要打造容器化平臺生態圈，以容器為主導，慢慢替換 CloudStack 的環境。”

　　飛貸金融科技容器化歷程

　　不要為了容器化而做容器化

　　很多公司聲稱要做容器化，其實只是“換湯不換藥”，不是說把平臺換成容器就能解決所有問題。陳定瑋說，“我們不是為了容器化而容器化，整個飛貸的代碼質量和產品都要符合容器的要求和規范。因此我們做了大量重寫，才能達到容器標準，不然秒級容災、秒級恢復怎么實現呢？如果 DB 啟動時間要 5 分鐘，不管用容器還是傳統的虛擬機部署，整套系統的啟動時間還是 5 分鐘，這個安全級別達不到金融行業的標準。容器最大的好處是能夠實現秒級啟動和秒級恢復，但是容器只是對應用做封裝，而不是提供一個環境（這跟虛擬機不同），所以應用也要隨之修改，才能達到容器的標準，實現快速啟動。其實我們背后做了非常多的改造。”

　　金融企業非常重視代碼質量，飛貸因此開發了一個代碼質量的管理體系，建立代碼質量審查體系，只要 RD 代碼的撰寫與風格不符合規范，代碼是沒有辦法提交的，這也是 DevOps 流程的一部分。同時飛貸也研發了基于容器的代碼流程自動化系統，也就是 RD 從開發代碼到打包、發布、到生產和測試環境，全流程由系統自動化生成。同時將自研中間件與微服務整合在一起，實現類似于“ Service Mesh ”的“ DB Mesh ”。據了解，業界在 DB 容器化實踐上還沒有比較成功的核心生產系統案例，飛貸是目前為止第一個擁有成熟解決方案的公司。

　　容器化建設的坑與經驗

　　在談及飛貸做容器化建設過程中踩過的坑時，陳定瑋還是感慨萬千，“容器技術在早期沒有完善的運維部署和管理體系，導致從金融領域的行業標準的角度來看，我們是不達標的。雖然我們一直在前進，但底層技術不支持，無論我們在上層應用做什么都無濟于事。這是我覺得飛貸在容器化這條路上遇到的一個坑點。其實根源還是金融行業的特殊性，對于數據安全、信息安全的要求非常高，所以每一步都必須達到高標準。在 2018 年以前，我們都只是在 RD 環境和測試環境使用。因此我需要花費大量的精力平衡人力成本，去處理效率低下和代碼質量等等問題。后來隨著技術和時機的成熟，我們的容器化才真正開始上生產，實現了系統部署和快速交付，我可以騰出時間去抓代碼質量、代碼規范、減少 Bug 率，整個容器化建設和容器化生態也有條不紊地快速落地。”

　　MySQL 容器化 DB Mesh 的創造性實踐

　　從應用層來看，容器化發展得很好，但是數據庫仍然存在很多問題。如果數據庫中斷，重新恢復數據庫和業務生產需要花很長時間。如果數據庫非常大，那么啟動時間會非常久。這就是為什么銀行或大型金融機構不敢用開源數據庫 MySQL 或 MongoDB 等的原因，因為他們要保證安全和持續運作。

　　飛貸要做數據庫容器化的原因，一是為了要實現標準化快速部署。如果應用快速部署完，而數據庫部署慢，那么系統的整體效率還是慢。二是飛貸現有系統已經全部實現微服務化，在這種場景下數據庫實例如果不能做微服務，它就會成為業務彈性伸縮以及管理的短板。三是為了更長遠的目標，就是真正實現網格化（DB Mesh）。

　　MySQL 容器化 DB Mesh 架構如下圖所示。可以看到，多個不同的應用服務對應多個不同的中間件，每個中間件對應一個單獨的數據庫節點，形成一種類似于 Service Mesh 的 DB Mesh 架構，可以靈活調度遷移數據庫節點。為了數據庫容器化穩定，對業務數據實現分庫分表存儲，并限制單個分庫節點的容量。在數據庫遭遇故障時，可以多節點并行迅速恢復。可以說，飛貸在整體業務運作上擁有強大的數據分庫分表、讀寫分離的技術能力，這些能力是由飛貸自研中間件完成的，中間件是實現 MySQL DB Mesh 的關鍵所在。

　　MySQL 容器化 DB Mesh 架構

　　飛貸不是第一個做數據庫容器化的公司，之前一些公司也嘗試過，但都失敗了。飛貸做數據庫容器化可借鑒的一些思路是：

　　限制 DB 的容量：只有單個 DB 容量進行限制，有了標準，才能夠快速部署交付。但是對于銀行和一些傳統金融機構，一般采用 Oracle 數據庫，數據全部堆在那兒，就很難做數據庫的容器化，因為“牽一發而動全身”，如果改變數據庫，那勢必上層就要做很多的調整，這是數據庫容器化的難點之一。

　　結合中間件演化 DB Mesh：飛貸在數據庫容器化實踐中，通過自研中間件，一個中間件對應一個 DB，下面對應不同的服務。在數據處理上，中間件可以讓數據存儲變得簡單可控，這是數據庫容器化的核心，形成一個類似 Service Mesh 的 DB Mesh 架構，DB 與 Service 解耦，使得 DB 的彈性調度非常靈活。

　　改變傳統的思維模式：飛貸做數據庫容器化，整套體系用于服務生產環境上的一切應用。但其實這套體系不利于分析和報表，因為做了很多分庫，那么在做數據分析和報表的時候效率會非常低。陳定瑋和團隊想到了解決方案——用大數據做分析，把所有的報表、分析等等這些文獻，全部實時同步到大數據去，讓大數據來處理。這樣既保證了 B 端客戶的處理數據的秒級體驗，又能快速高效地做數據分析。

　　MySQL 容器化，透過 Istio 生成可視化圖形界面，可以去做自動追蹤，判斷庫的健康狀況。但也存在一個問題，當數據庫中斷，再把它恢復的時候，Istio 追蹤服務就不見了，需要手工注入。陳定瑋提到，“這個問題我們進行了研究，沒有找到很好的解決方案，可能還是要手工去處理一下，沒有辦法做到自動恢復。但是在應用與服務管理這部分，飛貸已經做到了完全自動化的 Istio 注入，實現了微服務訪問、安全加固、控制、觀察、服務追蹤、限速、熔斷、調度、負載等。”

　　飛貸容器化平臺成果

　　飛貸做容器化平臺以后，生產力得到了提升：80% 的基礎運維實現自動化；交付能力大幅提升，1 小時可以交付 100 套；實現極致的彈性容器化調度、灰度升級、預發布、藍綠部署、持續交付。在安全 / 敏捷 / 高效率上，實現業務數據全量備份分鐘級；在災難故障方面，業務應用一鍵恢復分鐘級；數據快照秒級；資源利用率提升 10 倍，數據庫交付能力提升百倍。

　　對于飛貸容器化平臺，Rancher Labs 大中華區總經理秦小康這樣評價：在容器時代，飛貸金融科技仍然保持了領先的創新，并通過業界領先的數據庫容器化技術，提升數據庫服務交付效率，大規模的容器化分布式數據庫集群部署開業界先河，值得大家參考學習。

　　開源初心

　　談及飛貸容器化建設的未來規劃，陳定瑋提到 由 DevOps 向 AIOps 發展。“比如現在做了一個飛貸自動化運維 App，實現監控及消息告警，對接運維機器人，這其實就是大家一直在談的 AI 概念，只是我們把 AI 的概念變到運維體系里面，結合容器化提高效率，實現更穩定的系統服務。這樣，以后在這個 App 上面可以看到生產資源上所有的體系或者設備的狀況；另外，我們會做很多自動化的策略，包含機器學習，就能快速知道問題發生后的處理辦法，減少 RD 或者運維人員的壓力，提升整個平臺的自動化和智能化的能力，由 DevOps 發展到 AIOps，就是往智能化運維去發展。”