經過近兩年時間的最佳化和打磨，Apache ShardingSphere 5。0。0 GA 版終於在本月正式釋出，相比於 4。1。1 GA 版，5。0。0 GA 版在核心層面進行了大量的最佳化。首先，基於可插拔架構對核心進行了全面改造，核心中的各個功能可以任意組合併疊加使用。其次，為了提升 SQL 分散式查詢能力，5。0。0 GA 版打造了全新的Federation 執行引擎，來滿足使用者複雜的業務場景。此外，5。0。0 GA 版在核心功能 API 層面也進行了大量最佳化，旨在降低使用者使用這些功能的成本。本文將為大家詳細解讀 5。0。0 GA 版中的這些重大核心最佳化，並將對比兩個 GA 版本中存在的差異，以典型的資料分片、讀寫分離和加解密整合使用的場景為例，幫助使用者更好地理解這些最佳化並完成版本升級。
端正強
SphereEx 高階中介軟體開發工程師，Apache ShardingSphere Committer。
2018 年開始接觸 Apache ShardingSphere 中介軟體，曾主導公司內部海量資料的分庫分表，有著豐富的實踐經驗；熱愛開源，樂於分享，目前專注於 Apache ShardingSphere 核心模組開發。
可拔插架構核心
Apache ShardingSphere 5。0。0 GA 版提出了全新的 Database Plus 理念，目標是構建異構資料庫上層標準和生態，為使用者提供精準化和差異化的能力。Database Plus 具有連線、增量、可插拔的特點，具體來說，Apache ShardingSphere 能夠連線不同的異構資料庫，基於異構資料庫的基礎服務，提供資料分片、資料加解密及分散式事務等增量功能。另外，透過可插拔平臺，Apache ShardingSphere 提供的增量功能能夠無限擴充套件，使用者也可以根據需求靈活進行擴充套件。Database Plus 理念的出現，使得 ShardingSphere 真正意義上從一個分庫分表中介軟體蛻變成為一套強大的分散式資料庫生態系統。透過踐行 Database Plus 理念，基於可插拔平臺提供的擴充套件點，Apache ShardingSphere 核心也進行了全面地可插拔化改造。
下圖展示了全新的可插拔架構核心：
Apache ShardingSphere 核心流程中的
元資料載入、SQL 解析、SQL 路由 、SQL 改寫、SQL 執行和結果歸併，都提供了豐富的擴充套件點，
基於這些擴充套件點，Apache ShardingSphere
預設實現了資料分片、讀寫分離、加解密、影子庫壓測及高可用等功能。
按照擴充套件點是基於技術還是基於功能實現，我們可以將擴充套件點劃分為功能擴充套件點和技術擴充套件點。Apache ShardingSphere 核心流程中，SQL 解析引擎及 SQL 執行引擎的擴充套件點屬於技術擴充套件點，而元資料載入、SQL 路由引擎、SQL 改寫引擎及結果歸併引擎的擴充套件點屬於功能擴充套件點。
SQL 解析引擎擴充套件點，主要包括 SQL 語法樹解析及 SQL 語法樹遍歷兩個擴充套件點。Apache ShardingSphere 的 SQL 解析引擎，基於這兩個擴充套件點，預設支援了 MySQL、PostgreSQL、Oracle、SQLServer、openGauss 和 SQL92 等資料庫方言的解析和遍歷。
使用者也可以基於這兩個擴充套件點，實現 Apache ShardingSphere SQL 解析引擎暫不支援的資料庫方言，以及開發諸如 SQL 審計這樣的新功能。
SQL 執行引擎擴充套件點按照不同的執行方式來提供擴充套件，
目前 Apache ShardingSphere SQL 執行引擎已經提供了單執行緒執行引擎和多執行緒執行引擎。
單執行緒執行引擎主要用於處理包含事務的語句執行，多執行緒執行引擎則適用於不包含事務的場景，用於提升 SQL 執行的效能。未來，Apache ShardingSphere 將基於執行引擎擴充套件點，提供諸如 MPP 執行引擎在內的更多執行引擎，滿足分散式場景下 SQL 執行的要求。
基於功能擴充套件點，Apache ShardingSphere 提供了資料分片、讀寫分離、加解密、影子庫壓測及高可用等功能，這些功能根據各自需求，實現了全部或者部分功能擴充套件點，並且在功能內部，又透過細化功能級擴充套件點提供了諸如分片策略、分散式 ID 生成及負載均衡演算法等內部擴充套件點。下面是 Apache ShardingSphere 核心功能實現的擴充套件點：
資料分片：
實現了元資料載入、SQL 路由、SQL 改寫和結果歸併的全部功能擴充套件點，在資料分片功能內部，又提供了分片演算法、分散式 ID 等擴充套件點；
讀寫分離：
實現了 SQL 路由的功能擴充套件點，功能內部提供了負載均衡演算法擴充套件點；
加解密：
實現了元資料載入、SQL 改寫和結果歸併的擴充套件點，內部提供了加解密演算法擴充套件點；
影子庫壓測：
實現了 SQL 路由的擴充套件點，在影子庫壓測功能內部，提供了影子演算法擴充套件點；
高可用：
實現了 SQL 路由的擴充套件點。
基於這些擴充套件點，Apache ShardingSphere 功能的可擴充套件空間非常大，
像多租戶和 SQL 審計等功能，都可以透過擴充套件點無縫地整合到 Apache ShardingSphere 生態中。
此外，使用者也可以根據自己的業務需求，基於擴充套件點完成定製化功能開發，快速地搭建出一套分散式資料庫系統。關於可插拔架構擴充套件點的詳細說明，可以參考
官網開發者手冊
：
https：//shardingsphere。apache。org/document/current/cn/dev-manual/
綜合對比來看，5。0。0 GA 版可插拔架構核心和 4。1。1 GA 版核心主要的差異如下：
首先，從專案定位上來看，5。0。0 GA 版藉助可插拔架構實現了從分庫分表中介軟體到分散式資料庫生態系統的轉變，各個功能都可以透過可插拔架構融入到分散式資料庫生態系統中。其次，從專案功能上來看，4。1。1 GA 版只提供一些基礎功能，而 5。0。0 GA 版則更加側重於提供基礎設施，以及一些功能的最佳實踐，使用者完全可以捨棄這些功能，基於核心基礎設施開發定製化功能。
從功能耦合的角度來看，5.0.0 GA 版的核心功能，做到了相互隔離，互無感知，這樣可以最大程度地保證核心的穩定性。最後，從功能組合使用的角度來看，5.0.0 GA 版實現了功能的層級一致，資料分片、讀寫分離、影子庫壓測、加解密和高可用等功能，可以按照使用者的需求任意組合。
而在 4。1。1 GA 版中，使用者在組合使用這些功能時，必須以資料分片為中心，再疊加使用其他功能。
透過這些對比可以看出， 5。0。0 GA 版可插拔核心進行了全方位地增強，使用者可以像搭積木一樣對功能進行疊加組合，從而滿足更多業務需求。但是，可插拔架構的調整也導致了核心功能的使用方式出現了很大的變化，在文章的後續內容中，我們會透過例項來詳細介紹在 5。0。0 GA 版中如何組合使用這些功能。
Federation 執行引擎
Federation 執行引擎是 5。0。0 GA 版核心的又一大亮點功能，目標是支援那些在 4。1。1 GA 版中無法執行的分散式查詢語句，例如：跨資料庫例項的關聯查詢及子查詢。
Federation 執行引擎的出現，使得業務研發人員不必再關心 SQL 的使用範圍，能夠專注於業務功能開發，減少了業務層面的功能限制。
上圖展示了 Federation 執行引擎的處理流程，總體上來看，仍然是遵循著 SQL 解析、SQL 路由、SQL 改寫、SQL 執行這幾個步驟，唯一的區別是 Federation 執行引擎額外引入了 SQL 最佳化，對分散式查詢語句進行 RBO（Rule Based Optimizer） 和 CBO（Cost Based Optimizer） 最佳化，從而得到代價最小的執行計劃。在 SQL 路由階段，路由引擎會根據 SQL 語句是否跨多個數據庫例項，來決定 SQL 是否透過 Federation 執行引擎來執行。
Federation 執行引擎目前處於快速開發中，仍然需要大量的最佳化，還是一個實驗性的功能，因此預設是關閉的，如果想要體驗 Federation 執行引擎，可以透過配置
sql-federation-enabled: true
來開啟該功能。
Federation 執行引擎主要用來支援跨多個數據庫例項的關聯查詢和子查詢，以及部分核心不支援的聚合查詢。
下面我們透過具體的場景，來了解下 Federation 執行引擎支援的語句。
跨庫關聯查詢：
當關聯查詢中的多個表分佈在不同的資料庫例項上時，由 Federation 執行引擎提供支援。
例如，在下面的資料分片配置中，
t_order
和
t_order_item
表是多資料節點的分片表，並且未配置繫結表規則，
t_user
和
t_user_role
則是分佈在不同的資料庫例項上的單表。
由於跨多個數據庫例項，下面這些常用的 SQL，會使用 Federation 執行引擎進行關聯查詢。
子查詢：
Apache ShardingSphere 的 Simple Push Down 引擎能夠支援分片條件一致的子查詢，以及路由到單個分片的子查詢。對於子查詢和外層查詢未同時指定分片鍵，或分片鍵的值不一致的場景，需要由 Federation 執行引擎來提供支援。
下面展示了一些由 Federation 執行引擎支援的子查詢場景：
聚合查詢：
對於 Apache ShardingSphere Simple Push Down 引擎暫不支援的一些聚合查詢，我們也同樣透過 Federation 執行引擎提供了支援。
Federation 執行引擎的出現，使得 Apache ShardingSphere 分散式查詢能力得到明顯增強，未來 Apache ShardingSphere 將持續最佳化，有效降低 Federation 執行引擎的記憶體佔用，不斷提升分散式查詢的能力。關於 Federation 執行引擎支援語句的詳細清單，可參考官方文件中的
實驗性支援的 SQL
：
https：//shardingsphere。apache。org/document/5。0。0/cn/features/sharding/use-norms/sql/
核心功能 API 調整
為了降低使用者使用核心功能的成本，5。0。0 GA 版在 API 層面也進行了大量的最佳化。首先，針對社群反饋較多的資料分片 API 過於複雜、難以理解的問題，經過社群充分討論之後，在 5。0。0 GA 版中提供了全新的資料分片 API。同時，隨著 Apache ShardingSphere 專案定位的變化——由傳統資料庫中介軟體蛻變為分散式資料庫生態系統，實現透明化的資料分片功能也變得越發重要。因此，
5.0.0 GA 版提供了自動化的分片策略，使用者無需關心分庫分表的細節，透過指定分片數即可實現自動分片。
此外，由於可插拔架構的提出，以及影子庫壓測等功能的進一步增強，核心功能 API 都進行了相應的最佳化調整。下面我們將會從不同功能的角度，為大家詳細介紹 5。0。0 GA 版 API 層面的調整。
資料分片 API 調整
在 4。x 版中，社群經常反饋資料分片的 API 過於複雜，難以理解。下面是 4。1。1 GA 版中的資料分片配置，分片策略包含了
standard
、
complex
、
inline
、
hint
和
none
5 種策略，不同的分片策略之間引數也大不相同，導致普通使用者很難理解和使用。
5。0。0 GA 版對分片 API 中的分片策略進行了簡化，首先去除了原有的
inline
策略，只保留了
standard
、
complex
、
hint
和
none
這四個分片策略，同時將分片演算法從分片策略中抽取出來，放到
shardingAlgorithms
屬性下進行單獨配置，分片策略中透過指定
shardingAlgorithmName
屬性進引用即可。
上面是根據 4。1。1 GA 版分片配置修改後的配置，可以看出新的分片 API 更加簡潔清晰。同時為了減少使用者的配置量，Apache ShardingSphere 提供了眾多內建分片演算法供使用者選擇，使用者也可以透過CLASS_BASED分片演算法進行自定義。更多關於內建分片演算法的內容，可以參考官方文件
內建演算法-分片演算法
：
https：//shardingsphere。apache。org/document/5。0。0/cn/user-manual/shardingsphere-jdbc/configuration/built-in-algorithm/sharding/
除了最佳化資料分片 API 之外，為了能夠實現透明化資料分片，5。0。0 GA 版還提供了自動化的分片策略。下面展示了自動化分片策略配置和手動宣告分片策略配置的差異：
自動化分片策略，需要配置在
autoTables
屬性下，使用者只需要指定資料儲存的資料來源，同時透過自動分片演算法指定分片數即可，不再需要透過
actualDataNodes
來手動宣告資料分佈，也無需專門設定分庫策略和分表策略，Apache ShardingSphere 將自動實現資料分片管理。
此外，5。0。0 GA 版刪除了資料分片 API 中的
defaultDataSourceName
配置。在 5。0。0 GA 版中，Apache ShardingSphere 定位為分散式資料庫生態系統，使用者可以像使用傳統資料庫一樣，直接使用 Apache ShardingSphere 提供的服務，因此使用者無需感知底層的資料庫儲存。Apache ShardingSphere 透過內建的
SingleTableRule
來管理資料分片之外的單表，幫助使用者實現單表的自動載入和路由。
5。0。0 GA 版為了進一步簡化使用者配置，同時配合資料分片 API 中的 defaultDatabaseStrategy 和 defaultTableStrategy 分片策略，增加了 defaultShardingColumn 配置，作為預設的分片鍵。當多個表分片鍵相同時，使用者可以不配置 shardingColumn，使用預設的 defaultShardingColumn 配置。下面的分片配置中，t_order 表的分片策略都會使用預設的 defaultShardingColumn 配置。
讀寫分離 API 調整
讀寫分離 API 的基本功能，在 5。0。0 GA 版變化不大，只是由
MasterSlave
調整為
ReadWriteSplitting
，其他用法基本相同。下面是 4。1。1 GA 版和 5。0。0 GA 版讀寫分離 API 的對比。
此外，在 5。0。0 GA 版中，基於可插拔架構開發了高可用功能，讀寫分離可以配合高可用功能，提供能夠自動切換主從的高可用版讀寫分離，歡迎大家關注高可用功能後續的官方文件及技術分享。
加解密 API 調整
5。0。0 GA 版對於加解密 API 進行了小幅度最佳化，增加了
table
級別的
queryWithCipherColumn
屬性，方便使用者能夠對加解密欄位的明文、密文切換進行表級別的控制，其他配置和 4。1。1 GA 版基本保持一致。
影子庫壓測 API 調整
影子庫壓測 API，在 5。0。0 GA 版中進行了全面調整，首先刪除了影子庫中的邏輯列，並增加了功能強大的影子庫匹配演算法，用來幫助使用者實現更加靈活的路由控制。下面是 4。1。1 GA 版影子庫壓測的 API，總體上功能較為簡單，根據邏輯列對應的值判斷是否開啟影子庫壓測。
5。0。0 GA 版中影子庫壓測 API 則更加強大，使用者可以透過
enable
屬性，控制是否開啟影子庫壓測，同時可以按照表的維度，細粒度控制需要進行影子庫壓測的生產表，並支援多種不同的匹配演算法，例如：列值匹配演算法、列正則表示式匹配演算法以及 SQL 註釋匹配演算法。
在後續的技術分享文章中，我們會對影子庫壓測功能進行詳細介紹，此處就不展開說明，更多影子庫匹配演算法可以參考官方文件
影子演算法
：
https：//shardingsphere。apache。org/document/5。0。0/cn/user-manual/shardingsphere-jdbc/configuration/built-in-algorithm/shadow/
5。0。0 GA 升級指南
前面分別從可插拔核心架構、Federation 執行引擎以及核心功能 API 調整三個方面，詳細地介紹了 5。0。0 GA 版核心的重大最佳化。面對兩個版本存在的眾多差異，
大家最關心的莫過於如何從 4.1.1 GA 升級到 5.0.0 GA 版本？
下面我們將基於資料分片、讀寫分離和加解密整合使用這樣一個典型的場景，詳細介紹下升級 5。0。0 GA 版本需要注意哪些問題。
在 4。1。1 GA 中，組合使用多個功能時，必須以資料分片為基礎，然後疊加讀寫分離和加解密，因此 4。1。1 GA 版中的配置通常如下：
從上面的配置檔案中可以看出，t_order 和 t_order_item配置了分片規則，並且t_order 表的 content欄位同時設定了加解密規則，使用 AES 演算法進行加解密。t_user則是未分片的普通表，telephone欄位也配置了加解密規則。另外需要注意的是，讀寫分離規則和加解密規則都是以屬性的形式，配置在分片規則中，這也是 4。1。1 GA 中功能依賴的具體體現，其他功能都必須以資料分片為基礎。
配置完成之後，我們啟動 4。1。1 GA 版 Proxy 接入端，對 t_order、t_order_item 及 t_user表進行初始化。初始化語句執行的結果如下：
t_order
表分片功能路由改寫正常，但加解密功能對應的改寫沒有能夠支援，因為 4。1。1 GA 版本不支援加解密場景下 DDL 語句的改寫，因此，需要使用者在底層資料庫上提前建立好對應的加解密表，
DDL 語句支援加解密改寫在 5.0.0 GA 版已經完美支援，減少了使用者不必要的操作。
t_order_item
表由於不涉及加解密，路由改寫的結果正常。
t_user
表同樣存在加解密 DDL 語句改寫的問題，並且
t_user
表被路由到了
ds_0
資料來源，這是因為我們在分片規則中配置了
defaultDataSourceName: ds_0
，所以對於非分片表，都會使用這個規則進行路由。
對於
t_order
表和
t_user
表，我們透過如下 SQL 在路由結果對應的底層資料庫上，手動建立加解密表。
我們重啟 Proxy 並向
t_order
、
t_order_item
和
t_user
表新增資料。
t_order
和
t_order_item
表在插入資料過程中，會根據分片鍵及配置的分片策略，路由到對應的資料節點。t_user表則根據defaultDataSourceName配置路由到ds_0資料來源。
然後再執行幾個簡單的查詢語句，看下讀寫分離是否生效。根據日誌可以看出，
t_order
和
t_order_item
表，進行了加解密改寫，也正確地路由到了從庫。而
t_user
表仍然路由到
ds_0
資料來源上執行，規則中配置的讀寫分離規則沒有起到作用。這是由於在 4。1。1 GA 版中，讀寫分離和加解密都是基於分片功能進行整合，這種方案天然限制了分片之外功能的配合使用。
5.0.0 GA 版基於可插拔架構，對核心進行了全面地升級，核心中的各個功能都可以任意組合使用。同時，5.0.0 GA 版刪除了需要使用者額外配置的
defaultDataSourceName
，
預設透過
SingleTableRule
實現單表的元資料載入及路由。
下面我們來看看相同的功能，在 5。0。0 GA 版中是如何配置和使用的，具體配置如下：
首先，從配置上來看，5。0。0 GA 版和 4。1。1 GA 版
最大的區別在於不同功能之間的關係，它們是一個平級關係，不存在 4.1.1 GA 中的功能依賴，每個功能都可以透過可插拔的方式靈活載入和解除安裝。其次，這些功能在整合使用時，使用類似於管道的傳遞方式，
例如：讀寫分離規則基於兩組主從關係，聚合出兩個邏輯資料來源，分別是
ms_ds_0
和
ms_ds_1
。資料分片規則基於讀寫分離聚合出的邏輯資料來源，配置資料分片規則，從而又聚合出邏輯表
t_order
。加解密功能則關注於列和值的改寫，面向資料分片功能聚合出的邏輯表，配置加解密規則。讀寫分離、資料分片和加解密功能層層傳遞，透過裝飾模式，不斷對功能進行增加。
為了對比 4。1。1 GA 版功能，我們執行同樣的初始化語句、插入語句和查詢語句對 5。0。0 GA 版進行測試。
在 5。0。0 GA 版中，增加了對加解密 DDL 語句改寫的支援，因此在建立
t_order
過程中，不論是資料分片、讀寫分離還是加解密，路由和改寫都能夠正常執行。
t_user
表從日誌來看，被路由到
ds_1
資料來源執行，在 5。0。0 GA 版中，
t_user
屬於單表，無需使用者配置資料來源，在執行建表語句時，會隨機選擇一個數據源進行路由。對於單表，我們需要保證它在邏輯庫中唯一，從而保證路由結果的準確性。
在對
t_user
表執行資料插入時，會根據元資料中儲存的資訊來進行自動路由，由於前一個步驟中t_user路由到了ds_1資料來源，因此其他語句會根據
t_user: ds_1
這樣的元資料進行路由處理。
在執行查詢語句時，我們可以發現，
t_user
表被路由到了
ds_1_slave_0
資料來源，實現了單表的讀寫分離。在 5。0。0 GA 版中，Apache ShardingSphere 核心透過元資料載入，內部維護了單表的資料分佈資訊，並充分考慮了不同功能組合使用的場景，使得單表也能夠完美支援。
5。0。0 GA 版中還有很多新功能，升級指南中的案例只是挑選了兩個 GA 版本中都能夠支援的一些功能進行對比，期望能夠幫助大家理解新功能，並順利地實現功能升級。如果大家對可插拔架構、Federation 執行引擎或者其他的新功能感興趣，歡迎參考官方文件進行測試使用。
結語
歷經兩年時間的打磨，Apache ShardingSphere 以全新的姿態展示在大家面前，
可插拔架構核心為所有的開發者提供了無限的可能性，未來，我們將基於可插拔架構核心，不斷開拓新的功能，豐富 Apache ShardingSphere 生態系統。
Federation 執行引擎則打開了分散式查詢的大門，後續我們將專注於記憶體及效能的最佳化，為大家提供更可靠、更高效的分散式查詢能力。最後，也歡迎大家能夠積極地參與進來，共同推動 Apache ShardingSphere 的發展。