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 的架构图：

 

在 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 逐渐成熟的同时，京东数科当仁不让的成为了第一个吃螃蟹的人。京东数科将部分核心业务系统通过小流量 -> 大流量 –> 全流量的流程切换到 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, 同时上线新官网。这预示着它新时代的到来。
• 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