怎樣打造一款分布式數(shù)據(jù)庫

怎樣打造一款分布式數(shù)據(jù)庫，針對這個問題，這篇文章詳細(xì)介紹了相對應(yīng)的分析和解答，希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。

關(guān)系型數(shù)據(jù)庫在過去數(shù)十年的數(shù)據(jù)庫領(lǐng)域一直占據(jù)著絕對主導(dǎo)的地位，它所帶來的穩(wěn)定性、安全性和易用性，成為了構(gòu)建現(xiàn)代化系統(tǒng)的基石。隨著的互聯(lián)網(wǎng)高速發(fā)展，構(gòu)架于單機系統(tǒng)的數(shù)據(jù)庫已無法滿足越來越高的并發(fā)請求和越來越大的數(shù)據(jù)存儲需求，因此，分布式數(shù)據(jù)庫被愈加廣泛的采用。

一直以來，數(shù)據(jù)庫領(lǐng)域均由西方的科技公司和社區(qū)所主導(dǎo)。而今，越來越多的國產(chǎn)數(shù)據(jù)庫解決方案以分布式為支點，逐漸在此領(lǐng)域有所建樹。Apache ShardingSphere 是其中的一個分布式數(shù)據(jù)庫解決方案，也是目前 Apache 軟件基金會中唯一的數(shù)據(jù)庫中間件。

全面兼容面向傳統(tǒng)關(guān)系型數(shù)據(jù)庫的 SQL 和事務(wù)，并且對分布式的天然友好，是分布式數(shù)據(jù)庫解決方案的設(shè)計目標(biāo)。它的核心功能主要集中在以下幾點：

• 分布式存儲: 數(shù)據(jù)存儲不受單機磁盤容量限制，可通過增加數(shù)據(jù)服務(wù)器的數(shù)量提升存儲能力；

• 計算存儲分離: 計算節(jié)點無狀態(tài)，可通過水平擴展增加算力。存儲節(jié)點和計算節(jié)點能夠分層優(yōu)化；

• 分布式事務(wù): 高性能、完全支持本地事務(wù) ACID 原義的分布式事務(wù)處理引擎；

• 彈性伸縮：可以隨時隨地的在不影響現(xiàn)有應(yīng)用的情況下，動態(tài)對數(shù)據(jù)存儲節(jié)點擴容和縮容；

• 多數(shù)據(jù)副本：自動將數(shù)據(jù)以強一致、高性能的方式復(fù)制至跨機房的多個副本，以保證數(shù)據(jù)的絕對安全；

• HTAP：采用同一套產(chǎn)品混合處理 OLTP 的事務(wù)型操作和 OLAP 的分析型操作。

分布式數(shù)據(jù)庫的實現(xiàn)方案可以劃分為進(jìn)取型和穩(wěn)定型。進(jìn)取型實現(xiàn)方案是指開發(fā)全新架構(gòu)的 NewSQL。這類產(chǎn)品以追求更高性能換取穩(wěn)定性的缺失和運維經(jīng)驗的不足；穩(wěn)定型的實現(xiàn)方案是指在現(xiàn)有數(shù)據(jù)庫的基礎(chǔ)上提供增量能力的中間件。這類產(chǎn)品則以犧牲部分性能以保證數(shù)據(jù)庫的穩(wěn)定性和運維經(jīng)驗的復(fù)用。

Apache ShardingSphere 是一套開源的分布式數(shù)據(jù)庫中間件解決方案組成的生態(tài)圈，它由 Sharding-JDBC、Sharding-Proxy 和 Sharding-Sidecar（計劃中）這 3 款相互獨立的產(chǎn)品組成。它們均提供標(biāo)準(zhǔn)化的數(shù)據(jù)分片、分布式事務(wù)和分布式治理等功能，可適用于如 Java 同構(gòu)、異構(gòu)語言、云原生等各種多樣化的應(yīng)用場景。隨著 Apache ShardingSphere 在查詢優(yōu)化器和分布式事務(wù)引擎的不斷探索，它已漸漸地打破了實現(xiàn)方案的產(chǎn)品邊界，向集進(jìn)取型和穩(wěn)定型于一身的平臺級解決方案演進(jìn)。

定位為輕量級 Java 框架，在 Java 的 JDBC 層提供的額外服務(wù)。它使用客戶端直連數(shù)據(jù)庫，以 jar 包形式提供服務(wù)，無需額外部署和依賴，可理解為增強版的 JDBC 驅(qū)動，完全兼容 JDBC 和各種 ORM 框架。

定位為透明化的數(shù)據(jù)庫代理端，提供封裝了數(shù)據(jù)庫二進(jìn)制協(xié)議的服務(wù)端版本，用于完成對異構(gòu)語言的支持。目前已提供 MySQL 和 PostgreSQL 版本，它可以使用任何兼容 MySQL 和 PostgreSQL 協(xié)議的訪問客戶端 (如：MySQL Command Client, MySQL Workbench, Navicat 等) 操作數(shù)據(jù)，對 DBA 更加友好。

定位為 Kubernetes 的云原生數(shù)據(jù)庫代理，以 Sidecar 的形式代理所有對數(shù)據(jù)庫的訪問。通過無中心、零侵入的方案提供與數(shù)據(jù)庫交互的的嚙合層，即 Database Mesh，又可稱數(shù)據(jù)庫網(wǎng)格。

Sharding-JDBC 采用無中心化架構(gòu)，適用于 Java 開發(fā)的高性能的輕量級 OLTP 應(yīng)用；Sharding-Proxy 提供靜態(tài)入口以及異構(gòu)語言的支持，適用于 OLAP 應(yīng)用以及對分片數(shù)據(jù)庫進(jìn)行管理和運維的場景。

每種架構(gòu)方案都有其各自的優(yōu)缺點，下面表格對比了各種架構(gòu)模型的在不同場景下的優(yōu)劣：

Apache ShardingSphere 是多接入端共同組成的生態(tài)圈。通過混合使用 Sharding-JDBC 和 Sharding-Proxy，并采用同一配置中心統(tǒng)一配置分片策略，能夠靈活的搭建適用于各種場景的應(yīng)用系統(tǒng)，使得架構(gòu)師更加自由的調(diào)整適合與當(dāng)前業(yè)務(wù)的最佳系統(tǒng)架構(gòu)。

Apache ShardingSphere 采用 Share Nothing 架構(gòu)，它的 JDBC 和 Proxy 接入端均采用無狀態(tài)設(shè)計。作為計算節(jié)點，Apache ShardingSphere 負(fù)責(zé)對獲取的數(shù)據(jù)進(jìn)行最終的計算匯總。由于本身并不存儲數(shù)據(jù)，因此 Apache ShardingSphere 可以將計算下推至數(shù)據(jù)節(jié)點，以充分利用數(shù)據(jù)庫自身的計算能力。Apache ShardingSphere 可以通過增加部署節(jié)點數(shù)量來增加計算能力；增加數(shù)據(jù)庫節(jié)點數(shù)量來增加存儲能力。

數(shù)據(jù)分片、分布式事務(wù)、彈性伸縮和分布式治理是 Apache ShardingSphere 目前階段的 4 個最核心功能。

分而治之是 Apache ShardingSphere 用于處理海量數(shù)據(jù)的方案。Apache ShardingSphere 通過數(shù)據(jù)分片方案，使數(shù)據(jù)庫具備分布式存儲能力。

它可以將 SQL 根據(jù)用戶預(yù)置的分片算法自動路由至相應(yīng)的數(shù)據(jù)節(jié)點，以達(dá)到操作多個數(shù)據(jù)庫的目的。用戶可以像使用單機數(shù)據(jù)庫一樣使用被 Apache ShardingSphere 所管理的多個數(shù)據(jù)庫。目前支持 MySQL、PostgreSQL、Oracle、SQLServer 以及任何支持 SQL92 標(biāo)準(zhǔn)和 JDBC 標(biāo)準(zhǔn)協(xié)議的數(shù)據(jù)庫。數(shù)據(jù)分片的內(nèi)核流程見下圖：

主要流程如下：

1. 通過解析數(shù)據(jù)庫協(xié)議包或 JDBC 驅(qū)動獲取用戶輸入的 SQL 和參數(shù)；

2. 根據(jù)詞法分析器和語法分析器將 SQL 解析為 AST（抽象語法樹），并提取分片所需信息；

3. 根據(jù)用戶預(yù)置算法匹配分片鍵，并計算路由路徑；

4. 將 SQL 改寫為分布式可執(zhí)行 SQL；

5. 向各數(shù)據(jù)節(jié)點并行發(fā)送 SQL，執(zhí)行引擎負(fù)責(zé)連接池與內(nèi)存資源的平衡；

6. 根據(jù) AST 執(zhí)行流式或全量內(nèi)存結(jié)果集歸并計算；

7. 封裝數(shù)據(jù)庫協(xié)議包或 JDBC 結(jié)果集，并返回至客戶端。

事務(wù)是數(shù)據(jù)庫系統(tǒng)的最核心功能。分布式的不確定和事務(wù)的復(fù)雜性，決定了分布式事務(wù)領(lǐng)域無法出現(xiàn)放之四海而皆準(zhǔn)的方案。

面對百花齊放的現(xiàn)狀，Apache ShardingSphere 提供高度開放的方案，采用標(biāo)準(zhǔn)接口統(tǒng)一整合開發(fā)者自主選擇的第三方分布式事務(wù)框架，以滿足各種場景的應(yīng)用需求。除此之外，Apache ShardingSphere 還提供了全新的分布式事務(wù)解決方案 JDTX，來彌補現(xiàn)有方案的缺失。

Apache ShardingSphere 為本地事務(wù)、兩階段事務(wù)和柔性事務(wù)提供了統(tǒng)一的適配接口，并對接了大量的現(xiàn)有第三方的成熟解決方案。通過標(biāo)準(zhǔn)接口，開發(fā)者可以輕松的將其他整合方案融入到 Apache ShardingSphere 平臺中。

然而，融合大量第三方解決方案，卻不能覆蓋所有分布式事務(wù)需求分支。各種解決方案均有各自的適合及不適合場景。各解決方案間是互斥的，無法將它們的優(yōu)點疊加使用。針對于當(dāng)前最常見 2PC（兩階段提交）和柔性事務(wù)，分別存在著以下的優(yōu)勢和不足：

• 兩階段提交：基于 XA 協(xié)議實現(xiàn)的兩階段分布式事務(wù)對業(yè)務(wù)侵入很小。它最大的優(yōu)勢是對使用方透明，開發(fā)者可以像本地事務(wù)一樣使用基于 XA 協(xié)議的分布式事務(wù)。XA 協(xié)議能夠嚴(yán)格保障事務(wù) ACID 特性，但這也是一把雙刃劍。事務(wù)執(zhí)行在過程中需要將所需資源全部鎖定，它更加適用于執(zhí)行時間確定的短事務(wù)。對于長事務(wù)來說，整個事務(wù)進(jìn)行期間對資源的獨占，將導(dǎo)致對熱點數(shù)據(jù)依賴的業(yè)務(wù)系統(tǒng)并發(fā)性能衰退明顯。因此，在高并發(fā)的性能至上場景中，基于 XA 協(xié)議兩階段提交類型的分布式事務(wù)并不是最佳選擇。

• 柔性事務(wù)：如果將實現(xiàn)了 ACID 的事務(wù)要素的事務(wù)稱為剛性事務(wù)的話，那么基于 BASE 事務(wù)要素的事務(wù)則稱為柔性事務(wù)。BASE 是基本可用、柔性狀態(tài)和最終一致性這 3 個要素的縮寫。在 ACID 事務(wù)中對一致性和隔離性的要求很高，在事務(wù)執(zhí)行過程中，必須將所有的資源占用。柔性事務(wù)的理念則是通過業(yè)務(wù)邏輯將互斥鎖操作從資源層面上移至業(yè)務(wù)層面。通過放寬對強一致性和隔離性的要求，只要求當(dāng)整個事務(wù)最終結(jié)束的時候，數(shù)據(jù)是一致的。而在事務(wù)執(zhí)行期間，任何讀取操作得到的數(shù)據(jù)都有可能被改變。這種弱一致性的設(shè)計可以用來換取系統(tǒng)吞吐量的提升。

基于 ACID 的兩階段事務(wù)和基于 BASE 的最終一致性事務(wù)都不是銀彈，可通過下表詳細(xì)對比它們之間的區(qū)別。

缺乏并發(fā)度保障的兩階段事務(wù)不能稱之為完善的分布式事務(wù)解決方案；而缺乏對 ACID 原義支持的柔性事務(wù)都甚至不能稱之為數(shù)據(jù)庫事務(wù)，它更適合服務(wù)層的事務(wù)處理。

放眼當(dāng)前，實難找到無需權(quán)衡即可放之四海而皆準(zhǔn)的分布式事務(wù)解決方案。

JDTX 是京東數(shù)科自研的分布式事務(wù)中間件，尚未開源。它的設(shè)計目標(biāo)是強一致（支持 ACID 的事務(wù)原義）、高性能（不低于本地事務(wù)性能）、1PC（完全摒棄兩階段提交和兩階段鎖）的完全分布式事務(wù)中間件，目前可用于關(guān)系型數(shù)據(jù)庫。它采用完全開放 SPI 的設(shè)計方式，提供與 NoSQL 對接的可能，未來能夠?qū)⒍嘣悩?gòu)數(shù)據(jù)維持在同一事務(wù)中。

JDTX 通過完全自研的事務(wù)處理引擎，將 SQL 操作的事務(wù)中數(shù)據(jù)轉(zhuǎn)化為 KV（鍵值對），并在其基礎(chǔ)上實現(xiàn)了 MVCC（多版本快照）的事務(wù)可見性引擎，以及與數(shù)據(jù)庫設(shè)計理念類似的 WAL（預(yù)寫日志系統(tǒng)）存儲引擎。可以通過下面的架構(gòu)圖來了解一下 JDTX 的構(gòu)成：

它的設(shè)計特點是將在事務(wù)中的數(shù)據(jù)（稱之為活躍數(shù)據(jù)）和不在事務(wù)中的數(shù)據(jù)（稱之為落盤數(shù)據(jù)）分離?；钴S數(shù)據(jù)在落盤至 WAL 之后，再以 KV 的形態(tài)保存至 MVCC 內(nèi)存引擎中。落盤數(shù)據(jù)則是通過異步刷盤的方式，將 WAL 中的 REDO 日志，以流量可控的方式同步至最終的存儲介質(zhì)中（如：關(guān)系型數(shù)據(jù)庫）。事務(wù)內(nèi)存查詢引擎負(fù)責(zé)使用 SQL 從 KV 格式的活躍數(shù)據(jù)中檢索到相關(guān)數(shù)據(jù)，與落盤數(shù)據(jù)合并，并根據(jù)事務(wù)隔離級別獲取符合當(dāng)前事務(wù)可見的數(shù)據(jù)版本。

JDTX 以全新的架構(gòu)重新詮釋了數(shù)據(jù)庫的事務(wù)模型，主要亮點有：

1、內(nèi)化分布式事務(wù)為本地事務(wù)

JDTX 的 MVCC 引擎是一個集中式緩存。它能夠?qū)呻A段提交內(nèi)化至一階段提交，以維持單一節(jié)點中數(shù)據(jù)的原子性和一致性，即將分布式事務(wù)的范疇縮減到本地事務(wù)的范疇。JDTX 通過保證所有對事務(wù)數(shù)據(jù)的訪問都通過 MVCC 引擎的活躍數(shù)據(jù) + 最終數(shù)據(jù)端的落盤數(shù)據(jù)的合并的方式，以保證事務(wù)數(shù)據(jù)的原子性和一致性。

2、無損的事務(wù)隔離機制

以 MVCC 的方式實現(xiàn)事務(wù)隔離性。目前完整的支持 4 種標(biāo)準(zhǔn)隔離級別中的讀已提交和可重復(fù)讀，已經(jīng)可以滿足絕大部分需求。

3、高性能

采用將活躍數(shù)據(jù)異步刷盤至存儲介質(zhì)的方式，極大地提高了數(shù)據(jù)寫入的性能上限。它的性能瓶頸從數(shù)據(jù)庫寫入耗時轉(zhuǎn)移到了落盤至 WAL 和 MVCC 引擎的耗時。

與數(shù)據(jù)庫的 WAL 系統(tǒng)類似，JDTX 的 WAL 也采用順序日志追加的方式，因此可以簡單的理解為 JDTX 的 WAL 耗時 = 數(shù)據(jù)庫系統(tǒng)的 WAL 耗時。而 MVCC 引擎則采用 KV 數(shù)據(jù)結(jié)構(gòu)，其寫入耗時小于維護 BTree 索引的數(shù)據(jù)庫。因此，JDTX 的數(shù)據(jù)更新性能的上限甚至可以高于不開啟事務(wù)。

4、高可用

WAL 和 MVCC 引擎均可以通過主備 + 分片的方式維持高可用和水平擴展的能力。在 MVCC 引擎完全不可用的情況下，可通過恢復(fù)模式將 WAL 中的數(shù)據(jù)同步至數(shù)據(jù)庫，以保證數(shù)據(jù)的完整性。

5、跨多元數(shù)據(jù)庫事務(wù)

將事務(wù)活躍數(shù)據(jù)和落盤數(shù)據(jù)分離的設(shè)計方案，使其落盤數(shù)據(jù)存儲端無任何限制。由于事務(wù)活躍數(shù)據(jù)通過異步的落盤執(zhí)行器存儲至后端存儲介質(zhì)，因此后端是否為同構(gòu)數(shù)據(jù)庫，其實并無影響。使用 JDTX 能夠保證跨多元存儲端（如：MySQL、PostgreSQL，甚至是 MongoDB、Redis 等 NoSQL）的分布式事務(wù)維持在同一事務(wù)語義之中。

通過 Apache ShardingSphere 提供的分布式事務(wù)統(tǒng)一適配接口，可以將 JDTX 像其他第三方分布式事務(wù)解決方案一樣輕松地融入 Apache ShardingSphere 生態(tài)，將數(shù)據(jù)分片與分布式事務(wù)無縫結(jié)合，使它們具備組成分布式數(shù)據(jù)庫基礎(chǔ)設(shè)施的能力。架設(shè)在產(chǎn)品最前端的 Apache ShardingSphere 用于 SQL 解析、數(shù)據(jù)庫協(xié)議和數(shù)據(jù)分片；位于中層的 JDTX 用于通過 KV 和 MVCC 的方式處理事務(wù)活躍數(shù)據(jù)；最底層的數(shù)據(jù)庫則僅作為最終的數(shù)據(jù)存儲端。下圖是 ShardingSphere + JDTX 的架構(gòu)圖。

可以說，JDTX 的存在，使得 Apache ShardingSphere 打破了穩(wěn)定型的數(shù)據(jù)庫中間件的定位，在保持穩(wěn)定的同時，逐步向進(jìn)取型 NewSQL 發(fā)展。

與無狀態(tài)的服務(wù)化應(yīng)用不同，數(shù)據(jù)節(jié)點中均持有不可丟失的重要用戶數(shù)據(jù)。當(dāng)數(shù)據(jù)節(jié)點的容量不足以承擔(dān)快速增長的業(yè)務(wù)時，數(shù)據(jù)節(jié)點的擴容則在所難免。根據(jù)用戶預(yù)置的分片策略不同，擴容的策略也會隨之不同。

彈性伸縮可以讓被 Apache ShardingSphere 所管理的數(shù)據(jù)庫在不停止對外服務(wù)的情況下進(jìn)行擴容和縮容。彈性伸縮分為彈性遷移和范圍擴容兩個組件，目前它們均在孵化中。

數(shù)據(jù)遷移是面向用戶定制分片策略的標(biāo)準(zhǔn)擴縮容方案。在遷移過程中，需要準(zhǔn)備兩套數(shù)據(jù)節(jié)點。原數(shù)據(jù)節(jié)點在繼續(xù)提供服務(wù)的同時，將數(shù)據(jù)以存量和增量的方式，分別寫入新數(shù)據(jù)節(jié)點。整個遷移過程無需停止對外服務(wù)，可以平順的過渡新舊數(shù)據(jù)節(jié)點。Apache ShardingSphere 還將提供工作流界面，讓遷移過程完全自主可控。彈性遷移的架構(gòu)圖如下：

具體流程如下：

1. 通過配置中心修改數(shù)據(jù)分片配置，以觸發(fā)遷移流程。

2. 記錄當(dāng)前遷移數(shù)據(jù)開啟前的位點之后，開啟歷史遷移作業(yè)，分批遷移全量數(shù)據(jù)。

3. 開啟 Binlog 訂閱作業(yè)，遷移位點之后的增量數(shù)據(jù)。

4. 根據(jù)采樣率設(shè)置比對數(shù)據(jù)。

5. 設(shè)置原數(shù)據(jù)源只讀，確保實時數(shù)據(jù)遷移完成。

6. 將應(yīng)用連接切換至新數(shù)據(jù)源。

7. 舊數(shù)據(jù)源下線。

遷移時長根據(jù)數(shù)據(jù)量的大小可能是幾分鐘至幾周不等。遷移過程中可以隨時回退或重新遷移。整個遷移流程完全自主可控，降低遷移過程中的風(fēng)險；并且通過自動化工具完全屏蔽人工操作，避免繁瑣的操作帶來的巨大工作量。

如果彈性遷移稱之為硬伸縮的話，那么范圍擴容則稱之為軟伸縮。Apache ShardingSphere 的范圍擴容不涉及內(nèi)核改造，也無需遷移數(shù)據(jù)，它只需通過優(yōu)化范圍分片策略，即可達(dá)到自動擴（縮）容的目標(biāo)。使用范圍擴容，用戶無需感知分片策略和分片鍵等分庫分表方案中必要概念，讓 Apache ShardingSphere 更加接近一體化的分布式數(shù)據(jù)庫。

使用范圍擴容的用戶，只需向 Apache ShardingSphere 提供數(shù)據(jù)庫資源池。容量巡檢器會在表容量到達(dá)閾值時，從資源池中依次尋找下一個數(shù)據(jù)節(jié)點，并在新數(shù)據(jù)節(jié)點創(chuàng)建新表之后，修改分片策略的范圍元數(shù)據(jù)。當(dāng)資源池中沒有新數(shù)據(jù)節(jié)點后，Apache ShardingSphere 會按照同樣的順序，在已經(jīng)創(chuàng)建過表的數(shù)據(jù)庫中增加新表。當(dāng)表數(shù)據(jù)大量刪除時，之前的數(shù)據(jù)節(jié)點的數(shù)據(jù)將不再緊湊，垃圾回收器會定時壓縮表范圍，以釋放更多的碎片空間。范圍擴容的結(jié)構(gòu)如下：

Apache ShardingSphere 為不同的應(yīng)用場景，提供了更加靈活的彈性伸縮策略。目前仍在孵化中的兩個彈性伸縮相關(guān)的項目，也力爭盡快提供試用版本。

治理模塊的設(shè)計目標(biāo)是為了更好管理和使用分布式數(shù)據(jù)庫。

與所有的分布式系統(tǒng)的設(shè)計理念一脈相承，分而治之同樣是分布式數(shù)據(jù)庫的指導(dǎo)方針。數(shù)據(jù)庫治理能力的存在，能夠讓管理成本不隨著數(shù)據(jù)庫實例數(shù)目的增長而提升。

Apache ShardingSphere 使用配置中心來管理配置，可以在配置修改后的極短時間內(nèi)傳播到所有的接入端實例。配置中心采用開放的 SPI 方式，能夠充分利用配置中心自身的能力，如配置多版本變更等。

Apache ShardingSphere 使用注冊中心管理接入端實例和數(shù)據(jù)庫實例的運行狀態(tài)。注冊中心同樣采用配置中心的開放 SPI 方式。部分注冊中心的實現(xiàn)可以涵蓋配置中心的能力，因此用戶可以疊加使用注冊中心和配置中心的能力。

Apache ShardingSphere 提供了數(shù)據(jù)庫實例禁用和接入端熔斷的能力，分別用于處理數(shù)據(jù)庫實例不可用和接入端被大流量沖擊的場景。

Apache ShardingSphere 目前正在孵化高可用的 SPI，讓用戶能夠復(fù)用數(shù)據(jù)庫自身提供的高可用方案。目前正在對接 MySQL 的 MGR 高可用方案。Apache ShardingSphere 可以通過自動探知 MGR 的選舉變化并快速傳播至所有的應(yīng)用實例。

大量數(shù)據(jù)庫和接入端實例，使得 DBA 和運維人員無法迅速感知當(dāng)前系統(tǒng)的狀況。Apache ShardingSphere 通過對 OpenTracing 協(xié)議的實現(xiàn)，將監(jiān)控數(shù)據(jù)發(fā)送至實現(xiàn)其協(xié)議的第三方 APM 系統(tǒng)中；除此之外，Apache ShardingSphere 還提供了 Apache SkyWalking 的自動探針，可以讓使用它作為可觀察性產(chǎn)品的用戶直接觀測到 Apache ShardingSphere 的性能、調(diào)用鏈關(guān)系以及系統(tǒng)的整體拓?fù)鋱D。

得益于 Apache ShardingSphere 對 SQL 靈活的處理能力和對數(shù)據(jù)庫協(xié)議的高度兼容性，數(shù)據(jù)相關(guān)的治理能力也被很方便的加入到了產(chǎn)品生態(tài)中。

Apache ShardingSphere 可以讓用戶在無需修改代碼的情況下，自動將指定的數(shù)據(jù)列加密后存儲至數(shù)據(jù)庫，并在應(yīng)用程序獲取數(shù)據(jù)時解密，以保證數(shù)據(jù)的安全。當(dāng)數(shù)據(jù)庫的數(shù)據(jù)被不慎泄露時，敏感數(shù)據(jù)信息由于被完全加密，從而不會造成更大的安全隱患。

Apache ShardingSphere 可以在系統(tǒng)進(jìn)行全鏈路壓測時，自動將用戶標(biāo)記的數(shù)據(jù)路由至影子庫（表）。影子庫（表）壓測功能可以讓線上壓測成為常態(tài)，用戶無需在關(guān)心壓測數(shù)據(jù)的清理。此項功能也正在高速的孵化中。

如您所見，Apache ShardingSphere 正處于高速發(fā)展的軌道中，越來越多與“分庫分表”這條曾經(jīng)主線并無強關(guān)聯(lián)的功能被加入其中。但這些產(chǎn)品功能卻并不突兀，它們反而能助力 Apache ShardingSphere 成為更加多元化的分布式數(shù)據(jù)庫解決方案。Apache ShardingSphere 未來的線路主要會集中在以下幾點。

越來越多的零散功能需要進(jìn)一步梳理。Apache ShardingSphere 現(xiàn)有的架構(gòu)還不足以完全吸收如此廣泛的產(chǎn)品功能。彈性化的功能可插拔平臺是 Apache ShardingSphere 未來架構(gòu)的調(diào)整方向。

可插拔平臺會將 Apache ShardingSphere 從技術(shù)和功能兩方面完全拆開。Apache ShardingSphere 的全景圖如下所示：

Apache ShardingSphere 會根據(jù)技術(shù)架構(gòu)橫向分為 4 層，分別是接入層、SQL 解析層、內(nèi)核處理層和存儲訪問層；并且將功能以可插拔的形態(tài)融入至 4 層架構(gòu)中。

Apache ShardingSphere 對數(shù)據(jù)庫類型的支持將完全開放，除了關(guān)系型數(shù)據(jù)庫，NoSQL 也會完全開放支持，數(shù)據(jù)庫方言互不影響，完全解耦。在功能方面，Apache ShardingSphere 采用疊加式架構(gòu)模型，使各個功能可以靈活的組合使用。每個功能模塊只需關(guān)注自身的核心功能，由 Apache ShardingSphere 架構(gòu)負(fù)責(zé)功能的疊加組合使用。即使沒有任何功能，Apache ShardingSphere 也可以作為一個空白的接入端直接啟動，為開發(fā)者的定制化開發(fā)提供腳手架以及 SQL 解析等基礎(chǔ)設(shè)施。融入 Apache ShardingSphere 生態(tài)的數(shù)據(jù)庫，將直接獲得平臺提供的所有基礎(chǔ)能力；在 Apache ShardingSphere 平臺上開發(fā)的功能，也將直接獲得已接入平臺的數(shù)據(jù)庫類型的全部支持。數(shù)據(jù)庫類型和功能類型將以相乘的方式排列組合，基礎(chǔ)設(shè)施 + 樂高的組合，將為 Apache ShardingSphere 提供各種想象和提升的空間。

目前 Apache ShardingSphere 只是將 SQL 通過正確的路由和改寫，分發(fā)至相應(yīng)的數(shù)據(jù)庫以操作數(shù)據(jù)。計算下發(fā)能夠充分利用的數(shù)據(jù)庫的查詢引擎，但無法有效的支持復(fù)雜關(guān)聯(lián)查詢和子查詢?；陉P(guān)系代數(shù)實現(xiàn)的 SQL on KV 查詢引擎隨著 JDTX 的開發(fā)日臻成熟，將其積累的經(jīng)驗反哺于 SQL 查詢引擎，能夠讓 Apache ShardingSphere 更好的支持子查詢和跨庫關(guān)聯(lián)查詢等復(fù)雜查詢。

分布式數(shù)據(jù)庫所需要的多數(shù)據(jù)副本能力目前的 Apache ShardingSphere 還未具備。未來 Apache ShardingSphere 將提供基于 Raft 的多副本寫入能力。

上文中提到的 Sharding-Sidecar 接入端，是 Apache ShardingSphere 未來的第三個接入端形態(tài)，旨在更好的與 Kubernetes 配合，打造云原生數(shù)據(jù)庫。

Database Mesh 的關(guān)注重點在于如何將分布式的數(shù)據(jù)訪問應(yīng)用與數(shù)據(jù)庫有機串聯(lián)起來，它更加關(guān)注的是交互，是將雜亂無章的應(yīng)用與數(shù)據(jù)庫之間的交互有效的梳理。使用 Database Mesh，訪問數(shù)據(jù)庫的應(yīng)用和數(shù)據(jù)庫終將形成一個巨大的網(wǎng)格體系，應(yīng)用和數(shù)據(jù)庫只需在網(wǎng)格體系中對號入座即可，它們都是被嚙合層所治理的對象。

支持更多的數(shù)據(jù)庫類型之后，Apache ShardingSphere 會將工作重點放在多元異構(gòu)的數(shù)據(jù)庫類型的統(tǒng)一查詢引擎之上。除此之外，Apache ShardingSphere 還將配合 JDTX，將更加多元的數(shù)據(jù)存儲介質(zhì)納入到同一事務(wù)中。

Apache ShardingSphere 在 2016 年 1 月 17 日在 GitHub 平臺首次開源，開源項目的初始名稱是 Sharding-JDBC。在 2018 年 11 月 10 日，ShardingSphere 改名并正式進(jìn)入 Apache 軟件基金會的孵化器。

在開源至今走過的 4 年里程中，Apache ShardingSphere 的架構(gòu)模型在不斷的演進(jìn)的同時，整體產(chǎn)品的功能范圍也在急速地擴張。它從開源之初的分庫分表 Java 開發(fā)框架，逐漸演化為分布式數(shù)據(jù)庫解決方案。

隨著 Apache ShardingSphere 的生態(tài)圈的擴張，由少數(shù)開發(fā)者掌控項目的狀態(tài)早已被打破。目前的 Apache ShardingSphere 有近百名貢獻(xiàn)者，以及近 20 名核心提交者，他們共同打造著這個遵循著 Apache Way 的社區(qū)。Apache ShardingSphere 是一個標(biāo)準(zhǔn)的 Apache 軟件基金會開源項目，并不受某一商業(yè)公司或某幾位核心開發(fā)者掌控。

目前有超過 100 家公司明確的聲明他們在使用 Apache ShardingSphere，讀者可以從官方網(wǎng)站找到采用公司的用戶墻。

隨著社區(qū)的成熟，Apache ShardingSphere 的成長也越來越迅速。我們誠邀感興趣的開發(fā)者一同參與到 Apache ShardingSphere 社區(qū)中，完善不斷擴大的生態(tài)。

關(guān)于怎樣打造一款分布式數(shù)據(jù)庫問題的解答就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關(guān)注億速云行業(yè)資訊頻道了解更多相關(guān)知識。