本篇博文想结合一些开源系统落地的思想，复盘之前在工作中如何落地ShardingSphere。
需求
新产品在总体需求阶段就已知将会以TOB的SaaS服务进行开发，为了确保商户的数据物理隔离，我们要根据不同的商户划分到不同的库中，因此需要一款分库产品来实现这个需求。
对数据库的增强的形式
那么当时进行分库的形式有哪些呢？
典型的开源数据库组件
- TDDL： 淘宝数据中间层。
- ShardingSphere-JDBC： Apache基金会开源产品（ 源于当当， 发展于京东） 。
典型的开源数据库中间件
- MyCat/DBLE： 开源+商业化的中间件。
- ShardingSphere-Proxy： Apache基金会开源产品（ 源于当当， 发展于京东） 。
- Vitness/KingShard： 开源的go数据库中间件。
典型的开源分布式数据库
- CockroachDB： 国外开源产品。
- TiDB： 国内可能是最火的开源分布式数据库。
选 - 如何选择合适的开源系统
从第二小节我们可以看到市面上已经存在丰富的不同类型的开源数据库增强形式，那么应该如何选择一款合适的开源系统到项目中进行开发
适应性
按照“合适原则”和“简单原则”挑选，基于业务量级和团队水平进行选择。
- 这是一个新的项目，可以根据总体需求进行一定的架构演化，原则上可以引入第二小节我们提到的三种不同形式的数据库增加方式。
- 已知当时的后端团队统一以JAVA为主,DBA只会MYCAT。
- 当时后端团队有20人，人员大多投入产品和项目当中，当时有3位固定的负责基础设施建设的资深工程师。
从当时情况来看，当时团队的组成不支持我们调配人员去专门负责使用开源分布式数据库，开源数据库中间件我们可以选择Mycat/ShardingSphere-Proxy，可以选择成熟的开源数据库组件。
成熟度
从“版本号”、“哪些公司在用”、“社区活跃度”等维度判断是否成熟
| 数据库组件/数据库中间件 | 版本号 | 社区活跃度 | 知名使用公司 |
| TDDL | 无 | 只是开源放在github上并没后续跟进 | 淘宝 |
| ShardingSphere-JDBC | 4.0.0 | 非常活跃 | 唯品会、滴滴小桔车服、京东金融 |
| MyCat | 1.6.5-RELEASE | 一般 | 赶集网 |
| ShardingSphere-Proxy | 4.0.0 | 非常活跃 | 唯品会、滴滴小桔车服、京东金融 |
- TDDL只是部分共享没有演进
- MyCat在2016年之后没有发布新的版本
- ShardingSphere在2016年发布后持续更新，每1-2年会进行大版本的更新
从社区活跃度和知名使用公司来看，使用ShardingSphere旗下的产品会是2019年的最好选择，那么到底选择ShardingSphere-JDBC还是ShardingSphere-Proxy
- ShardingSphere-Proxy在2018年才发布，经历的沉淀可能稍微欠缺
- ShardingSphere-JDBC作为JDK组件嵌入到项目中，天然实现了高可用
从现在的角度来看使用ShardingSphere-Proxy和ShardingSphere-JDBC都是可行的，但是在当时来看不需要额外进行运维的ShardingSphere-JDBC会更好。
可运维
1. 开源项目日志是否齐全；
2. 是否有命令行、管理控制台等维护工具；
3. 是否有故障检测和恢复的能力，例如告警、切换等。
对于2、3条嵌入ShardingSphere-JDBC的服务配上skywalker和Prometheus可以做的很好
用 - 如何使用开源系统
当开源系统需要落地项目的时候，应该如何做？
深入研究，仔细测试
1. 研究合理的配置项，避免默认配置踩坑；
2. 认真查看留意事项，避免经验产生问题；
3. 性能测试：计算机器数量；
4. 压力测试：应急处理。
ShardingSphere-JDBC已经能支持大多数场景下的的SQL，但是并不代表它都支持，union(all)在mysql就是正常的查询语法，但是ShardingSphere-JDBC就不支持，如下图，就只能分阶段查询，具体我们可以查看不支持项
SELECT
a.address_id,address0.*
FROM
eshop_address a
LEFT JOIN eshop_address_0 address0 ON a.province_code = address0.province_code
union all
SELECT
a.address_id,address1.*
FROM
eshop_address a
LEFT JOIN eshop_address_1 address1 ON a.province_code = address1.province_code 小心应用，灰度发布
小心驶得万年船，先用非核心业务试点再推广。
虽然本次引入在项目初期就确定，因此能做充分的测试和验证。但是如果在大型项目正常运营阶段一开始就引入到核心模块，那么如果开源项目拥有隐藏的很深的致命性缺陷，一旦出现问题，那么可能会出现不可想象的严重后果，所以最好把开源项目引入到非核心业务在真实环境观察一番再推广。
做好应急，以防万一
做最坏的打算，做最好的准备。
改 - 如何基于开源项目做二次开发
保持纯洁，加以包装
不要改动原系统，而是要开发辅助系统：监控、报警、负载均衡、管理等
我们可以从github中下载源码，我们也可以从中看到当时ShardingSphere-JDBC的负载均衡算法只提供了轮询和随机算法，如果我们需要使用权重分配方式，以前我们只能改动默认算法为权重分配，但是ShardingSphere-JDBC提供了SPI机制，我们通过SPI对框架进行拓展，不需要但是后续的升级。
发明你要的*
没有完全适合你的*，等开源系统又太慢了
虽然当时到现在公司没有这样的实力，但是我们现在能找到很多脱胎于旧的系统，在现在发光发热开源系统如基于Lunce的ElasticSearch。
后记
ShardingSphere-JDBC目前在我们的项目正常运行快两年了，ShardingSphere顺利成为了Apache*项目，ShardingSphere也由当初的4.x演进到5.x,社区依然火热，从现在的角度来看当初的选择是一个正确的选择。