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
  2. 原生支持Spring和行表達式的1.1.x
  3. 最大努力送達型柔性事務的1.2.x
  4. 讀寫分離的1.3.x
  5. 分佈式主鍵的1.4.x
  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的架構圖:

Sharding-Sphere成長記—分佈式數據庫代理端里程碑版本3.0.0發佈

在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成長記—分佈式數據庫代理端里程碑版本3.0.0發佈

Sharding-Sphere成長記—分佈式數據庫代理端里程碑版本3.0.0發佈

Sharding-Sphere成長記—分佈式數據庫代理端里程碑版本3.0.0發佈

Sharding-Sphere成長記—分佈式數據庫代理端里程碑版本3.0.0發佈

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

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

Sharding-Sphere成長記—分佈式數據庫代理端里程碑版本3.0.0發佈

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逐漸成熟的同時,京東數科當仁不讓的成為了第一個吃螃蟹的人。京東數科將部分核心業務系統通過小流量 -> 大流量 –> 全流量的流程切換到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成長記—分佈式數據庫代理端里程碑版本3.0.0發佈

大事記

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

2018.2

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

2018.5

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

2018.6

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

2018.8

  • Sharding-Proxy上線京東數科生產環境,並經受住了線上大規模生產數據的考驗。
  • Sharding-Sphere 3.0.0.M2發佈,數據庫治理模塊升級改造,提供更穩定功能。

2018.9

  • Sharding-Sphere 3.0.0.M3發佈,提供對XA分佈式事務的支持。
  • Sharding-Sphere 3.0.0.M4發佈, 改造自動化執行引擎,支持多邏輯數據庫切換,增強鏈路追蹤。

2018.10

  • Sharding-Sphere 3.0.0正式版發佈。

如何獲取

Sharding-JDBC

<groupid>io.shardingsphere/<groupid>
<artifactid>sharding-jdbc-core/<artifactid>
<version>3.0.0/<version>

Sharding-Proxy

docker pull shardingsphere/sharding-proxy

源碼

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

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

官網

http://shardingsphere.io


分享到:


相關文章: