一、2014年：基於分佈式的基礎架構
微衆銀行在2014年成立之時，就非常有前瞻性的確立了微衆銀行的IT基礎架構的方向：摒棄傳統的基於商業IT產品的集中架構模式，走互聯網模式的分佈式架構。衆所周知，傳統銀行IT架構體系非常依賴於傳統的商業數據庫，商業存儲以及大中型服務器設備，每年也需要巨大的IT費用去維護和升級，同時這種集中式的架構，也不便於進行高效的實現水平擴展。從過往經驗來看，當時除了oracle等少數傳統的商業數據庫，能滿足金融級銀行場景的數據庫產品並不多。當時騰訊有一款金融級的分佈式數據庫產品TDSQL，主要承載騰訊內部的計費和支付業務，其業務場景和對數據庫的可靠性要求，和銀行場景非常類似，同時也經受了騰訊海量計費業務場景的驗證。微衆銀行基礎架構團隊，經過多輪的評估和測試，最終確定和騰訊TDSQL團隊合作，共同將TDSQL打造爲適合銀行核心場景使用的金融級分佈式數據庫產品，並將TDSQL用於微衆銀行的核心繫統數據庫。
二、Why TDSQL？
爲什麼會選用TDSQL，作爲微衆銀行的核心數據庫呢？本章節將會詳細介紹TDSQL架構、以及TDSQL的核心特性，看看TDSQL是如何滿足了金融級場景的數據庫要求。
TDSQL架構介紹
TDSQL是基於MySQL/Mariadb社區版本打造的一款金融級分佈式數據庫集羣方案。在內核層面，TDSQL針對MySQL 社區版本和Mariadb 社區版本的內核，在複製模塊做了系統級優化，使得其具備主備副本數據強一致同步的特性，極大提升了數據安全性，同時相對原生的半同步複製機制，TDSQL強一致複製的性能也有極大提升。
TDSQL集成了TDSQL Agent、TDSQL SQLEngineSQLEngine、TDSQL Scheduler等多個模塊，實現了讀寫分離、AutoSharding、自動主備強一致性切換、自動故障修復、實時監控、實時冷備等一系列功能。TDSQL架構模型如下面2圖所示：
我們可以從橫向和縱向兩個維度來理解TDSQL的架構。
橫向是TDSQL的請求處理路徑，請過通過APP發出，經過負載均衡模塊，轉發到TDSQL SQLEngine集羣；TDSQL SQLEngine收到請求後，進行請求解析，然後轉發到set單元內的數據庫實例節點上（寫請求到master，讀請求可以到master或slave）；數據庫實例處理好請求後，回包給TDSQL SQLEngine，TDSQL SQLEngine再通過負載均衡模塊回包給app。
縱向是TDSQL集羣的管理路徑：TDSQL的一個管理單元稱爲一個set，每個set單元的每個數據庫實例上，都會部署一個TDSQL Agent模塊。 Agent模塊會收集所在數據庫實例的所有監控信息（包括節點主備角色信息/節點存活狀態/請求量/TPS/CPU負載/IO負載/慢查詢/連接數/容量使用率等等），上報到zookeeper集羣；zookeeper相當於整個TDSQL集羣元數據存儲管理中心，保存了集羣所有元數據信息； TDSQL Scheduler模塊會監控zookeeper的所存儲的上報信息，並根據集羣狀態啓動不同的調度任務，相當於TDSQL集羣的大腦，負責整個集羣的管理和調度。
TDSQL noshard與shard模式
TDSQL提供了noshard與shard兩種使用模式，如圖2所示。
所謂noshard模式，就是單實例模式，不做自動的分庫分表，在語法和功能上完全兼容於MySQL，缺點是隻支持垂直擴容，這會受限於單實例服務器的性能和容量上限，無法進行水平擴展。
Shard模式即AutoSharding模式。通過TDSQL SQLEngine模塊，實現數據庫的Sharding和分佈式事務功能，底層的數據打散在多個數據庫實例上，對應用層還是統一的單庫視圖。Shard模式可以實現容量和性能的水平擴展，通過兩階段XA支持分佈式事務和各種關聯操作，但是目前還不支持存儲過程，同時在建表的時候需要業務指定shard key，對部分業務開發來說覺得會有一定的侵入性 。
微衆銀行當時在做系統架構的時候充分考慮了是採用shard版本的純分佈式數據庫還是從應用層的角度來做分佈式，通過大量的調研分析，最終覺得采用應用做分佈式是最可控，最安全，最靈活，最可擴展的模式，從而設計了基於DCN的分佈式可擴展架構，通過在應用層做水平拆分，數據庫採用TDSQL noshard模式，保證了數據庫架構的簡潔性和業務層兼容性，這個後面會詳述。
主備強一致切換與秒級恢復
TDSQL通過針對mysql內核源碼的定製級優化，實現真正意義上的多副本強一致性複製，通過主備部署模式，可以實現RPO=0，即數據0丟失，這對於金融場景是至關重要也是最基礎的要求；同時基於TDSQL Agent和Scheduler等模塊，也實現了自動化的主備強一致切換，在30秒內可以完成整個主備切換流程，實現故障RTO的秒級恢復。
Watch節點模式
TDSQL slave節點提供了兩種角色，一種是follower節點，一種是watch節點。Fllower節點與watch節點都從master節點實時同步數據，但watch節點不參與主備選舉和主備切換，只作爲觀察者同步數據。Follower節點和watch節點的角色可以在線實時調整。
自動化監控與運維
TDSQL配套提供了赤兔管理平臺系統，來支持整個TDSQL集羣的可視化、自動化的監控和運維功能。如圖3所示，爲TDSQL赤兔管理平臺的運行界面。
基於以上的TDSQL的架構和特性，我們認爲TDSQL很好了滿足金融業務場景中對數據庫的高可用、高可靠、可運維的要求，同時基於MySQL和X86的軟硬件平臺，也能極大的降低數據庫層面的IT成本，從而極大降低戶均成本，非常適用互聯網時代的新一代銀行架構。
三、基於DCN的分佈式擴展架構
前文提到，微衆銀行爲了實現業務規模的水平擴展，設計了基於DCN的分佈式可擴展架構，從而即實現了擴展性，也保證了數據庫層面架構以的簡潔性。
DCN，即Data Center Node(數據中心節點)，是一個邏輯區域概念，DCN是一個自包含單位，包括了完整的應用層，接入層和數據庫庫。可以通俗的理解爲，一個DCN，即爲一個微衆銀行的線上的虛擬分行，這個虛擬分行只承載微衆銀行某個業務的一部分客戶。通過一定的路由規則（比如帳戶號分段），將不同的客戶劃分到不同的DCN內。一旦某個DCN所承載的客戶數達到規定的上限，那麼這個DCN將不再增加新的客戶。這時通過部署新的DCN，來實現容量的水平擴展，保證業務的持續快速發展。
不同的客戶保存在不同的DCN，那麼就需要有一個系統來保留全局的路由信息，記錄某個客戶到底在哪個DCN，這個系統就是GNS（Global Name Service），應用模塊會先請求GNS，拿到對應客戶的DCN信息，然後再去請求對應的DCN。GNS使用了redis緩存，以保證較高的查詢QPS性能，同時採用TDSQL做持久化存儲，以保證數據的安全性。
RMB（Reliable Message Bug），可靠消息總線，是DCN架構的另一個核心模塊，主要負責各個業務系統之間高效、準確、快速的消息通信。DCN的整體架構如圖所示:
其中兩地位於深圳和上海，深圳作爲生產中心，在深圳同城有5個IDC機房，上海作爲跨城異地容災，有1個IDC機房。深圳5個同城IDC，通過多條專線兩兩互聯，保證極高的網絡質量和帶寬，同時任何兩個IDC之間的距離控制在10~50公里左右，以保證機房間的網絡ping延遲控制在2ms左右。這一點非常重要，是實現TDSQL同城跨IDC部署的前提。
五、基於TDSQL的同城應用多活
基於以上的 DCN 架構和 IDC 架構，我們設計了TDSQL數據庫在微衆銀行的部署架構。如下圖所示：
我們採用同城3副本+跨城2副本的3+2 noshard部署模式。同城3副本爲1主2備，分別部署同城的3個IDC中，副本之間採用TDSQL強一致同步，保證同城3 IDC之間的RPO=0，RTO秒級恢復。跨城的2副本通過同城的一個slave進行異步複製，實現跨城的數據容災。基於以上架構，我們在同城可以做到應用多活，即聯機的業務流量，可以同時從3個IDC接入，任何一個IDC故障不可用，都可以保證數據0丟失，同時在秒級內可以恢復數據庫服務。
在同一IDC內，服務器之間的ping延遲通常在0.1ms以內，而同城跨IDC之間服務器的ping延遲會大大增加，那是否會影響TDSQL主備強同步的性能呢？另外IDC之間的網絡穩定性能否保證呢？我們通過以下幾個措施來消除或者規避這個問題。
首先，在基礎設施層面，我們會保證同城的三個IDC之間的距離控制在10~50公里左右，控制網絡延遲在2ms左右；同時在IDC之間建設多條專線，保證網絡傳輸的質量和穩定性；其次，TDSQL針對這種跨IDC強同步的場景，作了大量的內核級優化，比如採用隊列異步化，以及併發複製等技術。通過基準測試表明，跨IDC強同步對聯機OLTP的性能影響僅在10%左右。
從我們實際生產運營情況來看，這種同城跨IDC的部署模式，對於聯機OLTP業務的性能影響，完全是可以接受的，但對於集中批量的場景，因爲累積效應，可能最終會對批量的完成時效產生較大影響。如果批量APP需要跨IDC訪問數據庫，那麼整個批量期間每次訪問數據庫的網絡延遲都會被不斷累積放大，最終會嚴重影響跑批效率。爲了解決這個問題，我們利用了TDSQL的watch節點的機制，針對參與跑批的TDSQL SET，我們在原來一主兩備的基礎上，額外部署了一個與主節點同IDC的WATCH節點，同時保證批量APP與主節點部署在同一APP。如下圖所示：
WATCH節點與主節點同IDC部署，從主節點異步同步數據。因爲是WATCH節點是異步同步，所以主節點的binlog會確保同步到跨IDC的另外兩個備節點事務纔算成功，這樣即使主節點所在的IDC整個宕掉，仍能保證數據的完整性，不會影響IDC容災特性。當主節點發生故障時，scheduler模塊對對比watch節點和其他2個強同步備機的數據一致性，如果發現watch節點的數據跟另外2個idc數據一樣新（這是常態，因爲同IDC一般都比跨IDC快），則優先會將這個watch節點提升爲主機。這就保證了批量APP與數據庫主節節點儘量處於同一個IDC，避免了跨IDC訪問帶來的時延影響。
通過以上部署架構，我們實現了同城跨IDC級別的高可用，以及同城跨IDC的應用多活，極大提升了微衆銀行基礎架構的整體可用性與可靠性。
六、TDSQL集羣規模
微衆銀行成立4年多以來，業務迅速發展，目前有效客戶數已過億級，微粒貸，微業貸等也成爲行業的明星產品。在業務規模迅速增長的過程中，我們的數據庫規模也在不斷的增長。當前微衆銀行的TDSQL SET個數已達350+（生產+容災），數據庫實例個數已達到1700+， 整體數據規模已達到PB級，承載了微衆銀行數百個核心系統。在以往的業務高峯中，最高達到日3.6億+的金融交易量，最高的TPS也達到了10萬+。如圖8所示：
在過去4年多的運營中，TDSQL也從未出現過大的系統故障，或者數據安全問題，同時基於TDSQL的X86的軟硬件架構，幫助微衆銀行極大的降低IT戶均成本，極大提升了微衆銀行的行業競爭力。微衆銀行通過實踐證明，TDSQL作爲金融級的核心數據庫，是完全勝任的。
七、微衆銀行數據庫現狀及未來發展
目前，TDSQL承載了微衆銀行99%以上線上數據庫業務，同時我行也大量採用了redis作爲緩存，以解決秒殺，搶購等熱點場景，另外還有少量的mongodb滿足文檔類的存儲需求。同時我行從去年開始，也嘗試引入了NEWSQL數據庫TiDB，解決少部分無法拆分DCN，但同時又對單庫存儲容量或吞吐量有超大需求的業務場景。整體來看，我行目前的數據庫主要有TDSQL，TIDB以及Redis/MongoDB，TDSQL主要承載核心系統業務 ，TIDB作爲補充解決單庫需要超大容量或超大吞吐量的非聯機業務需求，Reids和MongoDB則主要是提供緩存及文檔型的存儲。
當然我們並不會止步於此，微衆銀行數據庫團隊和騰訊雲TDSQL團隊未來會有更加深入的合作。比如我們和騰訊雲TDSQL團隊合作的TDSQL智能運維-扁鵲項目，目前已在微衆銀行灰度上線，可以實時分析TDSQL的運行狀態和性能問題，是提升運維效率的利器。我們和也在和TDSQL研發團隊共同調研和評估MySQL 8.0版本，以及MySQL基於MGR的高可用功能，未來可能會嘗試將MySQL 8.0和MGR集成到TDSQL系統中，並嘗試在銀行核心系統中試用。
作者介紹：
胡盼盼，微衆銀行數據庫平臺負責人。碩士畢業於華中科技大學，畢業後加入騰訊，任高級工程師，從事分佈式存儲與雲數據庫相關的研發與運營工作；2014 年加入微衆銀行，負責微衆銀行的數據庫平臺的設計規劃和運營管理。
黃德志，微衆銀行數據庫平臺高級 DBA。2009年加入平安科技，先後擔任數據庫資深開發工程師及資深運維工程師。2016年加入微衆銀行任高級DBA，負責TDSQL相關運維工作。
相關文章：