初次接触shardingsphere是在2017年，那时候还叫sharding-jdbc，属于当当网。当时公司的支付项目改动升级，主要有如下两个问题。
1.数据量过大(水平分表)。订单表(order表)单表数据现在已经超500w条，在可预见的半年时间内，数据量可能会达到1000w。现在的查询速度慢已经肉眼可见。
2.业务需求(垂直分库)。不同的地区商户(merchant表)进入不同的物理数据库中。(分配给不同的人员维护)
解决方式：
1.ShardingJdbc即为增强版的JDBC驱动，其优势在于无需对原有的业务工程进行任何改造的基础上，即可使其拥有分库分表的能力，成本较低，易于上手。但是，也有缺点，中间件与业务应用工程绑定在一起，对应用本身有侵入。当时只支持Java语言。
2.MyCat是一个开源的分布式数据库系统（属于代理类框架），相当于一个实现了MySQL协议的数据库代理服务器。 其缺点是上线部署需要额外的中间件，增加运维成本；应用服务需经过代理来连接数据库，网络上多了一层链接的开销，性能有损失且有额外风险。
最终选择了sharding-jdbc，架构图如下。
sharding-jdbc的使用也是非常简单，只需要三步：
1.引⼊ maven 依赖
<dependency>
<groupId>org.apache.shardingsphere</groupId>
<artifactId>shardingsphere-jdbc-core</artifactId>
<version>${latest.release.version}</version>
</dependency>
注意：请将 ${latest.release.version} 更改为实际的版本号。
2.规则配置
ShardingSphere-JDBC 可以通过 Java，YAML，Spring 命名空间和 Spring Boot Starter 这 4 种
⽅式进⾏配置，开发者可根据场景选择适合的配置⽅式。详情请参⻅配置⼿册。
3.创建数据源
通 过 ShardingSphereDataSourceFactory
⼯ ⼚ 和 规 则 配 置 对 象 获 取
ShardingSphereDataSource。该对象实现⾃ JDBC 的标准 DataSource 接口，可⽤于原⽣ JDBC
开发，或使⽤ JPA, MyBatis 等 ORM 类库。
DataSource dataSource = ShardingSphereDataSourceFactory.
createDataSource(dataSourceMap, configurations, properties);
实际开发中遇到的两大问题：
1.数据id需要保持全局唯一。
2.有部分sql不支持。100%支持mysql单库查询。 全面支持DML、DDL、DCL、TCL和部分DAL。支持分页、去重、排序、分组、聚合、关联查询（不支持跨库关联）。 不支持CASE WHEN、HAVING、UNION (ALL)，有限支持子查询(只能 解析至第一个包含数据表的子查询 )。
解决的方案:
1.id生成方法改为UUID或者雪花算法等一些分布式的算法，如不然，则不能作为分片键使用。数据库自增的id不能作为应用的唯一标示，否则会出现数据不一致的情况。
2.有两种解决方法。
1）如果有确定的部分复杂的sql可以选择选择配置 default-data-source，凡是在默认数据源中的表可以⽆需配 置在分⽚规则中，ShardingSphere 将在找不到分⽚数据源的情况下将表路由⾄默认数据源。
2）如果业务上有大量不确定的sql场景，可以配合注解多数源来解决，详情参照https://mp.weixin.qq.com/s/LOcjg0lrV9ZbELBVWlTR2g。
注意：数据的读写分离需要运维同学在数据库服务器上做数据同步。
总结：现在sharding-jdbc改名为sharding-sphere,已经成为了apache开源基金会顶级的开源项目。是⼀套开源的分布式数据库中间件解决⽅案组成的⽣态圈，它由 JDBC、 Proxy和 Sidecar（规划中）这 3 款相互独⽴，却⼜能够混合部署配合使⽤的产品组成。它们均提供标准化的数据分⽚、分布式事务和数据库治理功能，可适⽤于如Java 同构、异构语⾔、云原⽣等各种多样化的应⽤场景。而我自己也成为了该开源项目的contributor，下一篇讲述开始如何成为该开源项目的contibutor，踩过的坑，以及对开源项目的看法。
参考资料:https://shardingsphere.apache.org/index_zh.html
