新起航!Sharding-JDBC经过公投,正式改名为Sharding-Sphere

新起航!Sharding-JDBC经过公投,正式改名为Sharding-Sphere

经过了两年多全力的耕耘与打造,Sharding-JDBC近期终于收获了在github上的第4000个star,在当今的分布式数据库中间件领域占有了一席之地。


作者:张亮
编辑于:2018-05-14

1. 更名契机

一直以来,Sharding-JDBC定位为轻量级Java框架,在Java的JDBC层提供的额外服务。它使用客户端直连数据库,以jar包形式提供服务,无需额外部署和依赖,可理解为增强版的JDBC驱动,完全兼容JDBC和各种ORM框架。

然而仅通过JDBC 层的嵌入,难于应对更加多样化的场景,如: Java 之外的异构语言、数据库管理端命令行和 UI,等等。基于Proxy去模拟数据库的中间层方案则更加容易支撑相应的应用场景。

Proxy方案与基于JDBC的Client方案到底谁更加优秀,是长久以来争论不休的经典话题。其实,它们都有着各自的优缺点,如何在适合的场景最大限度的发挥优势,屏蔽劣势,是技术选型时架构师们需要重点考虑的。它们的简单比较如下表:

为了应对异构语言等场景,我们开发了基于 MySQL 代理端的 Proxy 版本,而原有的 JDBC 版本也得以保留,给用户的多样化场景提供更多选择。

2. 全新拓展

由于Proxy版本的出现,使得Sharding-JDBC这个名字已经不再适合,但我们无法放弃过去两年多 Sharding-JDBC 的影响力所带来的累积。因此,我们保留了 “Sharding” 这个关键词。而且,对于分布式数据库中间件来说,无论是分库分表、柔性事务还是数据治理,“Sharding” 是这一切的起源

我们将原有的 Sharding-JDBC与新开发的 Sharding-Proxy 以及正在孵化中的 Sharding-Sidecar 一起组成了一个生态圈,将其命名为Sharding-Sphere,即 Sharding 圈。

下图中的蓝色部分是Sharding-Sphere已经实现的功能,橘色部分是即将开发的功能。

选择Proxy还是Client这个话题,在Sharding-Sphere这里可以暂且缓解一下。因为无论选择哪一种架构模式,Sharding-Sphere都会用同一套内核去处理SQL解析、路由、改写以及结果归并和核心逻辑,使得用户无需担心使用两套不同产品带来的功能不兼容。而在同一个系统中组合使用Sharding-Sphere也非常简单。

举例说明,对于仅使用 Java 为开发技术栈的场景,Sharding-JDBC 对各种 Java 的 ORM 框架支持度非常高,开发人员可以非常便利地将数据分片能力引入到现有的系统中,并将其部署至线上环境运行,而 DBA 可以通过部署一个 Sharding-Proxy 实例,对数据进行查询和管理。


3. 社区化运营

Sharding-Sphere通过完全社区化的方式运营,改名是由社区投票来决定的,请参见:

github.com/sharding-sph

投票持续一周,共计39同意票,1弃权票的结果,其中PMC和官方贡献者以13票全票数过。目前公投已结束。

改名之后的Sharding-Sphere将于近期发布3.0.0.M1版本,敬请大家指教。


Sharding-Sphere是一套开源的分布式数据库中间件解决方案组成的生态圈,它由Sharding-JDBC、Sharding-Proxy和Sharding-Sidecar这3款相互独立的产品组成。他们均提供标准化的数据分片、读写分离、柔性事务和数据治理功能,可适用于如Java同构、异构语言、容器、云原生等各种多样化的应用场景。

开源不易,您对我们最大支持,就是在github上留下一个star。

项目地址:

github.com/sharding-sph

gitee.com/sharding-sphe

更多信息请浏览官网:

Sharding-Sphereshardingsphere.io图标

或移步官方微信公众号:

微信公众号搜索“Sharding-Sphere”或“ShardingSphere官微”。

感谢您的支持与关注!