默默学Sharding-Sphere(一)

概念篇

Sharding-Sphere是一套开源的分布式数据库中间件解决方案组成的生态圈，它由Sharding-JDBC、Sharding-Proxy和Sharding-Sidecar（计划中）这3款相互独立的产品组成。 他们均提供标准化的数据分片、分布式事务和数据库治理功能，可适用于如Java同构、异构语言、容器、云原生等各种多样化的应用场景。
Sharding-Sphere定位为关系型数据库中间件，旨在充分合理地在分布式的场景下利用关系型数据库的计算和存储能力，而并非实现一个全新的关系型数据库。 它与NoSQL和NewSQL是并存而非互斥的关系。NoSQL和NewSQL作为新技术探索的前沿，放眼未来，拥抱变化，是非常值得推荐的。反之，也可以用另一种思路看待问题，放眼未来，关注不变的东西，进而抓住事物本质。 关系型数据库当今依然占有巨大市场，是各个公司核心业务的基石，未来也难于撼动，我们目前阶段更加关注在原有基础上的增量，而非颠覆。

Sharding-JDBC
定位为轻量级Java框架，在Java的JDBC层提供的额外服务。 它使用客户端直连数据库，以jar包形式提供服务，无需额外部署和依赖，可理解为增强版的JDBC驱动，完全兼容JDBC和各种ORM框架。
● 适用于任何基于Java的ORM框架，如：JPA, Hibernate, Mybatis, Spring JDBC Template或直接使用JDBC。
● 基于任何第三方的数据库连接池，如：DBCP, C3P0, BoneCP, Druid, HikariCP等。
● 支持任意实现JDBC规范的数据库。目前支持MySQL，Oracle，SQLServer和PostgreSQL。

Sharding-Proxy:
定位为透明化的数据库代理端，提供封装了数据库二进制协议的服务端版本，用于完成对异构语言的支持。 目前先提供MySQL版本，它可以使用任何兼容MySQL协议的访问客户端(如：MySQL Command Client, MySQL Workbench等)操作数据，对DBA更加友好。
● 向应用程序完全透明，可直接当做MySQL使用。
● 适用于任何兼容MySQL协议的的客户端。

Sharding-Sidecar
定位为Kubernetes或Mesos的云原生数据库代理，以DaemonSet的形式代理所有对数据库的访问。 通过无中心、零侵入的方案提供与数据库交互的的啮合层，即Database Mesh，又可称数据库网格。
Database Mesh的关注重点在于如何将分布式的数据访问应用与数据库有机串联起来，它更加关注的是交互，是将杂乱无章的应用与数据库之间的交互有效的梳理。 使用Database Mesh，访问数据库的应用和数据库终将形成一个巨大的网格体系，应用和数据库只需在网格体系中对号入座即可，它们都是被啮合层所治理的对象。

Sharding-JDBCSharding-ProxySharding-Sidecar数据库任意MySQLMySQL连接消耗数高低高异构语言仅Java任意任意性能损耗低损耗略高损耗低无中心化是否是静态入口无有无

	Sharding-JDBC	Sharding-Proxy	Sharding-Sidecar
数据库	任意	MYSQL	MYSQL
连接消耗数	高	低	高
异构语言	仅Java	任意	任意
性能	损耗低	损耗略高	损耗低
无中心化	是	否	是
静态入口	无	有	否

功能列表
数据分片
● 分库 & 分表
● 读写分离
● 分布式主键
分布式事务(Doing)
● XA强一致事务
● 柔性事务
数据库治理
● 配置动态化
● 熔断 & 禁用
● Open Tracing
● 多数据副本 (Planing)
● 弹性伸缩 (Planing)
Roadmap

总结

Sharding-Sphere定位为分布式数据中间件产品，旨在解决数据分片问题。当然从规划来看，后面还提供分布式事务和数据库治理功能。产品发展路线可以按产品演进划分：Sharding-JDBC->Sharding-proxy->Sharding-Sidecar。
这三个产品各有优缺点，也说明没有最好的方案，只有合适的方案。选用哪种，表格式也列出了相应的优缺点，需要特定场景特定分析。
Sharding-Sphere从Sharding-JDBC以来，社区活跃度一直很高，主要还是因为产品特点非常适用现在分布式场景下数据分片问题，开源且迭代频率也很高，还是很值得关注的。