2014年：基于分布式的基礎(chǔ)架構(gòu)

微眾銀行在2014年成立之時(shí)，就非常有前瞻性的確立了微眾銀行的IT基礎(chǔ)架構(gòu)的方向：摒棄傳統(tǒng)的基于商業(yè)IT產(chǎn)品的集中架構(gòu)模式，走互聯(lián)網(wǎng)模式的分布式架構(gòu)。眾所周知，傳統(tǒng)銀行IT架構(gòu)體系非常依賴于傳統(tǒng)的商業(yè)數(shù)據(jù)庫，商業(yè)存儲(chǔ)以及大中型服務(wù)器設(shè)備，每年也需要巨大的IT費(fèi)用去維護(hù)和升級(jí)，同時(shí)這種集中式的架構(gòu)，也不便于進(jìn)行高效的實(shí)現(xiàn)水平擴(kuò)展。從過往經(jīng)驗(yàn)來看，當(dāng)時(shí)除了oracle等少數(shù)傳統(tǒng)的商業(yè)數(shù)據(jù)庫，能滿足金融級(jí)銀行場景的數(shù)據(jù)庫產(chǎn)品并不多。當(dāng)時(shí)騰訊有一款金融級(jí)的分布式數(shù)據(jù)庫產(chǎn)品TDSQL，主要承載騰訊內(nèi)部的計(jì)費(fèi)和支付業(yè)務(wù)，其業(yè)務(wù)場景和對數(shù)據(jù)庫的可靠性要求，和銀行場景非常類似，同時(shí)也經(jīng)受了騰訊海量計(jì)費(fèi)業(yè)務(wù)場景的驗(yàn)證。微眾銀行基礎(chǔ)架構(gòu)團(tuán)隊(duì)，經(jīng)過多輪的評估和測試，最終確定和騰訊TDSQL團(tuán)隊(duì)合作，共同將TDSQL打造為適合銀行核心場景使用的金融級(jí)分布式數(shù)據(jù)庫產(chǎn)品，并將TDSQL用于微眾銀行的核心系統(tǒng)數(shù)據(jù)庫。

Why TDSQL？

為什么會(huì)選用TDSQL，作為微眾銀行的核心數(shù)據(jù)庫呢？本章節(jié)將會(huì)詳細(xì)介紹TDSQL架構(gòu)、以及TDSQL的核心特性，看看TDSQL是如何滿足了金融級(jí)場景的數(shù)據(jù)庫要求。

TDSQL架構(gòu)介紹

TDSQL是基于MySQL/Mariadb社區(qū)版本打造的一款金融級(jí)分布式數(shù)據(jù)庫集群方案。在內(nèi)核層面，TDSQL針對MySQL 社區(qū)版本和Mariadb 社區(qū)版本的內(nèi)核，在復(fù)制模塊做了系統(tǒng)級(jí)優(yōu)化，使得其具備主備副本數(shù)據(jù)強(qiáng)一致同步的特性，極大提升了數(shù)據(jù)安全性，同時(shí)相對原生的半同步復(fù)制機(jī)制，TDSQL強(qiáng)一致復(fù)制的性能也有極大提升。

TDSQL集成了TDSQL Agent、TDSQL SQLEngineSQLEngine、TDSQL Scheduler等多個(gè)模塊，實(shí)現(xiàn)了讀寫分離、AutoSharding、自動(dòng)主備強(qiáng)一致性切換、自動(dòng)故障修復(fù)、實(shí)時(shí)監(jiān)控、實(shí)時(shí)冷備等一系列功能。TDSQL架構(gòu)模型如圖1所示：

圖1 TDSQL架構(gòu)模型與SET模型

我們可以從橫向和縱向兩個(gè)維度來理解TDSQL的架構(gòu)。

橫向是TDSQL的請求處理路徑，請過通過APP發(fā)出，經(jīng)過負(fù)載均衡模塊，轉(zhuǎn)發(fā)到TDSQL SQLEngine集群；TDSQL SQLEngine收到請求后，進(jìn)行請求解析，然后轉(zhuǎn)發(fā)到set單元內(nèi)的數(shù)據(jù)庫實(shí)例節(jié)點(diǎn)上（寫請求到master，讀請求可以到master或slave）；數(shù)據(jù)庫實(shí)例處理好請求后，回包給TDSQL SQLEngine，TDSQL SQLEngine再通過負(fù)載均衡模塊回包給app。

縱向是TDSQL集群的管理路徑：TDSQL的一個(gè)管理單元稱為一個(gè)set，每個(gè)set單元的每個(gè)數(shù)據(jù)庫實(shí)例上，都會(huì)部署一個(gè)TDSQL Agent模塊。Agent模塊會(huì)收集所在數(shù)據(jù)庫實(shí)例的所有監(jiān)控信息（包括節(jié)點(diǎn)主備角色信息/節(jié)點(diǎn)存活狀態(tài)/請求量/TPS/CPU負(fù)載/IO負(fù)載/慢查詢/連接數(shù)/容量使用率等等），上報(bào)到zookeeper集群；zookeeper相當(dāng)于整個(gè)TDSQL集群元數(shù)據(jù)存儲(chǔ)管理中心，保存了集群所有元數(shù)據(jù)信息；TDSQL Scheduler模塊會(huì)監(jiān)控zookeeper的所存儲(chǔ)的上報(bào)信息，并根據(jù)集群狀態(tài)啟動(dòng)不同的調(diào)度任務(wù)，相當(dāng)于TDSQL集群的大腦，負(fù)責(zé)整個(gè)集群的管理和調(diào)度。

TDSQL noshard與shard模式

TDSQL提供了noshard與shard兩種使用模式，如圖2所示。

所謂noshard模式，就是單實(shí)例模式，不做自動(dòng)的分庫分表，在語法和功能上完全兼容于MySQL，缺點(diǎn)是只支持垂直擴(kuò)容，這會(huì)受限于單實(shí)例服務(wù)器的性能和容量上限，無法進(jìn)行水平擴(kuò)展。

Shard模式即AutoSharding模式。通過TDSQL SQLEngine模塊，實(shí)現(xiàn)數(shù)據(jù)庫的Sharding和分布式事務(wù)功能，底層的數(shù)據(jù)打散在多個(gè)數(shù)據(jù)庫實(shí)例上，對應(yīng)用層還是統(tǒng)一的單庫視圖。Shard模式可以實(shí)現(xiàn)容量和性能的水平擴(kuò)展，通過兩階段XA支持分布式事務(wù)和各種關(guān)聯(lián)操作，但是目前還不支持存儲(chǔ)過程，同時(shí)在建表的時(shí)候需要業(yè)務(wù)指定shard key，對部分業(yè)務(wù)開發(fā)來說覺得會(huì)有一定的侵入性 。

圖2 TDSQL noshard與shard模式

微眾銀行當(dāng)時(shí)在做系統(tǒng)架構(gòu)的時(shí)候充分考慮了是采用shard版本的純分布式數(shù)據(jù)庫還是從應(yīng)用層的角度來做分布式，通過大量的調(diào)研分析，最終覺得采用應(yīng)用做分布式是最可控，最安全，最靈活，最可擴(kuò)展的模式，從而設(shè)計(jì)了基于DCN的分布式可擴(kuò)展架構(gòu)，通過在應(yīng)用層做水平拆分，數(shù)據(jù)庫采用TDSQL noshard模式，保證了數(shù)據(jù)庫架構(gòu)的簡潔性和業(yè)務(wù)層兼容性，這個(gè)后面會(huì)詳述。

主備強(qiáng)一致切換與秒級(jí)恢復(fù)

TDSQL通過針對mysql內(nèi)核源碼的定制級(jí)優(yōu)化，實(shí)現(xiàn)真正意義上的多副本強(qiáng)一致性復(fù)制，通過主備部署模式，可以實(shí)現(xiàn)RPO=0，即數(shù)據(jù)0丟失，這對于金融場景是至關(guān)重要也是最基礎(chǔ)的要求；同時(shí)基于TDSQL Agent和Scheduler等模塊，也實(shí)現(xiàn)了自動(dòng)化的主備強(qiáng)一致切換，在30秒內(nèi)可以完成整個(gè)主備切換流程，實(shí)現(xiàn)故障RTO的秒級(jí)恢復(fù)。

Watch節(jié)點(diǎn)模式

TDSQL slave節(jié)點(diǎn)提供了兩種角色，一種是follower節(jié)點(diǎn)，一種是watch節(jié)點(diǎn)。Fllower節(jié)點(diǎn)與watch節(jié)點(diǎn)都從master節(jié)點(diǎn)實(shí)時(shí)同步數(shù)據(jù)，但watch節(jié)點(diǎn)不參與主備選舉和主備切換，只作為觀察者同步數(shù)據(jù)。Follower節(jié)點(diǎn)和watch節(jié)點(diǎn)的角色可以在線實(shí)時(shí)調(diào)整。

自動(dòng)化監(jiān)控與運(yùn)維

TDSQL配套提供了赤兔管理平臺(tái)系統(tǒng)，來支持整個(gè)TDSQL集群的可視化、自動(dòng)化的監(jiān)控和運(yùn)維功能。如圖3所示，為TDSQL赤兔管理平臺(tái)的運(yùn)行界面。

圖3 TDSQL赤兔管理平臺(tái)

通過TDSQL赤兔管理平臺(tái)，可以實(shí)現(xiàn)監(jiān)控?cái)?shù)據(jù)的采集與顯示，告警和策略配置，日常運(yùn)維操作（主備切換，節(jié)點(diǎn)替換，配置更改等），數(shù)據(jù)庫備份與恢復(fù)，慢查詢分析，性能分析等一系列功能，極大的提升了運(yùn)維效率和運(yùn)維準(zhǔn)確性。

基于以上的TDSQL的架構(gòu)和特性，我們認(rèn)為TDSQL很好了滿足金融業(yè)務(wù)場景中對數(shù)據(jù)庫的高可用、高可靠、可運(yùn)維的要求，同時(shí)基于MySQL和X86的軟硬件平臺(tái)，也能極大的降低數(shù)據(jù)庫層面的IT成本，從而極大降低戶均成本，非常適用互聯(lián)網(wǎng)時(shí)代的新一代銀行架構(gòu)。

基于DCN的分布式擴(kuò)展架構(gòu)

前文提到，微眾銀行為了實(shí)現(xiàn)業(yè)務(wù)規(guī)模的水平擴(kuò)展，設(shè)計(jì)了基于DCN的分布式可擴(kuò)展架構(gòu)，從而即實(shí)現(xiàn)了擴(kuò)展性，也保證了數(shù)據(jù)庫層面架構(gòu)以的簡潔性。

DCN，即Data Center Node(數(shù)據(jù)中心節(jié)點(diǎn))，是一個(gè)邏輯區(qū)域概念，DCN是一個(gè)自包含單位，包括了完整的應(yīng)用層，接入層和數(shù)據(jù)庫庫?？梢酝ㄋ椎睦斫鉃?，一個(gè)DCN，即為一個(gè)微眾銀行的線上的虛擬分行，這個(gè)虛擬分行只承載微眾銀行某個(gè)業(yè)務(wù)的一部分客戶。通過一定的路由規(guī)則（比如帳戶號(hào)分段），將不同的客戶劃分到不同的DCN內(nèi)。一旦某個(gè)DCN所承載的客戶數(shù)達(dá)到規(guī)定的上限，那么這個(gè)DCN將不再增加新的客戶。這時(shí)通過部署新的DCN，來實(shí)現(xiàn)容量的水平擴(kuò)展，保證業(yè)務(wù)的持續(xù)快速發(fā)展。

不同的客戶保存在不同的DCN，那么就需要有一個(gè)系統(tǒng)來保留全局的路由信息，記錄某個(gè)客戶到底在哪個(gè)DCN，這個(gè)系統(tǒng)就是GNS（Global Name Service），應(yīng)用模塊會(huì)先請求GNS，拿到對應(yīng)客戶的DCN信息，然后再去請求對應(yīng)的DCN。GNS使用了redis緩存，以保證較高的查詢QPS性能，同時(shí)采用TDSQL做持久化存儲(chǔ)，以保證數(shù)據(jù)的安全性。

RMB（Reliable Message Bug），可靠消息總線，是DCN架構(gòu)的另一個(gè)核心模塊，主要負(fù)責(zé)各個(gè)業(yè)務(wù)系統(tǒng)之間高效、準(zhǔn)確、快速的消息通信。DCN的整體架構(gòu)如圖4所示

圖4 DCN架構(gòu)模型

微眾銀行IDC架構(gòu)

有了基于DCN的基礎(chǔ)架構(gòu)模型，下一步就是基礎(chǔ)物理環(huán)境的建設(shè)。微眾銀行經(jīng)過4年多的發(fā)展，目前已發(fā)展成為兩地六中心的架構(gòu)，如圖5所示：

圖5 微眾銀行IDC架構(gòu)

其中兩地位于深圳和上海，深圳作為生產(chǎn)中心，在深圳同城有5個(gè)IDC機(jī)房，上海作為跨城異地容災(zāi)，有1個(gè)IDC機(jī)房。深圳5個(gè)同城IDC，通過多條專線兩兩互聯(lián)，保證極高的網(wǎng)絡(luò)質(zhì)量和帶寬，同時(shí)任何兩個(gè)IDC之間的距離控制在10~50公里左右，以保證機(jī)房間的網(wǎng)絡(luò)ping延遲控制在2ms左右。這一點(diǎn)非常重要，是實(shí)現(xiàn)TDSQL同城跨IDC部署的前提。

基于TDSQL的同城應(yīng)用多活

基于以上的 DCN 架構(gòu)和 IDC 架構(gòu)，我們設(shè)計(jì)了TDSQL數(shù)據(jù)庫在微眾銀行的部署架構(gòu)。如圖6所示：

圖6 微眾銀行基于TDSQL的同城多活架構(gòu)

我們采用同城3副本+跨城2副本的3+2 noshard部署模式。同城3副本為1主2備，分別部署同城的3個(gè)IDC中，副本之間采用TDSQL強(qiáng)一致同步，保證同城3 IDC之間的RPO=0，RTO秒級(jí)恢復(fù)。跨城的2副本通過同城的一個(gè)slave進(jìn)行異步復(fù)制，實(shí)現(xiàn)跨城的數(shù)據(jù)容災(zāi)?；谝陨霞軜?gòu)，我們在同城可以做到應(yīng)用多活，即聯(lián)機(jī)的業(yè)務(wù)流量，可以同時(shí)從3個(gè)IDC接入，任何一個(gè)IDC故障不可用，都可以保證數(shù)據(jù)0丟失，同時(shí)在秒級(jí)內(nèi)可以恢復(fù)數(shù)據(jù)庫服務(wù)。

在同一IDC內(nèi)，服務(wù)器之間的ping延遲通常在0.1ms以內(nèi)，而同城跨IDC之間服務(wù)器的ping延遲會(huì)大大增加，那是否會(huì)影響TDSQL主備強(qiáng)同步的性能呢？另外IDC之間的網(wǎng)絡(luò)穩(wěn)定性能否保證呢？我們通過以下幾個(gè)措施來消除或者規(guī)避這個(gè)問題。

首先，在基礎(chǔ)設(shè)施層面，我們會(huì)保證同城的三個(gè)IDC之間的距離控制在10~50公里左右，控制網(wǎng)絡(luò)延遲在2ms左右；同時(shí)在IDC之間建設(shè)多條專線，保證網(wǎng)絡(luò)傳輸?shù)馁|(zhì)量和穩(wěn)定性；其次，TDSQL針對這種跨IDC強(qiáng)同步的場景，作了大量的內(nèi)核級(jí)優(yōu)化，比如采用隊(duì)列異步化，以及并發(fā)復(fù)制等技術(shù)。通過基準(zhǔn)測試表明，跨IDC強(qiáng)同步對聯(lián)機(jī)OLTP的性能影響僅在10%左右。

從我們實(shí)際生產(chǎn)運(yùn)營情況來看，這種同城跨IDC的部署模式，對于聯(lián)機(jī)OLTP業(yè)務(wù)的性能影響，完全是可以接受的，但對于集中批量的場景，因?yàn)槔鄯e效應(yīng)，可能最終會(huì)對批量的完成時(shí)效產(chǎn)生較大影響。如果批量APP需要跨IDC訪問數(shù)據(jù)庫，那么整個(gè)批量期間每次訪問數(shù)據(jù)庫的網(wǎng)絡(luò)延遲都會(huì)被不斷累積放大，最終會(huì)嚴(yán)重影響跑批效率。為了解決這個(gè)問題，我們利用了TDSQL的watch節(jié)點(diǎn)的機(jī)制，針對參與跑批的TDSQL SET，我們在原來一主兩備的基礎(chǔ)上，額外部署了一個(gè)與主節(jié)點(diǎn)同IDC的WATCH節(jié)點(diǎn)，同時(shí)保證批量APP與主節(jié)點(diǎn)部署在同一APP。如圖7所示：

圖7 TDSQL帶WATCH節(jié)點(diǎn)的部署模式

WATCH節(jié)點(diǎn)與主節(jié)點(diǎn)同IDC部署，從主節(jié)點(diǎn)異步同步數(shù)據(jù)。因?yàn)槭荳ATCH節(jié)點(diǎn)是異步同步，所以主節(jié)點(diǎn)的binlog會(huì)確保同步到跨IDC的另外兩個(gè)備節(jié)點(diǎn)事務(wù)才算成功，這樣即使主節(jié)點(diǎn)所在的IDC整個(gè)宕掉，仍能保證數(shù)據(jù)的完整性，不會(huì)影響IDC容災(zāi)特性。當(dāng)主節(jié)點(diǎn)發(fā)生故障時(shí)，scheduler模塊對對比watch節(jié)點(diǎn)和其他2個(gè)強(qiáng)同步備機(jī)的數(shù)據(jù)一致性，如果發(fā)現(xiàn)watch節(jié)點(diǎn)的數(shù)據(jù)跟另外2個(gè)idc數(shù)據(jù)一樣新（這是常態(tài)，因?yàn)橥琁DC一般都比跨IDC快），則優(yōu)先會(huì)將這個(gè)watch節(jié)點(diǎn)提升為主機(jī)。這就保證了批量APP與數(shù)據(jù)庫主節(jié)節(jié)點(diǎn)盡量處于同一個(gè)IDC，避免了跨IDC訪問帶來的時(shí)延影響。

通過以上部署架構(gòu)，我們實(shí)現(xiàn)了同城跨IDC級(jí)別的高可用，以及同城跨IDC的應(yīng)用多活，極大提升了微眾銀行基礎(chǔ)架構(gòu)的整體可用性與可靠性。

TDSQL集群規(guī)模

微眾銀行成立4年多以來，業(yè)務(wù)迅速發(fā)展，目前有效客戶數(shù)已過億級(jí)，微粒貸，微業(yè)貸等也成為行業(yè)的明星產(chǎn)品。在業(yè)務(wù)規(guī)模迅速增長的過程中，我們的數(shù)據(jù)庫規(guī)模也在不斷的增長。當(dāng)前微眾銀行的TDSQL SET個(gè)數(shù)已達(dá)350+（生產(chǎn)+容災(zāi)），數(shù)據(jù)庫實(shí)例個(gè)數(shù)已達(dá)到1700+， 整體數(shù)據(jù)規(guī)模已達(dá)到PB級(jí)，承載了微眾銀行數(shù)百個(gè)核心系統(tǒng)。在以往的業(yè)務(wù)高峰中，最高達(dá)到日3.6億+的金融交易量，最高的TPS也達(dá)到了10萬+。如圖8所示：

圖8 微眾銀行TDSQL業(yè)務(wù)規(guī)模

在過去4年多的運(yùn)營中，TDSQL也從未出現(xiàn)過大的系統(tǒng)故障，或者數(shù)據(jù)安全問題，同時(shí)基于TDSQL的X86的軟硬件架構(gòu)，幫助微眾銀行極大的降低IT戶均成本，極大提升了微眾銀行的行業(yè)競爭力。微眾銀行通過實(shí)踐證明，TDSQL作為金融級(jí)的核心數(shù)據(jù)庫，是完全勝任的。

微眾銀行數(shù)據(jù)庫現(xiàn)狀及未來發(fā)展

目前，TDSQL承載了微眾銀行99%以上線上數(shù)據(jù)庫業(yè)務(wù)，同時(shí)我行也大量采用了redis作為緩存，以解決秒殺，搶購等熱點(diǎn)場景，另外還有少量的mongodb滿足文檔類的存儲(chǔ)需求。同時(shí)我行從去年開始，也嘗試引入了NEWSQL數(shù)據(jù)庫TiDB，解決少部分無法拆分DCN，但同時(shí)又對單庫存儲(chǔ)容量或吞吐量有超大需求的業(yè)務(wù)場景。整體來看，我行目前的數(shù)據(jù)庫主要有TDSQL，TIDB以及Redis/MongoDB，TDSQL主要承載核心系統(tǒng)業(yè)務(wù) ，TIDB作為補(bǔ)充解決單庫需要超大容量或超大吞吐量的非聯(lián)機(jī)業(yè)務(wù)需求，Reids和MongoDB則主要是提供緩存及文檔型的存儲(chǔ)。

當(dāng)然我們并不會(huì)止步于此，微眾銀行數(shù)據(jù)庫團(tuán)隊(duì)和騰訊云TDSQL團(tuán)隊(duì)未來會(huì)有更加深入的合作。比如我們和騰訊云TDSQL團(tuán)隊(duì)合作的TDSQL智能運(yùn)維-扁鵲項(xiàng)目，目前已在微眾銀行灰度上線，可以實(shí)時(shí)分析TDSQL的運(yùn)行狀態(tài)和性能問題，是提升運(yùn)維效率的利器。我們和也在和TDSQL研發(fā)團(tuán)隊(duì)共同調(diào)研和評估MySQL 8.0版本，以及MySQL基于MGR的高可用功能，未來可能會(huì)嘗試將MySQL 8.0和MGR集成到TDSQL系統(tǒng)中，并嘗試在銀行核心系統(tǒng)中試用。