The Evolution and Release of ShardingSphere 3.0.0: From Sharding‑JDBC to Sharding‑Proxy
This article chronicles the eight‑month development of ShardingSphere 3.0.0, detailing its origins from Sharding‑JDBC, the addition of Sharding‑Proxy and Sidecar, core feature enhancements, distributed transaction redesign, community growth, and future roadmap for the open‑source database middleware ecosystem.
After eight months of intensive development, the Sharding‑Sphere community released Sharding‑Sphere 3.0.0 on Programmer's Day (October 24), marking a milestone that reflects the project's evolution from its predecessor Sharding‑JDBC.
Origins : Sharding‑JDBC began as an internal component of the ddframe framework at Dangdang, providing transparent sharding at the JDBC layer. It was open‑sourced in early 2016 and quickly grew into a standalone project.
Core Feature Maturation : Over a year, Sharding‑JDBC delivered six major 1.x releases, establishing the core sharding model (SQL parsing, routing, rewriting, execution, and result merging) and adding Spring integration, flexible transactions, read/write splitting, distributed primary keys, and a new SQL parser engine.
Distributed Governance : In 2017, version 2.x introduced centralized configuration via a registry, database and application circuit‑breaking, and OpenTracing support through integration with Apache SkyWalking.
Shift to Cloud‑Native : With the rise of cloud‑native architectures, the Java‑only Sharding‑JDBC could no longer meet all needs, prompting the creation of a proxy‑based sharding solution (Sharding‑Proxy) and the eventual renaming of the project to Sharding‑Sphere, encompassing three sub‑projects: Sharding‑JDBC (driver), Sharding‑Proxy, and the future Sharding‑Sidecar.
Technical Challenges of Sharding‑Proxy include implementing the MySQL protocol (handling packets such as COM_QUERY, COM_STMT_PREPARE, COM_STMT_EXECUTE) and adopting Netty for high‑throughput, lock‑free asynchronous communication. The architecture diagram is shown below:
Sharding‑Sphere 3.0.0 also introduced a redesigned distributed transaction module, replacing the previous “best‑effort delivery” model with support for XA strong consistency, Saga‑based eventual consistency, and plans for message‑driven transactions via Apache ServiceComb‑Saga.
The project has grown a vibrant community, established a PMC, and formed partnerships with companies such as Wing Pay and Apache ServiceComb, while continuing to expand its governance and tracing capabilities through SkyWalking.
Production adoption began with JD Finance, which migrated core services to Sharding‑Proxy, validating the system at a ten‑thousand‑node scale. Subsequent milestone releases (M1–M4) refined performance and added features, culminating in the stable 3.0.0 release on October 24.
Future plans include Sharding‑Sphere 3.1.0 (enhanced distributed transactions), version 4.0.0 (Sidecar support and automated elastic scaling), and a roadmap illustrated below:
For developers, the Maven coordinates are:
<groupId>io.shardingsphere</groupId>
<artifactId>sharding-jdbc-core</artifactId>
<version>3.0.0</version>Docker image for Sharding‑Proxy: docker pull shardingsphere/sharding-proxy Source code and documentation are available at GitHub and shardingsphere.io .
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
JD Tech Talk
Official JD Tech public account delivering best practices and technology innovation.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
