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

点击上方蓝字关注我们

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

更名契机

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

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

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

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

全新拓展

由于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 实例，对数据进行查询和管理。

社区化运营

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

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

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

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

Sharding-Sphere

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

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

项目地址：

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

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

更多信息请浏览官网：

http://shardingsphere.io/

或加入Sharding-Sphere官方讨论群 

感谢您的支持与关注