一、选型背景
公司营收业绩高速增长，业务快速向前奔跑，对基础技术上线既要超、快、猛，又要保证服务质量，所以前期选型稳妥方案为MySQL router，但他的核心功能上仅支持读写分离、读写库高可用、动态增删DB节点，而读写性能却无法应对每月大幅增长的数据。对业务拆分同时进行分库分表势在必行。基于以上场景需求，由我发起、高层参与和相关人一起讨论决定选型TDDL作为长期演进方案，关于为什么选择TDDL，理由如下：
- 大厂阿里出品，经过6年长期迭代，在内部有1000+系统验证和运行
- 功能强大，体系完善，tddl + diamond + otter + Canal组合套件能做到在线数据迁移，拆表扩容
- 基于agent客户端接入方式，相对proxy模式，业务隔离性较好，性能也更高
- 当当ShardingJDBC和美团zebra基本都是follow的tddl体系和思想，而且SQL解析模块代码也是从阿里tddl从抽取出来的
- 容易构建服务治理体系
TDDL不足：
- 开源代码无法run起来，有代码，无文档，无法立即run起来，需要自己摸索
- 目前网上能找到的开源版本中最后一个commit 是2014 Aug. 从14至今, JDK 从6升到了8, 中间涉及到JDBC的变更，以及第三方框架(Spring, Mybaits, CGLib)的变更。我们需要自己去验证并发现14年的版本和今天我们线上的所有数据库涉及到的第三方框架兼容性。
- 进度无法精准判断，前期花费时间较长，代码模块比较复杂，进度上很难给出精准判断
二、核心目标
推进策略，先保证核心功能，再完善扩展功能
核心功能
- 动态数据源
- 读写分离
- 读写库高可用
- 分库分表
- 读库负载均衡
- 连接池及慢SQL监控
扩展功能
- 动态化配置 tddl依赖diamond客户端版本与diamond服务端无法匹配，还需要大量开发工作，后续可以考虑携程配置中心apollo，功能强大，体系完善
- 拆表扩容
- 数据迁移(迁记录行、迁表、迁库)
三、面临挑战
1.迭代挑战
- 有代码，无文档，需要自己摸索
- 前期探索时间较长，后期会加快
- 当前开源到tddl 5.x版本，从2015年起就没有继续开源维护
2.接入挑战
对比router变化，客户端方案无法做到完全平滑迁移，多了一些配置，读写分离配置少，分库分表配置更多
spring + mybatis + tddl 数据源 + druid
- 对于读写分离表，只需要基于spring配置文件更改数据源
- 对于分库分表，基于spring配置文件数据源 + 分库分表规则
四、业务关注
- 接入成本，希望能统一做适配层，能在router与TDDL、直连DB间自由切换
- 主从库高可用failover
- 容灾、容错、SLA
- 包依赖冲突与管理
- 运营生态(完善)
五、当前进展
1.编译环境升级，jdk从1.6升级到1.8，整合代码，处理错误和补缺接口
2.进入test case阶段，正在做单表、分表、分库分表crud测试
以上为2017年12月29日状态
六、技术规划
1.TDDL阶段里程碑
12月底 搭建一个本地可初步运行的工程demo，单表curd test case，验证后续演进可行性和风险 已经完成
18年Q1
1月 搭建TDDL自测环境，test case，SQL支持度，功能测试，性能测试。
2月 搭建TDDL测试环境，引入一个业务项目，试运行。
3月 逐步推广TDDL，对接配置中心
团队人数安排：2018年1月15日前暂定2人，以后工作更明确再做分解
2.团队规划
负责大量测试验证工作，例如 功能测试、性能测试、SQL支持度测试、压力测试 1人负责
代码优化，核心流程梳理，文档体系建设 1人负责
运维体系建设，动态配置对接开发，实现在线运维 1人负责
客户端封装，为直连、router、tddl做适配，做调研，写代码 1人负责
监控系统完善 对接cat和连接池监控 1人负责
容灾、容错、SLA、主从库高可用failover 1人负责
以上工作需求至少4人完成