[[319472]]

分布式架構可能是近幾年最火的話題。從集中式、SOA到分布式架構，本文回顧了這些年金融行業經歷的架構演變;結合當下一些較典型的分布式數據庫的實現原理，分析了分布式數據庫的三個發展階段。分布式數據庫的應用解決了傳統數據庫性能擴展問題的同時，也給運維人員帶來了挑戰。那么，分布式數據庫的管理究竟多了些什么?如何管理好?未來數據庫和數據庫運維又將去往何方?讀過本文，你可以找到答案。

 

一、金融行業這些年經歷了怎樣的架構演變?

1. 集中式架構

分布式架構可能是近幾年最火的話題，與之相對的則是集中式架構，后者是傳統金融行業如銀行最常見的部署架構。在“去IOE”之前，各大銀行的目標還停留在將集中式單點做強做大，不少銀行采用IBM的主機系統就是鮮明的例子。數據庫服務器更是如此，通常都是采用最好的機器。

近幾年，隨著銀行業務增長，互聯網行業爆發，用戶行為模式發生變化，集中式架構的系統面臨很大的挑戰。問題主要體現在擴展性和可用性這兩方面：

1. 擴展性

集中式架構的橫向水平擴展能力非常低。面對性能不足，用戶能做的就是加CPU、加內存、換存儲、換機器等方式。

2. 可用性

集中式架構的服務能力依賴高性能的主機。然而一旦主機出現故障，上面的服務就會受到影響。應對這個問題的方案就是搭建高可用架構。每一個環節都需要考慮冗余和HA。集中式架構下這幾乎是最好的方式了。然而無論哪個環節出故障，影響的都是全局服務。

這種架構下的數據庫也是通過做主備機冗余，HA服務自動管理切換滿足高可用性。性能方面通常也是采用縱向擴容的方式。然而縱向擴容是有限制的。如果最強的主機都搞不定了怎么辦?

 

 

 

 

圖 1. 集中式架構

在集中式架構的數據庫里面有一個例外，那就是MPP數據庫。為了解決單節點數據庫性能上限問題，某些數據庫廠商開發出來MPP數據庫。這種數據庫算是一套集群，數據分布在這些集群的節點上，數據查詢服務也能下推到這些節點完成。通過數據分發和功能分發，充分利用多節點的處理能力，這簡直就是現在的分布式先驅。

 

 

 

 

圖 2. 集中式MPP架構

圖中協調節點CN并非是一個特殊組件，這可以是任何一個DN。不過這類產品是面向OLAP的，是為了解決大查詢問題，和現在分布式的方向并不一樣。

2. 面向服務的架構(SOA)

在互聯網浪潮還沒到來，分布式架構還未興起的時候，為了解決單機性能瓶頸和全局服務可用性問題，最初的方案是業務拆分，也就是面向服務的架構(SOA)開始應用起來。純粹的SOA其實是一個組件模型，它將應用程序的不同功能單元(稱為服務)進行拆分，并通過這些服務之間定義良好的接口和協議聯系起來。SOA架構曾經流行了一段時間，當然現在更火的是微服務模式。

 

 

 

 

圖 3. SOA架構

當時有很多銀行將自己的核心系統依照這個思路拆分，一個大系統拆成多個小系統或者是組件。優點是服務拆分之后實現了部分性能擴展。之所以說是部分，是因為總有些核心服務是熱點，沒有辦法做到拆分的。隨之帶來的缺點是系統調用鏈復雜程度增加了，數據在不同服務間的同步要求變多變復雜，然后系統和服務器的數量增多了。即便是采用了SOA的思路，還是沒有徹底解決熱點功能的性能問題和可用性問題：

1. 沒有實現核心功能的水平擴展，單個功能還是屬于集中式架構部署。

2. 沒有實現數據水平拆分，解決不了大數據量的問題，反而帶來了不同系統數據同步的復雜需求。

3. 分布式架構

就在金融行業還在忙著為系統功能拆分改造，給新的小機打預算的同時，中國的互聯網科技行業正在發生大的變革。

大數據技術發展：第一大變革是各種分布式開源軟件走向成熟并被充分利用。分布式存儲、分布式計算、分布式消息中間件引領大數據行業變革。這些分布式技術簡單粗暴的解決了大數據量、高吞吐量和高可用性的難題。這些難題對業務系統和后臺的數據庫同樣存在。看起來數據庫走向分布式才是終極解決方案。然數據庫行業的領先者們并沒有像擁抱云技術那樣去擁抱分布式數據庫，反而給了眾多初創數據庫企業機會。

互聯網消費行為：另外一大變革是互聯網行業改變了用戶的消費行為。這幾年網絡運營商在提速降費，互聯網移動設備出貨量飆升，用戶的消費習慣也大量從線下轉移到線上。中國的人口紅利在互聯網產業發揮的淋漓盡致。對于金融行業來說，用戶消費行為的變化帶來的是對金融科技的挑戰。交易量和數據量都在不停攀升高峰。尤其是網銀，手機銀行等渠道類業務都將面臨集中式架構性能瓶頸問題。

其中最典型的就是阿里。阿里從2011年開始基于成本因素的考慮逐步去IOE，同時年年祭出了雙十一成績單。高帥富的小機替換成了PC機，Oracle數據庫換成了開源MySQL數據庫，同時自研分布式中間件TDDL實現橫向擴展。阿里通過堆砌廉價的PC機來支撐龐大的雙十一促銷業務，最終交出了交易量、峰值、金額等漂亮的成績單。現在阿里的分布式中間件發展成了關系型數據庫 DRDS。同時阿里還有面向金融領域全自研內核的OceanBase，主打云數據庫存儲計算分離架構的PolarDB。

技術自主可控：這幾年國際關系大環境也在發生變化，國內尋求自主可控的聲音越來越響。相應的國內也涌現出了很多主打數據庫產品和服務的企業。尤其是分布式數據庫技術，在國際數據庫領頭羊們還沒有全力投入拿出作品的時候，國內很多企業借鑒開源分布式技術方案，研發出了自己的分布式數據庫。因為沒有作業可抄，所以大家做的作業也很不一樣。

綜上所述，內有金融行業對于大數據量、高吞吐量和高可用性的迫切需求以及自主可控的需求，外有大數據分布式技術方案得到肯定，再加上互聯網行業解決方案引領，金融行業對國內優秀的分布式數據庫的需求持續走強。

二、分布式數據庫經歷了哪幾個發展階段?

分布式數據庫是為了解決大數據量、高吞吐量和高可用性的問題，通過數據和計算分片的方式提供橫向擴展能力。然而思路很明確，實現很復雜。為了更清楚當前一些分布式數據庫的實現原理，我們首先將要數據庫分為三層來看待：解析層，計算層，存儲層。而分布式的實現就是在解決這幾層的實現問題。我把分布式數據庫的發展分為三個階段。

1. 讀寫分離

為了解決集中式架構下的單節點計算性能問題，首先出現的方案是讀寫分離模式。當時MySQL開源數據庫比較流行。然而MySQL單節點的處理性能很容易遇到瓶頸。MySQL主從復制的架構下，主庫可讀寫，然而備庫建議只讀。因此如果SQL解析層能夠做到讀寫分離，那么主庫的壓力將會大大降低。

 

 

 

 

圖 4. 讀寫分離架構

這種架構曾經流行一段時間，這個階段MySQL發展勢頭也很迅猛，開始挑戰商業數據庫的地位。商業數據庫的用戶也向IBM和Oracle等提出了相關的需求。這種架構下每個數據節點的數據是全量的。客戶端或者是數據庫中間件需要解決SQL的讀寫分發問題：如何保證數據一致性，如何設計SQL的隔離級別，如何解決鎖問題等等。

• 解析層

解析層需要實現讀寫分發。

• 計算層

實現了從庫接受讀交易，一定程度分散了壓力。

• 存儲層

單節點是全量數據。數據同步通過數據庫的主從復制技術實現。

如果存儲計算分離，然后實現分布式存儲。那么這種架構又可以進一步解決存儲層的壓力問題。現在最典型的是阿里云的polardb。

 

 

 

 

圖 5. 阿里云polardb分布式存儲

阿里云的polardb實現遠遠比簡單的讀寫分離要豐富的多。首先這是個面向云的原生數據庫，是屬于軟硬一體的解決方案。

• 解析層

實現讀寫分離和負載均衡。

• 計算層

縱向擴展單節點性能，橫向擴展讀性能。

• 存儲層

分布式存儲，分片方式對應用透明。通過FPGA，RDMA等硬件技術加速性能。

個人認為云數據庫是未來的趨勢，阿里polardb和騰訊tdsql會大放異彩。

2. 分布式中間件模式

讀寫分離還是不能滿足中國互聯網龐大的用戶體量。銀行有幾千萬上億的用戶，互聯網更多。但凡來個促銷活動，運維人員就心驚肉跳。僅僅靠讀寫分離其實不能滿足這種集中并發式的性能瓶頸。那么能不能將這些用戶的交易數據分開放在不同的節點上，讓這些用戶只在對應的節點處理數據呢?這就是現在分布式的主流思路：數據分片。

 

 

 

 

圖 6. 數據庫中間件

圖中的每個分片都可以是一套主從架構的數據庫，不僅僅是一個物理節點。

• 解析層

實現sql分發查詢以及結果匯聚。數據分片的定義需要在這一層保存。對于跨節點的分布式事務支持能力很單薄。這個主要看分布式中間件的產品能力。

• 計算層

通過底層數據的分片，計算層已經完全實現了負載分離。

• 存儲層

數據分片后，存儲層的性能問題也完美解決。

這種架構的典型代表是阿里最初的TDDL數據庫中間件產品和開源數據庫中間件Mycat。阿里的TDDL數據庫中間件已經演變成現在的DRDS集群。

首先我們來看看Mycat的解決方案。

 

 

 

 

圖 7. Mycat數據庫中間件

Mycat數據庫中間件架設在應用和底層數據庫之間。應用SQL會解析轉化并路由到底層多個數據庫主備集群里。這種方案不需要底層數據庫做任何改動。然而支持復雜SQL的能力有限。使用這種架構要避免分布式事務。

下面看看阿里云的DRDS解決方案。DRDS雖然是中間件模式，不過現在推出的解決方案更像是個完整的分布式集群數據庫。DRDS是分布式中間件，底層是RDS數據庫集群(mysql)。RDS數據庫服務是阿里云提供的關系型數據庫服務統稱，主要是MySQL。DRDS通過兩階段提交來實現分布式事務。

 

 

 

 

圖 8. 阿里云DRDS

如果存在分布式的事務，那么在這種架構下最好由應用層面去解決。這方面我覺得做的最好的是招商銀行。招行一開始就將分布式事務和分片的角色都放在業務應用開發層面，因此不需要依賴底層數據庫來實現分庫分表。

3. 分布式集群模式

中間件模式其實還是和數據庫引擎脫離的。分布式中間件如果將中間件和底層數據庫揉在一起，當做一個產品去開發使用，這就是現在的分布式集群數據庫。我觀察了國內各家廠商分布式數據庫的實現，基本濃縮成下面這張示意圖。

 

 

 

 

圖 9. 分布式數據庫集群

協調節點：這是分布式數據庫接受用戶請求和返回數據的處理節點，通常以多活的模式部署在多個物理節點上。協調節點之間的事務控制通過向全局管理節點請求，獲取全局事務信息或者鎖信息。協調節點的SQL會編譯執行，調取對應的數據節點。

數據節點：真正存放數據的地方。從協調節點導入的數據通過分片或者復制的方式存放在數據節點里面。數據節點通常只需要響應協調節點的調取。數據節點通過一主多備的模式提高數據可用性。備節點一般不提供讀取服務。

全局管理節點：分布式數據庫的核心，也是區別于分布式中間件方案的關鍵組件。全局管理節點用于全局事務控制、元數據管理等。這些需要全局控制的功能可能會被拆分成多個組件來部署，這也是不同分布式數據庫集群的根本差異。

集群管理節點：這是數據庫集群高可用性的保證。用于全局監控數據庫各項組件的狀態，并且依據狀態變化自動響應。集群管理節點控制著整個集群里組件的切換和維護。

上述邏輯節點可以在物理節點上混部署，加上數據中心的概念。集群可以跨多中心部署實現數據中心級的容災。國內現在比較突出分布式數據庫gaussT、TIDB、glodendb、sequoiadb、antdb等都是這類架構。下面看兩個典型的國產化數據案例，與大部分分布式數據庫的解決方案不一樣的是，他們的數據庫引擎不是基于MySQL。

第一個是華為的高斯數據庫gaussT。

 

 

 

 

圖 10. 華為gaussT數據庫

這是華為官方的高斯數據庫。其中ETCD和CM是集群管理器，用來選擇和操作整個集群。其中ETCD存放集群整體狀態信息，基于paxos協議保證可用性。CN是接受用戶請求的協調節點，負責數據和SQL的分發和匯總。CN多活，客戶端通過負載均衡模式連接CN。GTS是全局事務管理節點，僅處理事務號的請求并且有緩存機制，因此相對處理性能比較高。DN是數據節點，一主多備模式保證高可用。集群內部的表有兩種方式建立，一種是選好分布鍵的分片數據表，一種是全局同步復制的復制表。從高斯數據庫的架構來說，它是典型的傳統關系型數據庫的升華版：全面支持分布式事務，集群當做一個數據庫來用的方式對用戶友好。

說到分布式數據庫也要提到TIDB。TIDB是PingCAP公司推出的開源分布式數據庫。在一幫做分布式數據庫的廠家中，TIDB是個另類，另辟蹊徑主打先進的數據庫架構和良好的開源生態。

 

 

 

 

圖 11. TIDB數據庫

在TIDB的架構圖里，TiDB Cluster是接受請求的協調節點，用作SQL解析和轉發。TiKV是存放數據的數據節點。與其他分布式數據庫不同的是TIDB用的是分布式的KV存儲引擎。TIDB的數據分發也和其他分布式數據庫必須指定分區鍵分片規則不同，實現的是基于Region級別的raft復制，還可以根據負載情況進行合并和分裂。這個特點是其他分布式數據庫做不到的。PD Cluster相當于是全局事務管理器。集群管理器在圖中沒有標出來，其實里面的每個cluster都有相應的集群服務。

三種分布式方案已經介紹差不多了，最后來看看中興Goldendb吧。

 

 

 

 

圖 12. GoldenDB三種部署形態

中興Goldendb將這三種部署形態全部集成。No-Sharding就是單機部署一主多備模式，提供讀寫分離的負載方案。Sharding集群就是中間件部署模式，計算節點做轉發，不支持分布式事務。Distribute Transaction集群就是加了GTM全局事務管理器，支持分布式事務。

4. 分布式數據庫測試體會

介紹了這么多分布式數據庫架構，我們也測試了很多家的數據庫產品。這里談談銀行在測試分布式過程中的一些經驗：

1. 對于單點數據的增刪改查，大家的性能都很好，極限瓶頸一般出現在全局事務管理這個環節。因此這部分的性能差異就在于這個全局事務的處理問題上。這也決定了一個分布式數據庫的性能上限。

2. 對于分布式事務，需要跨節點數據訪問的，大家的性能都不怎么好。其實分布式事務對于分布式數據庫來說還是有很大挑戰的。對于使用分布式數據庫的業務，建議減少分布式事務，也不要把分布式數據庫當做混合負載來用。尤其是像不同分布鍵的大表關聯，搞垮協調節點是分分鐘的。這部分技術還是面向數倉的MPP數據庫比較合適。如果MPP數據庫的這部分能力被集成到分布式數據庫中，那這個分布式數據庫才真是厲害了，從容面對HTAP。

3. 使用分布式數據庫一定要關注分布鍵。無論是分片還是復制，業務開發人員需要從自己的業務邏輯開發，合理設置。一旦選不好，分布式數據庫還不如單節點性能。

4. 分布式數據庫數據重分布，也就是橫向擴展，都是痛點。無論是操作方式還是性能影響，基本上所有的分布式數據庫都成問題。可能使用自動分布可擴展的存儲引擎才是最終解決方案。

5. 分布式數據庫集群組件眾多，相對來說管理比較復雜。每個組件都有自己的日志，都可能有性能瓶頸。在分布式數據庫環境下運維管理成本比較高。

三、傳統數據庫運維崗面臨哪些挑戰?

分布式數據庫的應用解決了傳統數據庫性能擴展問題的同時，也給運維人員帶來了挑戰。以前一套標準就可以運維好傳統數據庫，定好參數規則，做好應急防護即可。現在多了分布式數據庫，并不只是多了個數據庫產品那么簡單，而是多了種數據庫的使用方式。

1. 分布式數據庫管理多了什么?

統一數據視圖：分布式數據庫數據做了分片之后，運維人員需要解決數據透視的問題。哪些表是分片表，哪些表是復制表?如果需要導出或者同步數據到其他系統，這個方案該怎么做?一張表被分成了多少份，整體的數據量是多少?如果選擇了分布式數據庫成熟產品還好，這些部分有產品級的解決方案。中間件型的分布式就更難了。對于用戶來說，如果還能將集群里的數據當做一個數據庫來操作是最理想的。

大量節點管理：選擇分布式，就是選擇橫向擴展。相應的運維節點數量會出現爆發式增長。這個運維力量一下子就上去了。還好需要上分布式的系統不會太多。現在這些節點不僅都需要單獨監控管理，還需要管理好節點的角色。

容量管理：這里的容量管理包含性能和數據兩個方面。在分布式環境下一定要關注負載分布問題。因為從根本上來說分布式就是為了解決性能負載而誕生的。運維人員需要檢測到負載是否均衡，是否符合預期，如果有問題，需要從數據分布和業務行為的角度一起去分析。這相對是比較復雜和困難的。另一方面，分布式數據庫里面最怕出現數據傾斜問題。嚴重的數據傾斜會導致性能瓶頸和容量瓶頸。出現傾斜后如何數據重分布也是很難的問題。

數據一致性：分布式數據庫的數據一致性可能會被用戶忽略。因為在集中式數據庫中很少會出現這種問題。然而分布式數據庫的分布式事務基本都是通過兩階段提交的方式來實現。出現問題的情況下可能會出現提交殘留。因此用戶需要定時檢查數據庫是否存在兩階段提交殘留，定時比對數據。

變更管理：分布式環境下的變更問題也需要重視。節點變多了，數據庫拆散了，變更也就存在全局和單點的維度。如何統一變更保證集群所有機器都完成而沒有遺漏?是不是所有的節點都變更了?能不能通過定時參數比對等方式提示參數不一樣的節點?

容災方案：分布式數據庫的災備方案該怎么做?兩地三中心采用什么方式實現?異構數據庫的數據同步方案有哪些?數據遷移方案呢?這些在單節點數據庫的情況下有很多成熟并久經考驗的方案可以使用。然而在分布式環境下，現在只能說是陪著廠商一起成長。

多租戶管理：多租戶管理是分布式數據庫環境需要解決的重要功能。運維人員需要把相應的產品方案用起來，并且在運維的過程中關注租戶的容量和性能需求，并相應調整數據庫。

2. 如何管理好分布式數據庫

分布式數據庫作為新的技術，并不是脫胎于成熟的商業數據庫，因此還有很多粗糙的地方。尤其是金融行業的用戶，被傳統商業數據庫“嬌生慣養”，首次接觸到新生數據庫的時候，會有四處碰壁的感覺。但是即便是硬骨頭，還是得啃。

控制應用場景：

分布式不是萬能的，它是面向特殊場景的數據庫產品。只有符合的交易才能往上遷移。如果不想自己麻煩，那就別麻煩分布式數據庫了。這個要求運維人員不僅僅在看產品，還需要與業務人員和開發人員緊密合作。要從業務分片的角度去管理數據庫。因此使用分布式數據庫必須定義一個使用場景規范。

統一管理平臺：

分布式數據庫的數據分片后，運維人員需要了解數據的整體規劃是什么樣子的，數據分片規則，復制方案，同步方案等。使用分布式數據庫集群的用戶可能要輕松一些，因為這些產品可能有相應的產品級解決方案。而采用了分布式中間件的用戶，如何還能隨時查詢和透視數據表的關系，這是需要另尋方案的。不管是何種方式，這些都是分布式數據庫運維需要做好的事情。

所以運維人員需要建立一套數據管理平臺。在平臺里查看和操作分布式數據庫集群狀態，管理數據庫用戶、權限、分布規則、配置下發、配置比對、查看日志、分析等各類管理功能。最好也包含多租戶管理。

智能監控平臺：

引進分布式數據庫之后，運維人員需要監控分布式數據庫節點狀態和各個節點的性能。首先要解決的問題是將新數據庫接入到監控告警平臺。原先適用于單機數據庫的各項監控需要針對集群數據庫適配一遍。然后更進一步，運維人員還需要借助智能運維來實現分布式數據庫的精細化監控。智能監控平臺需要分析發現分布式數據庫負載不均衡，節點行為離群等問題，然后智能化展示故障影響鏈條。智能監控平臺還能夠做性能容量趨勢分析和預測，提前警示性能容量告警。

容量管理：

這個主題單獨列出來，確實是因為這個主題太重要了。一定要有辦法能夠監控數據傾斜問題和負載傾斜問題，并且在管理平臺里需要做好負載重分布和數據重分布功能。分布式數據庫支持的數據分片方式一般有三種：hash、range和list。如果發生了數據傾斜問題，運維人員需要查看傾斜原因，并采用這現有的幾種方式嘗試繼續打散數據。因此在容量管理這方面，運維人員需要與業務及開發人員緊密溝通，了解數據的業務信息，獲取業務增長預期，這樣才能做好性能和容量規劃。

變更發布：

數據庫的參數變更可以通過統一管理平臺來實現。但是如果管理平臺沒有集成的功能，變更內容也一定需要借助自動化發布平臺來做。尤其是存在多數據中心容災的情況下，人為變更是很容易遺漏的。最好是上線DevOps平臺，將分布式數據庫的變更也集成在平臺里。

通過建立這些管理平臺和工具，將數據庫運維人員從忙于解決各種問題的窘境中釋放出來，成長為數據架構師。DBA向前與業務場景對接，向后挑選合適的數據庫技術，基于標準化自動化的部署維護方式，為業務穩定運行保駕護航。

四、未來，數據庫和數據庫運維將去往何方?

我們正處在一個數據庫技術大爆炸的時代。這幾年NoSQL數據庫、NewSQL數據庫、時序數據庫、圖數據庫、分布式數據庫、超融合數據庫相關的技術百花齊放，國產數據庫也強勢發展起來。那么下一代主流數據庫是什么樣子呢?未來的運維模式又將發生什么變化?

云數據庫：系統上云已經成為這幾年的熱點。大廠也紛紛推出自己的云數據庫。未來云數據庫將會成為趨勢。數據庫服務將進一步標準化輸出。無論是私有云還是公有云，用戶的數據庫使用方式正在發生變化。而分布式數據庫和超融合數據庫的強勁性能，也適合在云環境提供多租戶使用。

細分領域：數據庫應用領域也會越來越細分。可能現在我們還是希望有能夠面向HTAP場景的全能數據庫，但是未來數據庫功能將更加分化。尤其是通過數據庫云可以輕易申請到主打不同功能的數據庫來解決各類業務場景。

智能運維：隨著數據庫提供云部署云服務，數據庫運維一定需要走向智能運維。通過機器學習智能算法來監控系統運行狀態，依據數據表現提供決策、自動修復、自動擴容。

最后想象一個場景，用戶申請了云數據庫，運行一段時間后，智能運維機器人告訴用戶數據庫最近發生了什么事情，一共發生了幾次自動調優，幾次自動修復異常等，共節省了多少時間損失。還會基于用戶的使用場景，建議用戶擴容或者是購買更適合的數據庫服務，將有助于提高性能多少百分比等。

以上是筆者認為在不久的將來即將發生的變化，你有什么看法?

【作者】孔再華，IBM認證高級DBA，SAP認證BASIS，具有豐富的數據庫環境問題診斷和性能調優的經驗。在數據庫同城雙活，集群，多分區，分布式等項目實施上具有豐富的經驗。現任職于中國民生銀行科技部，工作致力于數據庫同城雙活架構建設，數據庫分布式架構建設和數據庫智能運維(AIOps)方向。對于如何將AI技術運用在運維領域具有濃厚的興趣和創新熱情。