跨越數據庫發展鴻溝，談分佈式數據庫技術趨勢

1. 金融行業架構轉型需求

隨着移動化與互聯網化的不斷髮展，我國金融行業的商業模式與技術體系已經逐漸走上了與西方世界徹底不一樣的道路。衆所周知，歐美國家的移動化普及率遠遠不如我國，同時人口基數也有着數量級的不一樣，這就使得國內外金融行業所面臨的業務類型、數據量、併發量都存在巨大的差別，致使對整個IT基礎設施的需求大相徑庭。

在最近的一兩年中，國內部分科技領先的銀行已經率先對微服務與分佈式技術進行了探索，一些新建的互聯網金融類業務也已經開始嘗試使用微服務架構、分佈式技術、DevOps框架進行應用的開發與維護。甚至一些銀行在規劃下一代核心體系架構時，也會嘗試適當引入分佈式架構，以知足將來業務壓力與數據量不斷增加的需求。

與新一代分佈式架構相比，中間件加數據庫的傳統「煙囪式」架構在面向海量數據、高併發、高響應速度的業務應用時存在諸多問題。

• 從業務部門和系統來看，複雜的業務致使企業中系統數量多、分散、數據之間徹底隔離沒法共享；
• 系統缺少靈活的水平伸縮能力，性能瓶頸明顯，很容易遇到硬件瓶頸，沒法知足彈性擴張的業務需求
• 系統沒法快速響應順勢爆發的海量請求，例如雙十一期間、秒殺等業務致使的瞬時爆發性增加很難處理；
• 採購和運維成本高昂，小型機設備與軟硬件分別採購獨立運維，致使總體擁有成本高昂；
• 缺少自主掌控能力，高度依賴國外的廠商，出了嚴重問題本地支持團隊很難在短期內解決問題，致使生產運營風險增長。

1. 銀行架構演進歷程

在過去的近二十年間，我國銀行的IT架構歷經了幾個階段的變化。我國的第一代銀行核心系統構建在大型機之上，採用的是典型的大集中架構。而隨着SOA概念的提出，一些銀行也開始逐漸進行了去大機化，將核心業務系統從主機或400下移到UNIX小型機。虛擬化技術的加強使得一些銀行和金融機構在其基礎架構中引入虛擬化機制，將開發環境以及一些生產環境的應用程序部署在虛擬機上。

現在，不少銀行都已經基於分佈式與PC服務器架構建設了大數據平臺，而一些基於微服務體系的應用程序則更是將業務邏輯進行了容器化封裝，結合後臺的分佈式存儲與數據庫技術，實現了端到端的分佈式架構體系。

正如同不少銀行的科技部門都經歷過核心系統從大集中向SOA轉型的艱辛，由當前的小型機體系向分佈式架構轉型一樣面臨巨大的挑戰，例如技術堆棧的選擇、應用程序的開發、與DevOps體系的搭建等。

應用開發從傳統架構向分佈式轉型，最早面臨改造的天然就是應用程序框架。現在的微服務框架已經很是成熟，其表明性架構每每包括協議處理、服務拼裝、原子服務、以及底層持久化四層。業務邏輯從傳統的單一中間件被拆解成衆多微服務模塊，每一個微服務模塊由徹底對等的一系列容器構成，能夠簡單經過增長容器的方式實現對該服務吞吐處理能力的擴容。

可是微服務的拆分即意味着每一個服務都擁有本身獨立的執行邏輯與存儲。從數據庫的角度來看，微服務體系的拆分對數據庫存儲提出了極大的挑戰。若是每一個微服務依然將數據存放在傳統的單點數據庫中，其存儲與處理能力均沒法隨着微服務容器數量的上升提供一樣的擴展能力。在這種狀況下，數據庫將會成爲微服務體系框架中性能與擴展性的最大制約瓶頸。

而若是每一個微服務使用獨立的數據庫進行存放，整個企業IT的數據架構將會變得支離破碎。數據庫的數量從過去的幾百被拆分爲上萬個數據庫，整個運維團隊的管理成本與數據庫採購成本面臨幾何級數的提高。

所以，分佈式數據庫的目標不只僅做爲傳統Oracle或DB2的單一替代，將一個數據庫存放不下的數據放到多個物理機存放。在實際環境中，大部分銀行都有着較爲完善的數據生命週期管理策略，通常不會在生產環境中堆積大量的歷史數據，所以數據量通常來講不會是使用分佈式數據庫的最重要緣由。

1. 分佈式數據庫架構體系

分佈式數據庫的核心價值在於對分佈式應用程序提供一個彈性可擴張的數據服務資源池，也可稱之爲DBPaaS平臺。其主要能力在於爲上層數以萬計的來自不一樣開發商、不一樣業務類型、不一樣SLA安全級別、不一樣數據類型的微服務提供一個可彈性擴展、高響應速度、易維護的數據庫服務平臺，同時必須支持在不一樣微服務數據間進行高可用配置、容災策略定義、多租戶、業務數據邏輯物理隔離、交易分析混合模式隔離、冷熱數據隔離等一系列數據隔離與治理機制。

一些採用微服務架構的互聯網企業，20餘人的數據庫運維團隊能夠支撐幾十萬個不一樣的數據庫實例，最運維核心即是構建了企業統一的DBPaaS平臺，經過分佈式數據庫的故障自愈、彈性擴展等機制大規模簡化了運維人員對數據庫的管理。

當前業界存在衆多分佈式數據庫產品，主要分爲三種架構體系。

 應用垂直拆分
應用垂直拆分是一種最傳統的分佈式理念。其中一種實現方式是將應用拆解成多個獨立的子服務，每一個服務對應總體中的部分數據；另外一種實現方式則是在一個服務中對接多個數據庫鏈接，在應用內部根據業務規則選擇數據源。例如，應用根據用戶帳戶ID進行切分，ID爲一到一百萬以內的用戶存在數據庫A、從一百萬零一到兩百萬存在數據庫B，以此類推。

該機制經過在應用程序內預設一個規則，每次進行數據訪問首先要從規則庫篩選出目標所在的數據庫實例，而後再直接獲取鏈接進行訪問。使用這種機制，一方面跨數據庫的事務極爲難以實現，另外一方面從應用程序來講，分佈式能力的業務侵入性極強，須要很是多的定製化開發才能完成基本業務邏輯，同時每次擴容須要對應用邏輯作完整的端到端梳理，可能會存在大量的風險與二次開發工做。

 中間件分庫分表
隨着須要分佈式存儲能力需求的普及，業界開始逐漸出現了另外一類技術體系，稱爲中間件分庫分表。這類技術體系的思路是在應用程序和數據庫之間構建一個SQL解析器服務，將傳統的SQL進行解析而後翻譯成底層每一個數據庫所對應的子查詢，而後將查詢直接下發給底層的傳統數據庫進行執行。

該機制的優點在於數據存儲可以繼續基於傳統關係型數據庫不變，同時上層對於應用程序接口獲得了必定程度的封裝。可是，中間件分庫分表的機制從整個行業來看，能夠認爲是從傳統單點數據庫向分佈式數據庫轉型的過渡階段。在新型基於PC服務器構建的分佈式數據庫普及以前，一些急需數據拆分的應用能夠先經過該方式緩解業務與數據量暴漲的壓力，但在將來原生分佈式數據庫成熟且獲得驗證後會其優點將很難繼續保持。同時，該技術對於應用沒法作到100%徹底透明，通常來講須要在應用拼裝SQL的時候指定一些參數或使用較獨特的語法，很難作到對應用徹底透明無感知。

 原生分佈式數據庫
不一樣於中間件分庫分表技術，原生分佈式數據庫從底層的存儲引擎直接以PC服務器爲基礎進行重構，從數據存儲結構、數據安全機制、分佈式事務控制等多個領域針對分佈式存儲與執行進行優化。

原生分佈式數據庫是底層徹底從零開始研發，徹底拋棄小型機體系，基於PC服務器硬件架構設計的分佈式數據庫，將高可用、容災、分佈式等機制自然融入到數據存儲體系的方方面面。譬如說，一些分佈式數據庫產品可以在作到與MySQL 100%兼容的前提下，實現對應用徹底透明的分佈式存儲與執行能力。從開發者的角度看，用戶徹底不須要關注一個表存在幾億仍是幾十億記錄，只要在建表時配置好容量與最大物理資源消耗策略，數據會自動在集羣的多個物理設備中進行均衡，從應用來看就像訪問標準的表同樣直接進行讀寫請求。

1. 原生分佈式數據庫技術趨勢

爲了支撐將來IT微服務框架，分佈式交易型數據庫的引入須要從傳統技術兼容性、以及新技術前瞻性兩個維度進行評估。

ACID的支持與SQL完整性的支持是評估一款新型分佈式數據庫是否可以提供與傳統數據庫技術兼容的兩大關鍵指標。

• ACID的支持
從安全性上來看，不論採用新技術或傳統技術，數據不錯不丟是全部數據庫的必備基礎。在分佈式數據庫業界中，一些針對互聯網技術設計的產品以分佈式（Partition Tolerance）加高可用（Availability）做爲目標，在安全一致性（Consistence）上沒法保證數據的正確，很難在金融業務中被普遍使用。所以，銀行所關注的新型分佈式數據庫必須首先保證數據的安全和一致性，其中分佈式事務、分佈式鎖、四種隔離級別的支持等都是該指標中的關鍵技術點。

• SQL完整性支持
SQL完整性指的是新型分佈式數據庫與傳統關係型數據庫的開發友好性。越是成熟的分佈式數據庫，其SQL語法越能作到與傳統關係型數據庫兼容，同時其數據切分對應用程序則愈加透明。現在大部分分佈式數據庫技術都號稱支持MySQL語法，而主流新型應用程序也都將MySQL做爲其默認支持的數據庫選項。所以，對MySQL語法協議支持的強弱則成爲分佈式數據庫SQL完整性支持的評判關鍵。

新技術前瞻性指的是分佈式數據庫與將來開發方式和IT架構是否吻合。

• 分佈式與彈性擴展能力
做爲數據服務資源池，分佈式數據庫必須作到可彈性擴張，才能在服務於上層不斷增長微服務類型與數量。同時對於每一個微服務來講，其數據存放在一臺物理設備仍是多臺物理設備，必須對其中的應用代碼徹底透明。

• 多模式引擎
服務於上層來自不一樣開發商、不一樣業務場景、不一樣數據類型的微服務，分佈式數據庫必然須要支持多種SQL協議與計算引擎。從存儲引擎來看，結構化與半結構化數據均可能將會在應用中同時使用。所以，新一代分佈式數據庫須要從訪問接口到存儲結構均支持多模（Multi-Model）引擎。

• HTAP（Hybrid Transactional/Analytical Processing）
HTAP即混合交易分析處理能力。在傳統銀行IT架構中，聯機交易與統計分析系統每每採用不一樣的技術與物理設備，經過按期執行的ETL將聯機交易數據向分析系統中遷移。而做爲數據服務資源池，同一份數據可能被不一樣類型的微服務共享訪問。當一些聯機交易與審計類業務針對同一份數據同時運行時，必須保證請求在徹底隔離的物理環境中執行，作到交易分析業務無干擾。

整體來講，分佈式數據庫技術趨勢須要從傳統技術兼容性以及新技術前瞻性兩個維度進行評判，其中ACID數據安全與SQL完整性是傳統技術兼容性的重要指標，而彈性擴展能力、多模式引擎、以及HTAP則是新技術前瞻性的幾個重要衡量標準。

1. 金融分佈式數據庫應用場景

當前金融行業中，分佈式數據庫在五大領域中獲得應用：數據倉庫、大數據平臺、內容管理平臺、數據中臺、與聯機交易。對於聯機分佈式數據庫的使用，當前業界主要圍繞着三類業務場景。

 聯機交易系統
聯機交易系統是銀行重要的生產運行環境。我國一些分佈式技術探索走在前沿的銀行，已經開始逐漸將核心業務流程系統從IBM和Oracle的大機與小機架構下移到分佈式環境，作到集羣可彈性擴張，知足隨時爆發的業務增加需求。一些典型使用到分佈式數據庫的系統包括網貸核心、渠道整合、信用卡積分等。

 數據中臺
現在，不少企業提出了重中臺、輕前臺的IT架構。而數據中臺做爲企業IT數據整合的關鍵平臺，爲前臺靈活多變的業務需求，與後臺相對固定的數據模型相結合，起到了「數據匯聚、鏈接先後」的做用。譬如銀行可以先以生產系統瘦身做爲目標，從歷史流水帳單查詢打印開始，逐漸擴展到用戶畫像、資產視圖等準實時數據服務。

 內容管理平臺
傳統的內容管理平臺主要之後督與審計爲目的進行建設，前端業務基本不會直接參與非結構化數據的使用。而隨着自助設備與移動應用的普及，愈來愈多的流程處理須要非結構化數據的直接參與。所以，內容管理平臺也在不少銀行從過去的後端走向前端，大量對客應用直接鏈接到內容管理平臺，一些開戶、信貸、甚至自助設備大量流程都在高度依賴內容管理平臺的實時交互能力，使得內容管理系統從傳統的對內後臺審計走向對外聯機服務。

能夠看到，做爲離線分析類業務場景來講，分佈式數據庫在銀行早已經獲得了廣泛應用。而針對聯機業務來講，MPP數據倉庫與大數據平臺不管從可靠性、併發能力、與響應速度均沒法知足需求。

小結
現在一些對分佈式技術研究較深的銀行，已經開始針對分佈式數據庫進行試點應用。分佈式數據庫的核心價值不只在於將傳統數據庫存放不下的數據分散到多個物理設備中存儲，更重要的是針對將來微服務化的應用開發模型，面對來自不一樣開發商、不一樣SLA級別、不一樣高可用容災特性、不一樣業務類型的數據，提供一個可彈性擴展、多模式接口的數據服務平臺（DBPaaS）。

當前的科技人員常常問的一個問題：分佈式數據庫是否可以在將來取代Oracle？這個問題的答案能夠說很是直觀。分佈式應用框架與PC服務器集羣化必定是將來IT發展的方向，而微服務取代煙囪式軟件架構，必定須要將數據庫從傳統的「點」向平臺的「面」進行轉移。每一個應用程序都存在相應的迭代週期，現在已經能夠看到不少應用程序都開始將MySQL等開源數據庫做爲自身默認支持的數據庫選項，將來必須使用Oracle的場景也將會愈來愈少。

所以，分佈式數據庫將來必將取代Oracle等傳統單點數據庫。銀行的科技部門也應該儘早對分佈式數據庫技術進行前瞻性研究，以適應將來銀行IT架構從煙囪式模式向微服務轉型的趨勢。