一、金融行業(yè)架構轉型需求

隨著移動化與互聯(lián)網化的不斷發(fā)展，我國金融行業(yè)的商業(yè)模式與技術體系已經逐漸走上了與西方世界完全不同的道路。眾所周知，歐美國家的移動化普及率遠遠不如我國，同時人口基數(shù)也有著數(shù)量級的不同。這就使得國內外金融行業(yè)所面臨的業(yè)務類型、數(shù)據(jù)量、并發(fā)量都存在巨大的差異，導致對整個IT基礎設施的需求截然不同。

在最近的一兩年中，國內部分科技的銀行已經率先對微服務與分布式技術進行了探索，一些新建的互聯(lián)網金融類業(yè)務也已經開始嘗試使用微服務架構、分布式技術、DevOps框架進行應用的開發(fā)與維護。甚至一些銀行在規(guī)劃下一代核心體系架構時，也會嘗試適當引入分布式架構，以滿足未來業(yè)務壓力與數(shù)據(jù)量不斷增長的需求。

與新一代分布式架構相比，中間件加數(shù)據(jù)庫的傳統(tǒng)“煙囪式”架構在面向海量數(shù)據(jù)、高并發(fā)、高響應速度的業(yè)務應用時存在諸多問題。

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

二、銀行架構演進歷程

在過去的近二十年間，我國銀行的IT架構歷經了幾個階段的變化。我國的第一代銀行核心系統(tǒng)構建在大型機之上，采用的是典型的大集中架構。

而隨著SOA概念的提出，一些銀行也開始逐漸進行了去大機化，將核心業(yè)務系統(tǒng)從主機或400下移到UNIX小型機。虛擬化技術的增強使得一些銀行和金融機構在其基礎架構中引入虛擬化機制，將開發(fā)環(huán)境以及一些生產環(huán)境的應用程序部署在虛擬機上。

如今，很多銀行都已經基于分布式與PC服務器架構建設了大數(shù)據(jù)平臺，而一些基于微服務體系的應用程序則更是將業(yè)務邏輯進行了容器化封裝，結合后臺的分布式存儲與數(shù)據(jù)庫技術，實現(xiàn)了端到端的分布式架構體系。

正如同很多銀行的科技部門都經歷過核心系統(tǒng)從大集中向SOA轉型的艱辛，由當前的小型機體系向分布式架構轉型同樣面臨巨大的挑戰(zhàn)，例如技術堆棧的選擇、應用程序的開發(fā)、與DevOps體系的搭建等。

應用開發(fā)從傳統(tǒng)架構向分布式轉型，最先面臨改造的自然就是應用程序框架。如今的微服務框架已經非常成熟，其代表性架構往往包括協(xié)議處理、服務拼裝、原子服務、以及底層持久化四層。業(yè)務邏輯從傳統(tǒng)的單一中間件被拆解成眾多微服務模塊，每個微服務模塊由完全對等的一系列容器構成，可以簡單通過增加容器的方式實現(xiàn)對該服務吞吐處理能力的擴容。

但是微服務的拆分即意味著每個服務都擁有自己獨立的執(zhí)行邏輯與存儲。從數(shù)據(jù)庫的角度來看，微服務體系的拆分對數(shù)據(jù)庫存儲提出了極大的挑戰(zhàn)。如果每個微服務依然將數(shù)據(jù)存放在傳統(tǒng)的單點數(shù)據(jù)庫中，其存儲與處理能力均無法隨著微服務容器數(shù)量的上升提供同樣的擴展能力。在這種情況下，數(shù)據(jù)庫將會成為微服務體系框架中性能與擴展性的大制約瓶頸。

而如果每個微服務使用獨立的數(shù)據(jù)庫進行存放，整個企業(yè)IT的數(shù)據(jù)架構將會變得支離破碎。數(shù)據(jù)庫的數(shù)量從過去的幾百被拆分為上萬個數(shù)據(jù)庫，整個運維團隊的管理成本與數(shù)據(jù)庫采購成本面臨幾何級數(shù)的提升。

因此，分布式數(shù)據(jù)庫的目標不僅僅作為傳統(tǒng)Oracle或DB2的單一替代，將一個數(shù)據(jù)庫存放不下的數(shù)據(jù)放到多個物理機存放。在實際環(huán)境中，大部分銀行都有著較為完善的數(shù)據(jù)生命周期管理策略，一般不會在生產環(huán)境中堆積大量的歷史數(shù)據(jù)，因此數(shù)據(jù)量一般來說不會是使用分布式數(shù)據(jù)庫的最重要原因。

三、分布式數(shù)據(jù)庫架構體系

分布式數(shù)據(jù)庫的核心價值在于對分布式應用程序提供一個彈性可擴張的數(shù)據(jù)服務資源池，也可稱之為DBPaaS平臺。

其主要能力在于為上層數(shù)以萬計的來自不同開發(fā)商、不同業(yè)務類型、不同SLA安全級別、不同數(shù)據(jù)類型的微服務提供一個可彈性擴展、高響應速度、易維護的數(shù)據(jù)庫服務平臺，同時必須支持在不同微服務數(shù)據(jù)間進行高可用配置、容災策略定義、多租戶、業(yè)務數(shù)據(jù)邏輯物理隔離、交易分析混合模式隔離、冷熱數(shù)據(jù)隔離等一系列數(shù)據(jù)隔離與治理機制。

一些采用微服務架構的互聯(lián)網企業(yè)，20余人的數(shù)據(jù)庫運維團隊可以支撐幾十萬個不同的數(shù)據(jù)庫實例，運維最核心便是構建了企業(yè)統(tǒng)一的DBPaaS平臺，通過分布式數(shù)據(jù)庫的故障自愈、彈性擴展等機制大規(guī)模簡化了運維人員對數(shù)據(jù)庫的管理。

當前業(yè)界存在眾多分布式數(shù)據(jù)庫產品，主要分為三種架構體系。

1、應用垂直拆分

應用垂直拆分是一種最傳統(tǒng)的分布式理念。其中一種實現(xiàn)方式是將應用拆解成多個獨立的子服務，每個服務對應整體中的部分數(shù)據(jù);另一種實現(xiàn)方式則是在一個服務中對接多個數(shù)據(jù)庫連接，在應用內部根據(jù)業(yè)務規(guī)則選擇數(shù)據(jù)源。例如，應用根據(jù)用戶賬戶ID進行切分，ID為一到一百萬之內的用戶存在數(shù)據(jù)庫A、從一百萬零一到兩百萬存在數(shù)據(jù)庫B，以此類推。

該機制通過在應用程序內預設一個規(guī)則，每次進行數(shù)據(jù)訪問首先要從規(guī)則庫篩選出目標所在的數(shù)據(jù)庫實例，然后再直接獲取連接進行訪問。

使用這種機制，一方面跨數(shù)據(jù)庫的事務極為難以實現(xiàn)，另一方面從應用程序來說，分布式能力的業(yè)務侵入性極強，需要非常多的定制化開發(fā)才能完成基本業(yè)務邏輯，同時每次擴容需要對應用邏輯做完整的端到端梳理，可能會存在大量的風險與二次開發(fā)工作。

2、中間件分庫分表

隨著需要分布式存儲能力需求的普及，業(yè)界開始逐漸出現(xiàn)了另一類技術體系，稱為中間件分庫分表。這類技術體系的思路是在應用程序和數(shù)據(jù)庫之間構建一個SQL解析器服務，將傳統(tǒng)的SQL進行解析然后翻譯成底層每個數(shù)據(jù)庫所對應的子查詢，然后將查詢直接下發(fā)給底層的傳統(tǒng)數(shù)據(jù)庫進行執(zhí)行。

該機制的優(yōu)勢在于數(shù)據(jù)存儲能夠繼續(xù)基于傳統(tǒng)關系型數(shù)據(jù)庫不變，同時上層對于應用程序接口得到了一定程度的封裝。但是，中間件分庫分表的機制從整個行業(yè)來看，可以認為是從傳統(tǒng)單點數(shù)據(jù)庫向分布式數(shù)據(jù)庫轉型的過渡階段。

在新型基于PC服務器構建的分布式數(shù)據(jù)庫普及之前，一些急需數(shù)據(jù)拆分的應用可以先通過該方式緩解業(yè)務與數(shù)據(jù)量暴漲的壓力，但在未來原生分布式數(shù)據(jù)庫成熟且得到驗證后會其優(yōu)勢將很難繼續(xù)保持。

同時，該技術對于應用無法做到100%完全透明，一般來說需要在應用拼裝SQL的時候指定一些參數(shù)或使用較獨特的語法，很難做到對應用完全透明無感知。

3、原生分布式數(shù)據(jù)庫

不同于中間件分庫分表技術，原生分布式數(shù)據(jù)庫從底層的存儲引擎直接以PC服務器為基礎進行重構，從數(shù)據(jù)存儲結構、數(shù)據(jù)安全機制、分布式事務控制等多個領域針對分布式存儲與執(zhí)行進行優(yōu)化。

原生分布式數(shù)據(jù)庫是底層完全從零開始研發(fā)，完全拋棄小型機體系，基于PC服務器硬件架構設計的分布式數(shù)據(jù)庫，將高可用、容災、分布式等機制天然融入到數(shù)據(jù)存儲體系的方方面面。

譬如說，一些分布式數(shù)據(jù)庫產品能夠在做到與MySQL 100%兼容的前提下，實現(xiàn)對應用完全透明的分布式存儲與執(zhí)行能力。從開發(fā)者的角度看，用戶完全不需要關注一個表存在幾億還是幾十億記錄，只要在建表時配置好容量與大物理資源消耗策略，數(shù)據(jù)會自動在集群的多個物理設備中進行均衡，從應用來看就像訪問標準的表一樣直接進行讀寫請求。

4、原生分布式數(shù)據(jù)庫技術趨勢

為了支撐未來IT微服務框架，分布式交易型數(shù)據(jù)庫的引入需要從傳統(tǒng)技術兼容性、以及新技術前瞻性兩個維度進行評估。

ACID的支持與SQL完整性的支持是評估一款新型分布式數(shù)據(jù)庫是否能夠提供與傳統(tǒng)數(shù)據(jù)庫技術兼容的兩大關鍵指標。

1)ACID的支持

從安全性上來看，不論采用新技術或傳統(tǒng)技術，數(shù)據(jù)不錯不丟是所有數(shù)據(jù)庫的必備基礎。

在分布式數(shù)據(jù)庫業(yè)界中，一些針對互聯(lián)網技術設計的產品以分布式(Partition Tolerance)加高可用(Availability)作為目標，在安全一致性(Consistence)上無法保證數(shù)據(jù)的正確，很難在金融業(yè)務中被廣泛使用。

因此，銀行所關注的新型分布式數(shù)據(jù)庫必須首先保證數(shù)據(jù)的安全和一致性，其中分布式事務、分布式鎖、四種隔離級別的支持等都是該指標中的關鍵技術點。

2)SQL完整性支持

SQL完整性指的是新型分布式數(shù)據(jù)庫與傳統(tǒng)關系型數(shù)據(jù)庫的開發(fā)友好性。

越是成熟的分布式數(shù)據(jù)庫，其SQL語法越能做到與傳統(tǒng)關系型數(shù)據(jù)庫兼容，同時其數(shù)據(jù)切分對應用程序則越發(fā)透明。如今大部分分布式數(shù)據(jù)庫技術都號稱支持MySQL語法，而主流新型應用程序也都將MySQL作為其默認支持的數(shù)據(jù)庫選項。因此，對MySQL語法協(xié)議支持的強弱則成為分布式數(shù)據(jù)庫SQL完整性支持的評判關鍵。

新技術前瞻性指的是分布式數(shù)據(jù)庫與未來開發(fā)方式和IT架構是否吻合。

3)分布式與彈性擴展能力

作為數(shù)據(jù)服務資源池，分布式數(shù)據(jù)庫必須做到可彈性擴張，才能在服務于上層不斷增加微服務類型與數(shù)量。同時對于每個微服務來說，其數(shù)據(jù)存放在一臺物理設備還是多臺物理設備，必須對其中的應用代碼完全透明。

4)多模式引擎

服務于上層來自不同開發(fā)商、不同業(yè)務場景、不同數(shù)據(jù)類型的微服務，分布式數(shù)據(jù)庫必然需要支持多種SQL協(xié)議與計算引擎。從存儲引擎來看，結構化與半結構化數(shù)據(jù)都可能將會在應用中同時使用。因此，新一代分布式數(shù)據(jù)庫需要從訪問接口到存儲結構均支持多模(Multi-Model)引擎。

5)HTAP(Hybrid Transactional/Analytical Processing)

HTAP即混合交易分析處理能力。在傳統(tǒng)銀行IT架構中，聯(lián)機交易與統(tǒng)計分析系統(tǒng)往往采用不同的技術與物理設備，通過定期執(zhí)行的ETL將聯(lián)機交易數(shù)據(jù)向分析系統(tǒng)中遷移。而作為數(shù)據(jù)服務資源池，同一份數(shù)據(jù)可能被不同類型的微服務共享訪問。

當一些聯(lián)機交易與審計類業(yè)務針對同一份數(shù)據(jù)同時運行時，必須保證請求在完全隔離的物理環(huán)境中執(zhí)行，做到交易分析業(yè)務無干擾。

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

5、金融分布式數(shù)據(jù)庫應用場景

當前金融行業(yè)中，分布式數(shù)據(jù)庫在五大領域中得到應用：數(shù)據(jù)倉庫、大數(shù)據(jù)平臺、內容管理平臺、數(shù)據(jù)中臺、與聯(lián)機交易。對于聯(lián)機分布式數(shù)據(jù)庫的使用，當前業(yè)界主要圍繞著三類業(yè)務場景。

1)聯(lián)機交易系統(tǒng)

聯(lián)機交易系統(tǒng)是銀行重要的生產運行環(huán)境。

我國一些分布式技術探索走在前沿的銀行，已經開始逐漸將核心業(yè)務流程系統(tǒng)從IBM和Oracle的大機與小機架構下移到分布式環(huán)境，做到集群可彈性擴張，滿足隨時爆發(fā)的業(yè)務增長需求。一些典型使用到分布式數(shù)據(jù)庫的系統(tǒng)包括網貸核心、渠道整合、信用卡積分等。

2)數(shù)據(jù)中臺

如今，很多企業(yè)提出了重中臺、輕前臺的IT架構。而數(shù)據(jù)中臺作為企業(yè)IT數(shù)據(jù)整合的關鍵平臺，為前臺靈活多變的業(yè)務需求，與后臺相對固定的數(shù)據(jù)模型相結合，起到了“數(shù)據(jù)匯聚、連接前后”的作用。譬如銀行能夠先以生產系統(tǒng)瘦身作為目標，從歷史流水賬單查詢打印開始，逐漸擴展到用戶畫像、資產視圖等準實時數(shù)據(jù)服務。

3)內容管理平臺

傳統(tǒng)的內容管理平臺主要以后督與審計為目的進行建設，前端業(yè)務基本不會直接參與非結構化數(shù)據(jù)的使用。而隨著自助設備與移動應用的普及，越來越多的流程處理需要非結構化數(shù)據(jù)的直接參與。

因此，內容管理平臺也在很多銀行從過去的后端走向前端，大量對客應用直接連接到內容管理平臺，一些開戶、信貸、甚至自助設備大量流程都在高度依賴內容管理平臺的實時交互能力，使得內容管理系統(tǒng)從傳統(tǒng)的對內后臺審計走向對外聯(lián)機服務。

可以看到，作為離線分析類業(yè)務場景來說，分布式數(shù)據(jù)庫在銀行早已經得到了普遍應用。而針對聯(lián)機業(yè)務來說，MPP數(shù)據(jù)倉庫與大數(shù)據(jù)平臺無論從可靠性、并發(fā)能力、與響應速度均無法滿足需求。

四、小結

如今一些對分布式技術研究較深的銀行，已經開始針對分布式數(shù)據(jù)庫進行試點應用。分布式數(shù)據(jù)庫的核心價值不僅在于將傳統(tǒng)數(shù)據(jù)庫存放不下的數(shù)據(jù)分散到多個物理設備中存儲，更重要的是針對未來微服務化的應用開發(fā)模型，面對來自不同開發(fā)商、不同SLA級別、不同高可用容災特性、不同業(yè)務類型的數(shù)據(jù)，提供一個可彈性擴展、多模式接口的數(shù)據(jù)服務平臺(DBPaaS)。

當前的科技人員經常問的一個問題：分布式數(shù)據(jù)庫是否能夠在未來取代Oracle?

這個問題的答案可以說非常直觀。分布式應用框架與PC服務器集群化一定是未來IT發(fā)展的方向，而微服務取代煙囪式軟件架構，一定需要將數(shù)據(jù)庫從傳統(tǒng)的“點”向平臺的“面”進行轉移。

每個應用程序都存在相應的迭代周期，如今已經可以看到很多應用程序都開始將MySQL等開源數(shù)據(jù)庫作為自身默認支持的數(shù)據(jù)庫選項，未來必須使用Oracle的場景也將會越來越少。

因此，分布式數(shù)據(jù)庫未來必將取代Oracle等傳統(tǒng)單點數(shù)據(jù)庫。銀行的科技部門也應該盡早對分布式數(shù)據(jù)庫技術進行前瞻性研究，以適應未來銀行IT架構從煙囪式模式向微服務轉型的趨勢。

當前標題：跨越數(shù)據(jù)庫發(fā)展鴻溝，談分布式數(shù)據(jù)庫技術趨勢
當前路徑：http://aaarwkj.com/news/104805.html

成都網站建設公司_創(chuàng)新互聯(lián)，為您提供做網站、微信公眾號、商城網站、網站改版、服務器托管、網站收錄

廣告

聲明：本網站發(fā)布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯(lián)