Sharding-Sphere成長記——寫在分散式資料庫代理端里程碑版本3.0.0釋出之際

在歷經八個月的緊張開發與精心打磨之後，Sharding-Sphere社群為程式設計師獻禮，將Sharding-Sphere 3.0.0正式版於10月24日程式設計師節釋出。在3.0.0釋出之際，寫下此文，與大家共同回顧這段充滿紀念的時光，分享我們的前進歷程。

\\

前序

\\

關注開源圈的同學可能知道，Sharding-Sphere的前身是Sharding-JDBC。

\\

起源

\\

Sharding-JDBC是一套擴充套件於Java JDBC層的分庫分表中介軟體，最初起源於噹噹的內部應用框架ddframe中的資料庫訪問層元件。由於分庫分表需求的相對普遍，並且具備獨特的生命力與關注度，因此將其抽離成為獨立的專案，命名為Sharding-JDBC，並於2016年初開源。

\\

Sharding-JDBC的最初目標是透明化分庫分表所帶來的複雜度，包括資料來源的管理、根據業務進行的SQL改寫等。作為使用Java語言開發的ddframe框架中的一部分，Sharding-JDBC順其自然的選擇了JDBC作為其分庫分表擴充套件點的接入端。正如其名稱Sharding-JDBC所昭示，它是在JDBC層進行Sharding（分庫分表）的產品。

\\

核心功能完善

\\

Sharding-JDBC在其後的一年中有條不紊的釋出了1.x的6個大版本更新，分別是：

\\

1. 奠定了SQL解析、請求路由、SQL改寫、SQL執行和結果歸併的分庫分表的核心模型的1.0.x\\t
2. 原生支援Spring和行表示式的1.1.x\\t
3. 最大努力送達型柔性事務的1.2.x\\t
4. 讀寫分離的1.3.x\\t
5. 分散式主鍵的1.4.x\\t
6. 全新SQL解析引擎的1.5.x\

分散式治理

\\

在分庫分表功能逐漸成熟之後，在2017年，Sharding-JDBC進入了2.x時代。2.x主要實現的功能是資料庫治理，它可以通過註冊中心提供對配置的集中化和動態化，以及對資料庫和應用進行禁用和熔斷。在此基礎上，還增加了面向OpenTracing協議的鏈路追蹤能力，並且達成了與國內優秀的APM產品Apache SkyWalking（https://github.com/apache/incubator-skywalking）的合作協議，將Sharding-JDBC的追蹤資料對接入SkyWalking，並讓SkyWalking將採用Sharding-JDBC作為其儲存引擎成為可選項。

\\

至此，分庫分表、分散式事務和資料庫治理都有了簡單的雛形。

\\

發展

\\

隨著雲原生的普及，應用上雲和對異構語言的無差別支援漸漸成為當今主流。僅支援Java的Sharding-JDBC已經無法滿足雲原生的全部需要，在業界一直爭論不休的在客戶端（JDBC或其他語言客戶端）還是服務端（Proxy）進行分片的優劣，也未有定論。

\\

改名、之後再踏征途

\\

2018年春節前夕，隨著核心開發人員的加盟，京東數科（當時還叫京東金融）加入了Sharding-JDBC的開發工作中，並將其定位為面向雲化的資料庫中介軟體。在客戶端進行分庫分表的Sharding-JDBC，雖然可以作為輕量級微服務框架靈活應用，但卻沒有作為雲接入端進行統一管控的能力。因此，一個Proxy接入端呼之欲出。

\\

Sharding-JDBC這個名字在過去的兩年中獲得了大量的積累，已經具備一定的辨識度，開發團隊並不希望完全放棄掉這個名字。因此，最初將新的代理端產品命名為Sharding-JDBC-Server，而將原有的Sharding-JDBC改名為Sharding-JDBC-Driver。

\\

經過了反覆的權衡，我們發起了社群投票。最終決定保留Sharding這個關鍵詞，將專案的名稱正式改為Sharding-Sphere，意為分片生態圈。無論是分散式事務還是多資料庫的治理，其本源都是分片；若採用單一的無分片資料庫，後續功能都將無需存在。分片生態圈由根據不同的接入端，由3個子專案組成，它們是基於JDBC客戶端接入的Sharding-JDBC（即原有專案）、基於代理端接入的Sharding-Proxy（今年的重點更新）、以及基於Sidecar模式接入的Sharding-Sidecar（明年的產品規劃）。

\\

3.0.0於此刻正式起航，主要目標是將Sharding-JDBC的能力完全移植入Sharding-Proxy，使其具備支援異構語言的能力。雖然分片的核心邏輯並未變化，但相比於Sharding-JDBC，Sharding-Proxy有兩個難點是需要攻破的。

\\

第一個難點是資料庫協議的實現。將代理端偽裝成為一個資料庫，能夠將接入的成本降至最低。Sharding-Proxy選擇最常用的MySQL協議做為首先支援的資料庫協議，並完整的實現了所有的應用程式執行時所需的協議包（如：COM_QUERY、COM_STMT_PREPARE、COM_STMT_EXECUTE）。目前對於管理端使用的一些協議包還未全部實現。

\\

第二個難點是通訊框架。JDBC層的通訊是由各個資料庫驅動提供商通過BIO的方式實現的，雖然吞吐量欠佳，但卻容易實現。代理端為了更高的吞吐量，需要採用NIO的方式。Sharding-Proxy採用Netty作為通訊框架，在接入層前端實現了完全無鎖的非同步通訊。目前接入端連線後端資料庫時，仍然採用JDBC的方式，未來會將其完全改為Netty非同步通訊的方式，進一步提升吞吐量，達成前後端完全無鎖通訊的目標。以下是Sharding-Proxy的架構圖：

\\

\ 
\在2018年5月，基本可用的Sharding-Proxy隨著Sharding-Sphere 3.0.0.M1釋出。

\\

同時，由於多家公司共同參與開發，Sharding-Sphere決定成立社群，將著作權完全歸屬至Sharding-Sphere社群，併成立了專案管理委員會（PMC），並且也完善了貢獻者和提交者的晉升制度。

\\

隨著新的里程碑版本，Sharding-Sphere申請了全新的域名，並重新制作官網，重灌釋出。

\\

擴大範圍、加強合作

\\

Sharding-Sphere的更名，不僅僅是接入端的增強。作為分片生態圈，更完善的分散式事務和資料庫治理，也納入了專案範圍。

\\

Sharding-Sphere將原有的分庫分表功能更名為資料分片，內容包擴核心流程、讀寫分離和分散式主鍵。Sharding-Sphere的核心流程模組的幾個重點部分可以通過一張圖幫助使用者理解，下面分別是路由引擎、改寫引擎、執行引擎和歸併引擎的剖析圖：

\\

\\

\\

\\

\\

Sharding-Sphere對分散式事務進行了重新的設計和定位。廢棄掉原有的最大努力送達型柔性事務，取而代之的是採取剛柔並濟的實現方案：同時支援XA的強一致事務，以及基於Saga的最終一致性事務，基於訊息的最終一致性事務也在規劃中。

\\

分散式事務模組將定位從自研轉向整合，即整合現有的成熟事務方案，為本地事務、XA事務和柔性事務提供統一的分散式事務介面，並儘量彌補各個方案對資料庫層面的缺失。分散式事務模組提供一套SPI事務處理介面，能夠無縫對接分散式事務的各個實現方案。分散式事務模組的架構圖如下：

\\

\\

Sharding-Sphere經過比較分析，選擇採用Apache ServiceComb的分散式事務解決方案來實現柔性事務， 通過在ServiceComb Saga執行引擎基礎上擴充套件sql執行模組，實現了基於分散式Saga的事務執行和回滾功能。

\\

分散式事務模組將於3.1.0的版本釋出，目前仍處於緊張的開發階段。

\\

在資料庫治理方面，Sharding-Sphere全數保留了之前的功能，並提供了全新的APM鏈路追蹤資料，可以通過SkyWalking更直觀的觀測Sharding-Sphere。但目前仍未包括資料庫彈性擴縮功能，該部分功能將於明年規劃。

\\

在高速發展的同時，Sharding-Sphere迎來了新的合作伙伴——翼支付。翼支付成立了創新中心部門，並投入開發資源加入到了Sharding-Sphere的開發團隊。這使得Sharding-Sphere的開源社群更加多元化和健康成長。Sharding-Sphere屬於社群而非公司，因此歡迎有興趣參與開發的公司一起打造更加多元化的社群和更加完善的專案。

\\

上線、然後釋出

\\

在Sharding-Sphere的旗下產品Sharding-Proxy逐漸成熟的同時，京東數科當仁不讓的成為了第一個吃螃蟹的人。京東數科將部分核心業務系統通過小流量 -\u0026gt; 大流量 –\u0026gt; 全流量的流程切換到Sharding-Proxy，目前Sharding-Proxy在生產環境中已經管理並執行著萬級別資料節點。

\\

在經受考驗之後，隨之而來的Sharding-Sphere 3.0.0.M2、3.0.0.M3和3.0.0.M4相繼釋出。在經歷了大量的效能調優和功能完善之後，終於在10月24日的程式設計師節釋出3.0.0穩定版。在經歷了京東數科嚴酷的生產環境驗證後，相信Sharding-Sphere可以成為架構師們進行技術選型時的其中一個參考。

\\

面向未來

\\

Sharding-Sphere 3.0.0的釋出並非終點，而是新的起點。3.1.0已經在同步開發，也將於不久的將來面世，提供更加優化的分散式事務解決方案。計劃於明年開啟的4.0.0對Sidecar模式的接入端以及自動化的彈性伸縮功能也完成了初步規劃。Sharding-Sphere的線路規劃如下圖：

\\

\\

大事記

\\

回顧心路歷程，Sharding-Sphere立足於當下，著眼於未來：

\\

2018.2

\\

• Sharding-Sphere團隊升級組建，並開始著手Sharding-Proxy開發。\

2018.5

\\

• Sharding-JDBC正式更名為Sharding-Sphere, 同時上線新官網。這預示著它新時代的到來。\\t
• Sharding-Sphere著作版權完全歸屬社群shardingsphere.io，並繼續使用Apache 2.0協議。\\t
• Sharding-Sphere 3.0.0.M1釋出，Sharding-Proxy正式上線。\

2018.6

\\

• Sharding-Sphere與Apache ServiceComb建立合作伙伴關係，並開始分散式事務的全面規劃。\\t
• Sharding-Sphere與中國電信旗下翼支付建立合作伙伴關係，共同打造Sharding-Sphere新未來。\

2018.8

\\

• Sharding-Proxy上線京東數科生產環境，並經受住了線上大規模生產資料的考驗。\\t
• Sharding-Sphere 3.0.0.M2釋出，資料庫治理模組升級改造，提供更穩定功能。\

2018.9

\\

• Sharding-Sphere 3.0.0.M3釋出，提供對XA分散式事務的支援。\\t
• Sharding-Sphere 3.0.0.M4釋出， 改造自動化執行引擎，支援多邏輯資料庫切換，增強鏈路追蹤。\

2018.10

\\

• Sharding-Sphere 3.0.0正式版釋出。\

如何獲取

\\

Sharding-JDBC

\\

\\u0026lt;groupId\u0026gt;io.shardingsphere\u0026lt;/groupId\u0026gt;\\u0026lt;artifactId\u0026gt;sharding-jdbc-core\u0026lt;/artifactId\u0026gt;\\u0026lt;version\u0026gt;3.0.0\u0026lt;/version\u0026gt;\

\\

Sharding-Proxy

\\

\docker pull shardingsphere/sharding-proxy

\\

原始碼

\\

https://github.com/sharding-sphere/sharding-sphere

\\

https://gitee.com/sharding-sphere/sharding-sphere

\\

官網

\\

http://shardingsphere.io

\\