公司营收业绩高速增长,业务快速向前奔跑,对基础技术上线既要超、快、猛,又要保证服务质量,所以前期选型稳妥方案为MySQL router,但他的核心功能上仅支持读写分离、读写库高可用、动态增删DB节点,而读写性能却无法应对每月大幅增长的数据。对业务拆分同时进行分库分表势在必行。基于以上场景需求,由我发起、高层参与和相关人一起讨论决定选型TDDL作为长期演进方案,关于为什么选择TDDL,理由如下:
TDDL不足:
推进策略,先保证核心功能,再完善扩展功能
核心功能
扩展功能
1.迭代挑战
2.接入挑战
对比router变化,客户端方案无法做到完全平滑迁移,多了一些配置,读写分离配置少,分库分表配置更多
spring + mybatis + tddl 数据源 + druid
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人完成
引用博客地址为:https://www.cnblogs.com/lizherui/p/12769889.html
原文:https://www.cnblogs.com/lizherui/p/12769889.html