關(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)架于單機(jī)系統(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ù)存儲不受單機(jī)磁盤容量限制，可通過增加數(shù)據(jù)服務(wù)器的數(shù)量提升存儲能力；

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

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

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

• 多數(shù)據(jù)副本：自動將數(shù)據(jù)以強(qiáng)一致、高性能的方式復(fù)制至跨機(jī)房的多個副本，以保證數(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)定性的缺失和運(yùn)維經(jīng)驗的不足；穩(wěn)定型的實現(xiàn)方案是指在現(xiàn)有數(shù)據(jù)庫的基礎(chǔ)上提供增量能力的中間件。這類產(chǎn)品則以犧牲部分性能以保證數(shù)據(jù)庫的穩(wěn)定性和運(yù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ù)，無需額外部署和依賴，可理解為增強(qiáng)版的 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)行管理和運(yù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ù)庫的目的。用戶可以像使用單機(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，來彌補(bǔ)現(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ù)層面。通過放寬對強(qiáng)一致性和隔離性的要求，只要求當(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)是強(qiáng)一致（支持 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ù)）分離。活躍數(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ù)隔離機(jī)制

以 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)，其寫入耗時小于維護(hù) BTree 索引的數(shù)據(jù)庫。因此，JDTX 的數(shù)據(jù)更新性能的上限甚至可以高于不開啟事務(wù)。

4、高可用

WAL 和 MVCC 引擎均可以通過主備 + 分片的方式維持高可用和水平擴(kuò)展的能力。在 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é)點的擴(kuò)容則在所難免。根據(jù)用戶預(yù)置的分片策略不同，擴(kuò)容的策略也會隨之不同。

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

數(shù)據(jù)遷移是面向用戶定制分片策略的標(biāo)準(zhǔn)擴(kuò)縮容方案。在遷移過程中，需要準(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)險；并且通過自動化工具完全屏蔽人工操作，避免繁瑣的操作帶來的巨大工作量。

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

使用范圍擴(kuò)容的用戶，只需向 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ù)將不再緊湊，垃圾回收器會定時壓縮表范圍，以釋放更多的碎片空間。范圍擴(kuò)容的結(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ù)庫實例的運(yùn)行狀態(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 和運(yùn)維人員無法迅速感知當(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)主線并無強(qiá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)查詢和子查詢。基于關(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ù)庫有機(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)品的功能范圍也在急速地擴(kuò)張。它從開源之初的分庫分表 Java 開發(fā)框架，逐漸演化為分布式數(shù)據(jù)庫解決方案。

隨著 Apache ShardingSphere 的生態(tài)圈的擴(kuò)張，由少數(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ū)中，完善不斷擴(kuò)大的生態(tài)。

項目地址：

https://github.com/apache/incubator-shardingsphere