對數據庫要求最苛刻的金融行業，這套架構憑什麼異軍突起？

導語 | 在金融行業IT系統國產化的大背景下，國內金融行業開始推進IT基礎設施國產化，逐漸擺脫對於傳統IOE架構的依賴。微衆銀行自成立之初，就放棄了傳統IOE架構路紅，結合騰訊金融級分佈式數據庫TDSQL，創建了基於DCN單元化架構模式的分佈式基礎平臺。現在這套架構承載了微衆銀行數億級別的用戶規模，數百套銀行核心系統，和天天數億次的金融交易。本文由微衆銀行數據庫平臺室室經理、騰訊雲TVP 胡盼盼在 Techo TVP開發者峯會「數據的冰與火之歌——從在線數據庫技術，到海量數據分析技術」 的《分佈式數據庫在微衆銀行核心系統的實踐》演講分享整理而成，爲你們着重介紹金融行業的數據庫趨勢、微衆銀行基於單元化的分佈式架構，以及基於單元化的數據庫架構，並分享微衆銀行數據庫將來的演進方向。

點擊可觀看精彩演講視頻

1、金融行業數據庫趨勢

今天分享的主要內容包含四個方面：第一是介紹金融行業數據庫的趨勢；第二是介紹微衆銀行的單元化架構；第三是基於微衆銀行的單元化架構的數據庫架構是怎麼作的；第四是微衆銀行內部對於數據庫將來架構的演進方向。

金融行業是相對傳統的行業，對於IT基礎設施的選型，都是偏保守，以前一直都很穩定走傳統IOE架構。可是，近幾年產生了一些變化，主要有三個趨勢：

第一是國產化的趨勢。最近幾年的國際形勢衆所周知，在金融行業這種關鍵的領域，對於關鍵的IT基礎設施的國產化，是一個國家層面在推進的方向。另外一方面，得益於國產化浪潮的推進，國產數據庫產品也是百花齊，使得國內的金融企業有不少能夠選擇的國產數據庫。

第二個趨勢是去中心化。互聯網行業的發展帶來數據爆炸性的增加，傳統銀行如今也在慢慢走互聯網化和服務在線化，好比手機銀行APP，原來不少業務須要到線下網點去辦理，如今手機很行上就能夠辦理成功，因此帶來的數據量的也指數級的增加，原來中心化的架構，好比單機存儲或是用共享存儲的方式，無論是性能仍是容量上可能都沒辦法承載這種爆炸性的增加。

第三個趨勢是開源化。在幾年前，金融行業，特別是傳統的銀行，對於開源這種產品模式實際上是不太不信任的，以爲開源的產品，穩定性上沒有保證，也沒有固定的技術團隊支持。可是最近幾年這個認知慢慢變化了，不少同行業的傳統銀行都開始去嘗試一些開源數據庫，好比MySQL，Redis等。把一些非核心的業務場景跑在開源數據庫平臺上，並且規模都不小。另外，咱們國家對整個開源軟件生態建設也在逐漸加大支持，國內開源社區的建設也在慢慢走向成熟。進一步促進了開源數據庫在金融行業的應用。

這張圖是從國內的一個數據庫排名網站上截的，都是如今國內的數據庫產品。咱們能夠看到這張圖裏，有包括騰訊、阿里、華爲這種大廠的數據庫產品，也包括目前開源比較流行的產品，還包括一些傳統的廠商產品，能夠說真的是百花齊放的時代，這在五六年前都是不可想象的。

2、微衆銀行單元化架構

下面介紹一下微衆銀行內部的單元華架構究竟是怎麼作的。微衆銀行於2014年開始籌辦，做爲國內第一家民營銀行，咱們在IT基礎架構方面是沒有歷史包袱的，能夠從零去作一個全新的架構。因此當時定的路線是不會再用傳統銀行的IOE架構，肯定了要走基於分佈式架構的模式去承載整個銀行的核心繫統。

最終咱們選擇了單元化做爲咱們的架構基礎。這裏的單元化怎麼理解呢？以傳統的線下銀行類比一下，傳統銀行，通常在每一個省都有一個分行，每一個省的分行只負責各個省的客戶。微衆銀行的單元化，就相似這種分行的概念。咱們把全部的客戶也拆成一個一個單元去管理，每一個單元就是固定的用戶數量。好比說一個單元裏面咱們就只承載500萬用戶的數量，當這個單元用滿了之後，就直接再總體去擴一個單元。這個單元咱們內部有一個名字：DCN，即最小化的單元化部署單位，DCN裏包含了從應用層到中間件、到底層的數據庫，能夠理解爲一個DCN就是一個自包含的小的微衆銀行。DCN承載的用戶數量是固定的，好比說固定的500萬或者800萬用戶，DCN用滿以後，再橫向擴展一個新的DCN，新的用戶就放到新的DCN裏。

這個DCN架構會帶來兩個問題。

第一個問題：好比你是微衆銀行的用戶，要使用微衆銀行的服務，怎麼知道本身在哪個DCN呢？這裏就有一個關鍵組件：GNS，GNS是負責全部用戶的DCN路由信息存儲與查詢。當一個用戶的請求進來，會首先查詢GNS，獲得所在DCN的定位，再去對應的DCN作後續的請求。

第二個問題：DCN與DCN之間是隔離的，A DCN的一個用戶想給B DCN的一個用戶轉帳，轉帳的消息交換要怎麼實現？這裏就要提到另外一個關鍵組件：RMB，中文名爲：可靠消息總線。RMB的主要功能是負責DCN之間的消息交換，經過GNS和RMB這兩個組件，基本上把整個DCN的路由和消息交換功能解決了。

固然DCN並不能承載全部的業務場景，有些歸檔場景 ，多是要從DCN彙總過來統一存儲和計算，還有一些數據是全局數據，沒法進行DCN拆分，因此咱們看到下面會有一個全局數據管理和後臺管理的區域，叫ADM區。用來解決這一類業務場景。

在不斷線上實踐過程當中，這種DCN架構帶來了很多優點：

第一個優點是它能夠下降故障的影響面。由於DCN從軟件層面到硬件層面所有是獨立拆分的，因此一個DCN硬件的故障影響面有限，好比微衆銀行最大的業務：微粒貸，如今已經有20多個DCN，，某一個DCN的故障可能隻影響總體業務的1/2，能夠有效的控制故障的影響範圍。

第二個優點是能夠實現高效的擴容。目前咱們經過自動化部署的方式，能夠實現一個小時內擴容一個DCN，至關於一小時內從軟件到硬件層面就能夠完成500萬用戶量的擴容。

第三個優點是它能夠實現有效的灰度變動。由於每一個DCN至關因而徹底同構的，能夠去設置一個專門的灰度DCN，放一小部分用戶。每次的版本發佈，好比數據庫的DDL或者應用的版本發佈，均可以在這個小DCN內先灰度，灰度驗證沒問題，再全量發佈到其它的DCN，能夠有效下降版本風險。

最後一個優點，DCN單元化架構帶了數據庫架構的簡化。DCN的用戶規模是受限的，那麼DCN內的數據庫規模，包括數據庫的TPS、IO/CPU負載 、數據量都是具備上限的。因此DCN內的數據庫，就沒有必要採用比較複雜的分佈式或說中間件架構的數據庫來提供所擴展性。咱們在DCN內，採用了最簡單的TDSQL單實例架構，也不用考慮分佈式事務帶來的數據庫的複雜性。

固然這種DCN單元華架構也會帶來一些缺點：

第一：DCN之間物理資源相互獨立，可能每一個DCN都會預留一些buff資源，可能會致使總體的資源利用率不高。

第二：DCN架構對於運維自動化的要求很是高。咱們如今生產整個DCN數量已超過100個，對於多DCN的版本管理、版本發佈和平常變動都須要自動化運維去作。

第三：須要應用層去實現跨DCN的分佈式事務框架，好比我在A DCN，你在B DCN，我須要給你轉一筆錢，若是在原來的中心化架構下，可能就直接利用數據庫的事務去保證一致性，可是在這種跨DCN的架構下，可能須要應用層去實現相似的事務框架，來保證總體事務的一致性。

3、基於單元化的數據庫架構

上面介紹了微衆銀行的DCN單元化架構，基於這個架構的前提，再介紹一下微衆銀行的數據庫架構究竟是怎麼作的。在介紹數據庫架構以前，須要先介紹一些背景知識。

1. 微衆銀行IDC架構

微衆銀行如今IDC的建設，是2地7中心的IDC架構，咱們在深圳有5個生產機房做爲生產中心，在上海有2個容災機房做爲容災中心。咱們在深圳同城的這5個機房選址也是有規定的，兩兩IDC的距離控制在10-50千米的範圍內，以此來保證IDC之間的網絡延遲在2毫秒左右，這是數據庫多副本跨同城IDC部署的前提。

2. 微衆銀行TDSQL部署架構

首先介紹一下TDSQL這個產品。TDSQL是騰訊推出的一款金融級分佈式數據庫產品，微衆銀行目前全部的核心繫統基本都是用TDSQL來承載的。

以下圖，從橫向維度來看，最左邊APP請求進入，會通過一個負載均衡的組件，負載均衡的組件把請求轉發到TDSQL proxy模塊，這個proxy其實實現了SQL解析、讀寫分離、流量控制等功能，至關因而一箇中間件。TDSQL proxy接收到請求後，會把請求轉發到後端對應的SET列表，TDSQL的最小單元是以SET爲單位的，SET裏面本質上就是MySQL，TDSQL針對MySQL內核作了一些定製化的優化。SET裏通常是一主兩備架構，一主兩備之間會採用TDSQL優化後強同步的機制來保證數據多副本的一致性，一個TDSQL proxy下面能夠掛載多個TDSQL SET。

再看縱向維度。能夠持到縱向維度上，TDSQL還有兩個比較關鍵的模塊，一個是zookeeper，它是整個TDSQL配置的管理系統，全部的元數據信息和監控上報的統計信息，都會上報到zookeeper集羣。在zookeeper之上還有一個模塊叫schduler，它負責整個TDSQL任務流程調度，好比SET1如今Master節點可能宕機了，須要作一個主備切換，這個主備切換的流程就是由整個schduler模塊去調度的，它會控制每一步切換的流程，直到最終切換成功。

再補充一下TDSQL的兩種使用模式，一種是NO Shard模式，也就是TDSQL的單實例模式。這種架構下，TDSQL proxy單純作一個SQL轉換的功能，到底層的SET之後，每一個STE就是一個獨立的單實例架構，SET之間的庫是沒有關係的，這種No Shard架構沒有在中間件層作分庫分表，因此邏輯會簡單不少。但這種模式的SET須要擴容的話，就只能在SET內部去作垂直擴容。這種架構的優點在於它不涉及分佈式事務，也不涉及數據庫的分片，因此它的語法是徹底兼容的，且架構簡潔。

第二種模式是TDSQL Shard模式，Shard模式能夠簡單理解爲一種基於中間件分庫分表的模式。經過TDQSL proxy，把某一個庫作成三個Shard分片，這三個分片分別分佈在SET一、SET2和STE3這三個SET裏。這種模式的優勢是能夠實現容量的水平擴容。但它帶來的問題在於對語法的兼容不完美，由於須要在中間件層面實現Shard，就須要一些特殊語法的兼容，好比須要建表的時候帶Share key，SQL裏面可能也須要帶Share key，就須要應用層作適配改造。

剛纔咱們提到微衆銀行的單元化架構，以DCN單元化架構爲基礎，對於數據庫的性能和容量需求是可控的，因此咱們就不須要經過這種Shard模式作擴展，直接採用No Shard模式，從而大大簡化了咱們在數據庫架構和運維的工做量。

基於以上背景知識，咱們來看看微衆銀行的TDSQL的部署架構。從豎向的維度來看，每一個框裏就表明一個IDC，左邊有三個生產IDC，右邊還有跨城容災——上海的兩個IDC。從底層來看，最下面是咱們的數據庫，採用TDSQL數據庫，一主兩備的架構，三個副本分佈在同城的三個IDC內部，好比Master在南山機房，Slave1可能在觀瀾機房，Slave2可能在福田機房。Master、Slave之間採用TDSQL強同步的機制進行數據同步，在一個DCN內咱們可能會有多個SET去承載這個數據庫。

而在數據庫上層，每一個機房都會有獨立的接入層，接入層之上會有獨立的負載均衡功能，最上層是應用層。

基於這種部署架構，咱們實現了同城應用多活的概念。業務流量能夠從生產IDC的任何一個IDC進來，通過應用層到負載均衡的接入層都在同機房內，可是從接入層到上面的數據庫可能就涉及到跨機房流量的訪問。好比從IDC1進來的業務流量，數據庫的Master可能在IDC2，那麼它可能就會涉及到接入層到IDC2 Master這種跨機房的流量訪問。

除了生產的三個副本，咱們在上海的跨城容災還會有兩個副本：一個Master、一個Slave。跨城容災和生產IDC的數據同步因爲網絡時延的緣由是異步的，沒有作強同步。

這種架構帶來的好處是能夠實現同城IDC級別的容災。也就是同城的生產IDC，掛掉任何一個IDC，好比某一個機房斷電了，整個機房失聯了，那我也能夠保證業務的快速恢復，由於個人數據庫也能夠自動切換到其它兩個IDC。

你們可能會有一個疑問：同城的一主兩備是分佈在三個機房之間的，機房和機房之間可能會有延遲，咱們是控制在兩毫秒內，但對性能會不會有什麼影響？首先咱們在基礎設施方面，在機房建設上會設定一些原則，剛纔也提到同城IDC的距離控制在50千米以內，IDC之間會創建多條專線，保證帶寬和穩定性。咱們如今所有都是萬兆網絡的基礎設施，這是硬件層面的保證。另外軟件層面是針對TDSQL，TDSQL自己對於這種主備之間的強同步機制作了一些異步化和批量化的性能優化，來保證跨機房強同步的性能損失儘可能控制在10%之內。

通過咱們實測的效果，同城同機房、同城跨機房強同步帶來的性能損失可能只在10%之內，對於咱們業務層面來講是能夠接受的。

接下看TDSQL的運維管理體系。

TDSQL配套的運維管理平臺也叫赤兔平臺，負責實現TDSQL的監控以及運維功能。能夠監控全部的TDSQL實例的多項指標，包括各類指標、慢查詢、IO、CPU等；大部分的運維操做也集成在平臺上，好比主備切換、遷移、擴容、節點替換，能夠實現較高度的自動化運維功能。

另外一個TDSQL比較重要的運維組件叫CLOUD DBA。它是一個智能化的故障定位模塊，能夠取代DBA的一部分工做，好比分析SQL性能、給出索引建議，故障緣由自動分析定位等。CLOUD DBA會主動從TDSQL的實例上採集各類耗能指標、慢查詢SQL以及執行計劃，最終生成健康報告，以及優化建議。

CLOUD DBA的界面，左上的圖是打分的功能，它天天能夠定時給某一個實例作全面檢查，最終打分生成健康報告，爲你指出實例可能有哪些缺陷和風險。好比對某一個SQL的檢查和優化，能夠分析出可能缺失哪些索引，提出增長的優化建議。

下方是實時診斷的界面，它能夠實時診斷當前這個實例正在運行的狀態，好比有沒有失鎖、鎖等待、異常的新增指標，這些工具對於咱們平常的運維有很大的幫助做用。

如今微衆銀行整個TDSQL數據庫的規模，全網大概有400多個SET、2000多個實例，整個數據量達到PB級，承載了數百個銀行的核心繫統，金融交易量目前應該已經到6億左右，最高的TPS峯值10萬+以上。

4、將來的架構演進方向

最後分享一下微衆銀行數據庫將來的演進方向，總體有三個演進方向。

第一個方向是咱們正在作的：推動硬件國產化。如今咱們大部分的硬件都仍是基於X86平臺的英特爾CPU架構去作的。從去年開始，在嘗試把底層的服務器硬件平臺遷移到國產的ARM平臺上。咱們目前用的是華爲鯤鵬的CPU架構，去年在某一個業務上已經實現了從硬件層到中間件、到數據庫全鏈路運行在華爲鯤鵬ARM服務器平臺之上，今年可能也會繼續推進加大規模往國產的ARM平臺上遷移。

第二個方向，是雲原生。目前整個TDSQL仍是基於物理機和虛擬機這兩種資源模式部署的，這種部署模式會帶來一些問題，好比資源管理成本比較高、資源交付效率比較低，由於物理機涉及到上架、初始化，各類資源的流程分配比較麻煩，整個資源的隔離效果也會比較差，資源利用率也會比較低，因此咱們今年計劃要作的是會把TDSQL也慢慢往K8S+Docker這種容器化的架構上遷移，這樣能夠提高資源交付的利用率、效率。K8S+Docker的架構在無狀態的應用裏是比較成熟的，由於無狀態的場景較簡單，可是在數據庫這種有狀態的應用裏帶來的問題和複雜性會多不少，因此咱們也會謹慎嘗試。

第三個方向，是智能化預警和運維。對於DBA來講，很頭痛的問題是不少時候是問題發生了再去解決、定位它，但這時候已經對業務和交易產生了影響，比較被動。因此咱們一直在作的是但願能經過一些智能化的方式提早把這種風險和故障發現並預警，提早解決，這也是咱們如今的痛點。

舉兩個例子，一個是咱們已經上線的基於深度學習的智能故障預測告警。咱們會把數據庫的性能指標，好比IO使用率、CPU使用率、慢查詢的SQL數量等所有彙總到深度學習的平臺上，而基於這個深度學習平臺去作曲線的合理預測。

當咱們發現某一個實例的某些性能指標不在預期範圍內，就會提早把它預警出來。從實際的應用狀況來看，這仍是很是有效的，能夠提早發現一些潛在的風險。

第二個咱們正在作的是一個基於數據庫日誌和ES的日誌分析系統。咱們會把整個TDSQL全部的日誌，包括中間件、監控、調度的日誌，所有入庫到ES庫裏，再作一些SQL的耗時統計、SQ執行計劃的分析，基於這些分析把一些可能它如今尚未產生，但可能產生風險、威脅的SQL提早挖掘出來，讓業務去優化。

講師簡介

胡盼盼

微衆銀行數據庫平臺室室經理、騰訊雲TVP。碩士畢業於華中科技大學，畢業後加入騰訊，任高級工程師，從事分佈式存儲與雲數據庫相關的研發與運營工做；2014年在微衆銀行籌辦之時，就加入了微衆銀行基礎架構團隊，親歷和見證了微衆銀行分佈式核心架構從無到有的建設與發展，也參與了微衆銀行基礎架構1.0到基礎架構2.0的重大演進。目前全面負責微衆銀行數據庫平臺的建設和運營，包括關係數據庫平臺和KV數據庫平臺。