文/神州信息金融科技分布式架構專家 薛春雨

提及2020年金融科技熱詞，“分布式轉型”實屬其一。金融行業迫切需要分布式技術，以應對業務轉變，滿足發展需求。而金融行業在進行分布式轉型時，除了要關注應用層的分布式（以微服務的形式體現）外，數據層的分布式也是重要的組成部分，本文將把目光聚焦到數據的分布式。

分布式的核心理念是把大的拆分為小的，然后用多個物理節點去承載，但所有的加在一起在邏輯上還是完整的一份。具體到數據層面也是一樣，但具體的數據拆分又分為“垂直切分”和“水平切分”兩種大的類型，所謂的垂直切分更多的是將不同業務功能所使用的“表”拆分到不同的數據庫中，一般更多的是跟微服務配合起來使用，如下圖所示：

圖1 數據垂直切分

而水平切分則是把“表中的數據”按照一定的策略進行拆分，所以其主要是解決表數據量大的問題，如下圖所示：

圖2 數據水平切分

本文的數據分布式是針對“數據水平切分”的方式來談的。

數據分布式的發端與嘗試

追溯數據分布式的最早使用，就不得不提當年建行的南北中心，當時建行把全國的數據分為南北兩個中心，然后每個中心的業務系統只訪問各自中心的數據，如果出現跨南北中心的轉賬的話，就在行里模擬銀聯轉賬的方式通過消息隊列進行處理。但從數據的視角來看，其已經是將全行的數據按地域的維度拆分為兩部分，所以說，其應該算是數據分布式的最早應用。

2014年，國內第一家民營銀行——微眾銀行正式成立，由于其主要處理互聯網線上業務，并且有騰訊的引流，所以其必然要面對大數據量的挑戰，所以在系統建設的時候，微眾銀行采用了單元化的設計理念，將行內所有數據按客戶號拆分為多份，每一份用獨立的數據庫承載，并且每個分庫的數據只能被固定的應用所訪問，如下圖所示，其中上述的固定應用+具體的分庫組成一個DCN，也就是一個單元體。在這種架構體系下，所有的服務請求進來后，都首先訪問“GNS”，由其告知該到哪個DCN中執行，所以“GNS”在整體架構中的位置就非常重要，對其的穩定性、可靠性、性能，以及映射關系有變化后的數據一致性等，都提出了很高的要求。

圖3 數據分布式的單元體模式體現

由于各個單元體完全隔離，涉及到多個單元體的交易的邏輯處理就會變得更復雜。例如最常用的“轉賬”的處理邏輯基本如下：

圖4 單元體模式下的轉賬流程示意圖

上圖中紅色相關字體描述部分都是跟該架構有著密切的關系。在金融業務場景中還有一類業務，就是其交易訪問中是不帶客戶號的，例如，查詢一個月內的新開賬戶，由于其不帶客戶號，也就無法通過GNS把請求下發到具體的DCN，并且這種業務所查詢的數據，一般都是覆蓋所有分庫的。所以，微眾銀行的處理思路是：把這種業務當做分析統計類的業務，通過把所有分庫的數據歸集在一起，針對這種業務就直接查詢“歸集庫”（見圖3中的灰色部分）。據了解，微眾銀行已經逐漸將這里的“歸集庫”用TiDB數據庫進行替換。

這種“單元化”的思路，更像是一個全行級的架構，究其根本，其實是數據分布式的一種解決方案，只是在整體架構級來解決的。但架構只負責數據的拆分及提供路由支持（通過GNS體現），其他的問題全部交由業務或者系統架構來處理（“歸集庫”就是一個體現），所以才會造成了業務實現和系統架構都會比較復雜。但不可否認的是微眾銀行確實是國內在數據分布式領域的第一次大規模的應用，雖然我們現在來看這個架構還是有一些值得商榷的地方，但在2015年，行業內分布式才剛剛起步的時候，這種設計理念已經是朝分布式方向的一次大膽嘗試，也間接推動了國內金融行業分布式的發展，是數據分布式領域一個重要的里程碑。

數據分布式的落地探索

在數據分布式的探索過程中，各種解決方案百花齊放。其中，比較主流的實現方式有如下幾種：

1、分布式數據訪問組件

“單元化”是從整體架構的視角解決問題的，但同樣的是進行“數據水平切分”，另一種典型思路是在應用架構內部解決。傳統的系統實現基本都是應用直接訪問數據庫，這種方案的初期，業務開發人員一方面要實現業務邏輯，同時還要考慮應該訪問哪個具體的分庫，所以代碼非常復雜，對人員的能力要求也比較高。因此，思路調整成將 “數據的分布式存儲及訪問”的功能從業務代碼中剝離出來，實現對業務代碼的低侵入甚至無侵入?！胺植际綌祿L問組件”在這樣的背景下逐步發展，隨著這種模式的不斷發展，其功能不僅可以保證最典型的包含分片鍵的SQL的處理，逐漸對不包含分片鍵的比較復雜的SQL的支持度也越來越高，當然對業務的侵入度也越來越小。這種模式下數據的訪問模式基本如下圖，其中深藍色部分就是“分布式數據訪問組件”位置：

圖5 分布式數據訪問組件模式

“組件”模式可以簡單理解為是對傳統的數據訪問組件進行升級，以實現數據分布式的訪問的能力，但其實內部的復雜度也比較高，對業務系統訪問數據庫的整體鏈路沒有產生影響，也沒有增加額外的網絡開銷，并且對原有的數據庫DBA資源及運維體系也基本沒有影響，所以算是一種非常輕量、高效的實現方式。

2、分布式數據訪問中間件

為了減少對業務邏輯的侵入，逐漸形成了“分布式數據訪問組件”的模式，但由于其嵌入在業務系統內部，所以，在運行期間仍需要占用應用的運行資源，對一些比較復雜SQL的處理還是受一定的限制，因此中間件的模式逐漸衍生，把“分布式數據訪問組件”實現的功能從應用系統中剝離出來，獨立部署。這種模式看似簡單，但獨立出來后就需要考慮應用跟中間件的通訊（包含以什么協議，對業務幾乎沒影響），并且內部對復雜SQL的處理復雜度非常高?；谠撃Ｊ酱笾碌倪\行機制如下：

圖6 分布式數據中間件模式

“中間件”模式最大的優點就是在應用系統之外，可以獨立多節點部署，可以被多個應用系統使用，并且由于其運行資源獨立還可以進行比較復雜的SQL處理，理論上比“組件”模式SQL的支持度要高。但同樣由于是獨立部署，在調用鏈路中就增加了一來回網絡交互，按基本的網絡情況來計算，需要0.5ms的額外開銷，雖然只有0.5ms的消耗，但一般一個命中索引的信息查詢，也基本上就是0.5~1ms，所以，如果從單個SQL的總耗時來看，基本要翻倍。用銀行的活期存入來說，相同SQL數量的前提下，假如之前的單筆響應時間是40ms，如果按照中間件模式的話，基本就要到70~80ms了。雖然分布式強調的是在大數據量的基礎上整體處理能力的提升，但具體到單筆交易的響應時間如果影響太大，一般客戶還是不太容易接受的。

3、基于MySQL的分布式數據庫

中間件模式，理論上后端使用的數據庫可以是各種常用的數據庫，但一般更多的是跟MySQL進行對接，“分布式數據中間件”跟“MySQL數據庫”整合在一起的方案應運而生，使之變成一個分布式數據庫的產品獨立銷售，其不僅具備“分布式數據中間件”的能力，同時還提供完整的MySQL數據庫的集群管理能力，以及配套的各種完備的工具，同時由于跟MySQL數據庫緊密整合，在一些功能的實現機制上，可以跟MySQL進行比較深的定制，這也是其相對通用的中間件模式的一個優勢。但是整體來看，其在本質上跟中間件模式并沒有太大區別。具體如下：

圖7 基于MySQL的分布式數據庫模式

這種模式最大的優勢就在于其以一個完整的數據庫對外提供服務，尤其是相對中間件模式+MySQL數據庫的方式，該模式不僅提供了數據分布式的能力，而且還提供了比較專業的MySQL的集群及運維管理能力。但這種模式跟中間件模式一樣都要面對至少一來回（跟不同的廠商的實現機制有關）的額外網絡開銷，在SQL支持度方面理論上兩種無太大差異。

4、基于全新數據庫理論體系的NewSQL數據庫

前面提到的各種方式都有一個前提條件，就是基于現有成熟的關系型數據庫。但這種模式完全是一個原生的分布式實現，其將分布式的理念直接應用到數據庫內部的計算及存儲機制上，使其天生就具備分布式的基因。下圖是TiDB的架構，可以看出在實現機制上其跟傳統的數據庫有著非常大的區別。

圖8 TiDB的整體架構

基于這種模式，應用系統可以完全把其當做一個數據庫來看待，但其內部同樣需要進行分布式數據的計算，以及分布式數據的存儲等。具體如下圖：

圖9 基于NewSQL數據庫的模式

基于全新數據庫理論體系的NewSQL數據庫模式無疑是最先進的模式，由于其采用全新的設計理念，但讓使用者又可以按照之前傳統的方式來使用，所以，在一些細節層面跟傳統模式還是有一定差異的，所以在使用的過程中還是需要深入理解，否則在使用的時候還會出現一些問題。另外，這種模式畢竟是一種新生事物，所以其發展還是需要時間來不斷完善，至少在現階段對金融行業的支持仍有不少需要繼續提升的地方，但這也符合事物發展的規律。還有一點就是這種原生的分布式實現，其實是有一個潛在的前提，就是對網絡以及磁盤的存儲等方面要求都是比較高的，但是隨著硬件領域的快速發展，這些問題遲早都會被低成本的解決掉。其實，影響這種模式落地還有一個方面，就是其畢竟是新的事務，銀行如果要使用的話，就必須有對應的DBA資源，以及比較成熟的、完備的運維管理體系。比較慶幸的是，相關數據庫廠商也在積極推進相關生態圈及知識體系的建設工作。

如何選擇數據分布式的實現方式

以上多種數據分布式的實現方式，主要差別是實現的位置不同，“單元化”模式是在整體架構的入口實現的，“組件”模式是在應用架構中實現的，“中間件”模式是在應用和數據庫之間實現的，后面兩種都是直接在數據庫層面實現的。但不管是在哪個層級實現，大部分的思路都是把數據分布式的問題集中解決，對業務系統盡可能透明，在SQL支持度方面盡可能跟直接訪問傳統的關系型數據庫保持一致。但是分布式的設計理念注定了其解決的主要矛盾是大數據量的關系型數據的問題，所以相對傳統的關系型數據庫，其有些SQL在分布式體系下實現的難度還是比較高的，這跟在哪層實現沒有必然關系，即使是在數據庫層面實現的，同樣對跨多個物理節點的數據表的關聯查詢、排序等都是非常消耗資源的。所以，在分布式體系下一定是有取舍的，在使用該項技術時在思想層面也需要與時俱進，大的原則一定是揚長避短。

另外，還需要根據業務場景進行結合，而不是坐而論道要求其100%的完美。就拿銀行核心系統為例，一般比較大的表也就是客戶、賬戶、交易流水等相關的表，所以，只需要將涉及這些表的交易進行梳理，然后對常用的重要的交易按照分布式理念進行重新設計即可，通常情況下對這幾個表的操作，主要就是存款、取款、轉賬，以及客戶、賬戶信息、交易流水查詢等，這些交易幾乎占到了這幾個表所有交易的90%甚至更多。但這些交易基本都是具體到某個客戶或者賬戶的，所以，即使是輕量級的“分布式數據訪問組件”模式都可以又快又好的支持這種場景。就跟我們買一些其他產品一樣，要求他的功能非常豐富，但買回來后發現用到的只有不到10%的功能。

未來，數據分布式何去何從？上面談到多種模式，其實沒有絕對的孰好孰劣，但從長遠的發展趨勢來看，NewSQL的模式一定是未來的方向，并且目前NewSQL還在往HTAP發展，其可以同時支持OLTP和OLAP的交易，對相關行業系統建設的整體架構也會帶來比較大的改變。另外，其不僅是原生的分布式，也是云原生的重要組成部分，跟整個行業的發展方向也是一致的，但在當下，其還有不少功能需要不斷完善，尤其是對金融場景的支持方面。另外，對于“組件”模式，由于其嵌入在應用內部輕量化的實現，并且性能最高，對SQL的支持度也基本滿足常用的需求，所以在一些單個系統的建設方面也是非常方便的，其不需要單獨采購一個分布式數據庫，甚至整個數據庫運維體系都需要整體升級。所以，筆者比較看好這兩種模式，并且認為即使NewSQL逐漸成熟了，“組件”模式也會長期存在。

責任編輯：Rachel