跨越數(shù)據(jù)庫(kù)發(fā)展鴻溝，談分布式數(shù)據(jù)庫(kù)技術(shù)趨勢(shì)

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

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

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

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

2. 銀行架構(gòu)演進(jìn)歷程
   在過(guò)去的近二十年間，我國(guó)銀行的IT架構(gòu)歷經(jīng)了幾個(gè)階段的變化。我國(guó)的第一代銀行核心系統(tǒng)構(gòu)建在大型機(jī)之上，采用的是典型的大集中架構(gòu)。而隨著SOA概念的提出，一些銀行也開(kāi)始逐漸進(jìn)行了去大機(jī)化，將核心業(yè)務(wù)系統(tǒng)從主機(jī)或400下移到UNIX小型機(jī)。虛擬化技術(shù)的增強(qiáng)使得一些銀行和金融機(jī)構(gòu)在其基礎(chǔ)架構(gòu)中引入虛擬化機(jī)制，將開(kāi)發(fā)環(huán)境以及一些生產(chǎn)環(huán)境的應(yīng)用程序部署在虛擬機(jī)上。

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

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

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

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

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

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

3. 分布式數(shù)據(jù)庫(kù)架構(gòu)體系
   分布式數(shù)據(jù)庫(kù)的核心價(jià)值在于對(duì)分布式應(yīng)用程序提供一個(gè)彈性可擴(kuò)張的數(shù)據(jù)服務(wù)資源池，也可稱之為DBPaaS平臺(tái)。其主要能力在于為上層數(shù)以萬(wàn)計(jì)的來(lái)自不同開(kāi)發(fā)商、不同業(yè)務(wù)類型、不同SLA安全級(jí)別、不同數(shù)據(jù)類型的微服務(wù)提供一個(gè)可彈性擴(kuò)展、高響應(yīng)速度、易維護(hù)的數(shù)據(jù)庫(kù)服務(wù)平臺(tái)，同時(shí)必須支持在不同微服務(wù)數(shù)據(jù)間進(jìn)行高可用配置、容災(zāi)策略定義、多租戶、業(yè)務(wù)數(shù)據(jù)邏輯物理隔離、交易分析混合模式隔離、冷熱數(shù)據(jù)隔離等一系列數(shù)據(jù)隔離與治理機(jī)制。

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

當(dāng)前業(yè)界存在眾多分布式數(shù)據(jù)庫(kù)產(chǎn)品，主要分為三種架構(gòu)體系。

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

該機(jī)制通過(guò)在應(yīng)用程序內(nèi)預(yù)設(shè)一個(gè)規(guī)則，每次進(jìn)行數(shù)據(jù)訪問(wèn)首先要從規(guī)則庫(kù)篩選出目標(biāo)所在的數(shù)據(jù)庫(kù)實(shí)例，然后再直接獲取連接進(jìn)行訪問(wèn)。使用這種機(jī)制，一方面跨數(shù)據(jù)庫(kù)的事務(wù)極為難以實(shí)現(xiàn)，另一方面從應(yīng)用程序來(lái)說(shuō)，分布式能力的業(yè)務(wù)侵入性極強(qiáng)，需要非常多的定制化開(kāi)發(fā)才能完成基本業(yè)務(wù)邏輯，同時(shí)每次擴(kuò)容需要對(duì)應(yīng)用邏輯做完整的端到端梳理，可能會(huì)存在大量的風(fēng)險(xiǎn)與二次開(kāi)發(fā)工作。

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

該機(jī)制的優(yōu)勢(shì)在于數(shù)據(jù)存儲(chǔ)能夠繼續(xù)基于傳統(tǒng)關(guān)系型數(shù)據(jù)庫(kù)不變，同時(shí)上層對(duì)于應(yīng)用程序接口得到了一定程度的封裝。但是，中間件分庫(kù)分表的機(jī)制從整個(gè)行業(yè)來(lái)看，可以認(rèn)為是從傳統(tǒng)單點(diǎn)數(shù)據(jù)庫(kù)向分布式數(shù)據(jù)庫(kù)轉(zhuǎn)型的過(guò)渡階段。在新型基于PC服務(wù)器構(gòu)建的分布式數(shù)據(jù)庫(kù)普及之前，一些急需數(shù)據(jù)拆分的應(yīng)用可以先通過(guò)該方式緩解業(yè)務(wù)與數(shù)據(jù)量暴漲的壓力，但在未來(lái)原生分布式數(shù)據(jù)庫(kù)成熟且得到驗(yàn)證后會(huì)其優(yōu)勢(shì)將很難繼續(xù)保持。同時(shí)，該技術(shù)對(duì)于應(yīng)用無(wú)法做到100%完全透明，一般來(lái)說(shuō)需要在應(yīng)用拼裝SQL的時(shí)候指定一些參數(shù)或使用較獨(dú)特的語(yǔ)法，很難做到對(duì)應(yīng)用完全透明無(wú)感知。

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

原生分布式數(shù)據(jù)庫(kù)是底層完全從零開(kāi)始研發(fā)，完全拋棄小型機(jī)體系，基于PC服務(wù)器硬件架構(gòu)設(shè)計(jì)的分布式數(shù)據(jù)庫(kù)，將高可用、容災(zāi)、分布式等機(jī)制天然融入到數(shù)據(jù)存儲(chǔ)體系的方方面面。譬如說(shuō)，一些分布式數(shù)據(jù)庫(kù)產(chǎn)品能夠在做到與MySQL 100%兼容的前提下，實(shí)現(xiàn)對(duì)應(yīng)用完全透明的分布式存儲(chǔ)與執(zhí)行能力。從開(kāi)發(fā)者的角度看，用戶完全不需要關(guān)注一個(gè)表存在幾億還是幾十億記錄，只要在建表時(shí)配置好容量與最大物理資源消耗策略，數(shù)據(jù)會(huì)自動(dòng)在集群的多個(gè)物理設(shè)備中進(jìn)行均衡，從應(yīng)用來(lái)看就像訪問(wèn)標(biāo)準(zhǔn)的表一樣直接進(jìn)行讀寫請(qǐng)求。

4. 原生分布式數(shù)據(jù)庫(kù)技術(shù)趨勢(shì)
   為了支撐未來(lái)IT微服務(wù)框架，分布式交易型數(shù)據(jù)庫(kù)的引入需要從傳統(tǒng)技術(shù)兼容性、以及新技術(shù)前瞻性兩個(gè)維度進(jìn)行評(píng)估。

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

? ACID的支持
從安全性上來(lái)看，不論采用新技術(shù)或傳統(tǒng)技術(shù)，數(shù)據(jù)不錯(cuò)不丟是所有數(shù)據(jù)庫(kù)的必備基礎(chǔ)。在分布式數(shù)據(jù)庫(kù)業(yè)界中，一些針對(duì)互聯(lián)網(wǎng)技術(shù)設(shè)計(jì)的產(chǎn)品以分布式（Partition Tolerance）加高可用（Availability）作為目標(biāo)，在安全一致性（Consistence）上無(wú)法保證數(shù)據(jù)的正確，很難在金融業(yè)務(wù)中被廣泛使用。因此，銀行所關(guān)注的新型分布式數(shù)據(jù)庫(kù)必須首先保證數(shù)據(jù)的安全和一致性，其中分布式事務(wù)、分布式鎖、四種隔離級(jí)別的支持等都是該指標(biāo)中的關(guān)鍵技術(shù)點(diǎn)。

? SQL完整性支持
SQL完整性指的是新型分布式數(shù)據(jù)庫(kù)與傳統(tǒng)關(guān)系型數(shù)據(jù)庫(kù)的開(kāi)發(fā)友好性。越是成熟的分布式數(shù)據(jù)庫(kù)，其SQL語(yǔ)法越能做到與傳統(tǒng)關(guān)系型數(shù)據(jù)庫(kù)兼容，同時(shí)其數(shù)據(jù)切分對(duì)應(yīng)用程序則越發(fā)透明。如今大部分分布式數(shù)據(jù)庫(kù)技術(shù)都號(hào)稱支持MySQL語(yǔ)法，而主流新型應(yīng)用程序也都將MySQL作為其默認(rèn)支持的數(shù)據(jù)庫(kù)選項(xiàng)。因此，對(duì)MySQL語(yǔ)法協(xié)議支持的強(qiáng)弱則成為分布式數(shù)據(jù)庫(kù)SQL完整性支持的評(píng)判關(guān)鍵。

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

? 分布式與彈性擴(kuò)展能力
作為數(shù)據(jù)服務(wù)資源池，分布式數(shù)據(jù)庫(kù)必須做到可彈性擴(kuò)張，才能在服務(wù)于上層不斷增加微服務(wù)類型與數(shù)量。同時(shí)對(duì)于每個(gè)微服務(wù)來(lái)說(shuō)，其數(shù)據(jù)存放在一臺(tái)物理設(shè)備還是多臺(tái)物理設(shè)備，必須對(duì)其中的應(yīng)用代碼完全透明。

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

? HTAP（Hybrid Transactional/Analytical Processing）
HTAP即混合交易分析處理能力。在傳統(tǒng)銀行IT架構(gòu)中，聯(lián)機(jī)交易與統(tǒng)計(jì)分析系統(tǒng)往往采用不同的技術(shù)與物理設(shè)備，通過(guò)定期執(zhí)行的ETL將聯(lián)機(jī)交易數(shù)據(jù)向分析系統(tǒng)中遷移。而作為數(shù)據(jù)服務(wù)資源池，同一份數(shù)據(jù)可能被不同類型的微服務(wù)共享訪問(wèn)。當(dāng)一些聯(lián)機(jī)交易與審計(jì)類業(yè)務(wù)針對(duì)同一份數(shù)據(jù)同時(shí)運(yùn)行時(shí)，必須保證請(qǐng)求在完全隔離的物理環(huán)境中執(zhí)行，做到交易分析業(yè)務(wù)無(wú)干擾。

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

5. 金融分布式數(shù)據(jù)庫(kù)應(yīng)用場(chǎng)景
   當(dāng)前金融行業(yè)中，分布式數(shù)據(jù)庫(kù)在五大領(lǐng)域中得到應(yīng)用：數(shù)據(jù)倉(cāng)庫(kù)、大數(shù)據(jù)平臺(tái)、內(nèi)容管理平臺(tái)、數(shù)據(jù)中臺(tái)、與聯(lián)機(jī)交易。對(duì)于聯(lián)機(jī)分布式數(shù)據(jù)庫(kù)的使用，當(dāng)前業(yè)界主要圍繞著三類業(yè)務(wù)場(chǎng)景。

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

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

? 內(nèi)容管理平臺(tái)
傳統(tǒng)的內(nèi)容管理平臺(tái)主要以后督與審計(jì)為目的進(jìn)行建設(shè)，前端業(yè)務(wù)基本不會(huì)直接參與非結(jié)構(gòu)化數(shù)據(jù)的使用。而隨著自助設(shè)備與移動(dòng)應(yīng)用的普及，越來(lái)越多的流程處理需要非結(jié)構(gòu)化數(shù)據(jù)的直接參與。因此，內(nèi)容管理平臺(tái)也在很多銀行從過(guò)去的后端走向前端，大量對(duì)客應(yīng)用直接連接到內(nèi)容管理平臺(tái)，一些開(kāi)戶、信貸、甚至自助設(shè)備大量流程都在高度依賴內(nèi)容管理平臺(tái)的實(shí)時(shí)交互能力，使得內(nèi)容管理系統(tǒng)從傳統(tǒng)的對(duì)內(nèi)后臺(tái)審計(jì)走向?qū)ν饴?lián)機(jī)服務(wù)。

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

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

當(dāng)前的科技人員經(jīng)常問(wèn)的一個(gè)問(wèn)題：分布式數(shù)據(jù)庫(kù)是否能夠在未來(lái)取代Oracle？這個(gè)問(wèn)題的答案可以說(shuō)非常直觀。分布式應(yīng)用框架與PC服務(wù)器集群化一定是未來(lái)IT發(fā)展的方向，而微服務(wù)取代煙囪式軟件架構(gòu)，一定需要將數(shù)據(jù)庫(kù)從傳統(tǒng)的“點(diǎn)”向平臺(tái)的“面”進(jìn)行轉(zhuǎn)移。每個(gè)應(yīng)用程序都存在相應(yīng)的迭代周期，如今已經(jīng)可以看到很多應(yīng)用程序都開(kāi)始將MySQL等開(kāi)源數(shù)據(jù)庫(kù)作為自身默認(rèn)支持的數(shù)據(jù)庫(kù)選項(xiàng)，未來(lái)必須使用Oracle的場(chǎng)景也將會(huì)越來(lái)越少。

因此，分布式數(shù)據(jù)庫(kù)未來(lái)必將取代Oracle等傳統(tǒng)單點(diǎn)數(shù)據(jù)庫(kù)。銀行的科技部門也應(yīng)該盡早對(duì)分布式數(shù)據(jù)庫(kù)技術(shù)進(jìn)行前瞻×××，以適應(yīng)未來(lái)銀行IT架構(gòu)從煙囪式模式向微服務(wù)轉(zhuǎn)型的趨勢(shì)。