4.第三阶段：改造和上线（慎重）前两个阶段完成后 ， 开始业务切换流程 ， 主要步骤如下：
1）中台服务采用单读 双写 的模式
2）旧表往新表开着数据同步
3） 所有服务升级依赖的projectDB版本 ， 上线RPC ， 如果出现问题 ， 降版本即可回滚（上线成功后 ， 单读新库 ， 双写新旧库）
4）检查监控确保没有 中台服务 以外的其他服务访问旧库旧表
5）停止数据同步
6）删除旧表
4.1 查询改造如何验证我们前两个阶段设计是否合理？能否完全覆盖查询的修改 是一个前提条件 。
当新表设计完毕后 ， 就可以以新表为标准 ， 修改老的查询 。
以本项目为例 ， 需要将旧的sql在 新的中台服务中 进行改造 。
1）读查询的改造
可能查询会涉及以下几个方面：
a）根据查询条件 ， 需要将pk1和pk2的inner join改为对应分表键的新表表名
b）部分sql的废弃字段处理
c）非分表键查询改为走搜索平台的查询 ， 注意保证语义一致
d）注意写单测避免低级错误 ， 主要是DAO层面 。
只有新表结构和存储架构能完全适应查询改造 ， 才能认为前面的设计暂时没有问题 。
当然 ， 这里还有个前提条件 ， 就是相关查询已经全部收拢 ， 没有遗漏 。
2) 写查询的改造
除了相关字段的更改以外 ， 更重要的是 ， 需要改造为旧表、新表的双写模式 。
这里可能涉及到具体业务写入逻辑 ， 本项目尤为复杂 ， 需要改造过程中与业务方充分沟通 ， 保证写入逻辑正确 。
可以在双写上各加一个配置开关 ， 方便切换 。如果双写中发现新库写入有问题 ， 可以快速关闭 。
同时 ， 双写过程中不关闭 旧库到新库 的数据同步 。
为什么呢？主要还是由于我们项目的特殊性 。由于我们涉及到几十个服务 ， 为了降低风险 ， 必须分批上线 。因此 ， 存在比较麻烦的中间态 ， 一部分服务是老逻辑 ， 一部分服务是新逻辑 ， 必须保证中间态的数据正确性 ， 具体见4.5.1的分析 。
4.2 服务化改造为什么需要新建一个 服务来 承载改造后的查询呢？
一方面是为了改造能够方便的升级与回滚切换 ， 另一方面是为了将查询收拢 ， 作为一个中台化的服务来提供相应的查询能力 。
将改造后的新的查询放在服务中 ， 然后jar包中的原本查询 ， 全部替换成这个服务的client调用 。
同时 ， 升级jar包版本到3.0.0-SNAPSHOT 。
4.3 服务分批上线为了降低风险 ， 需要安排从非核心服务到核心服务的分批上线 。
注意 ， 分批上线过程中 ， 由于写服务往往是核心服务 ， 所以安排在后面 。可能出现非核心的读服务上线了 ， 这时候会有读新表、写旧表的中间状态 。
1） 所有相关服务使用 重构分支 升级projectdb版本到3.0.0-SNAPSHOT并部署内网环境；
2） 业务服务依赖于 中台服务 ， 需要订阅服务
3） 开重构分支（不要与正常迭代分支合并） ， 部署内网 ， 内网预计测试两周以上
使用一个新的 重构分支 是为了在内网测试两周的时候 ， 不影响业务正常迭代 。每周更新的业务分支可以merge到重构分支上部署内网 ， 然后外网使用业务分支merge到master上部署 。
当然 ， 如果从线上线下代码分支一致的角度 ， 也可以重构分支和业务分支一起测试上线 ， 对开发和测试的压力会较大 。
4）分批上线过程中 ， 如果碰到依赖冲突的问题 ， 需要及时解决并及时更新到该文档中
5）服务上线前 ， 必须要求业务开发或者测试 ， 明确评估具体api和风险点 ， 做好回归 。
这里再次提醒 ， 上线完成后 ， 请不要漏掉离线的数据分析业务！请不要漏掉离线的数据分析业务！请不要漏掉离线的数据分析业务！
4.4 旧表下线流程1）检查监控确保没有中台服务以外的其他服务访问旧库旧表
2）检查数据库上的sql审计 ， 确保没有其他服务仍然读取旧表数据
3）停止数据同步
推荐阅读
- 分库分表的 9种分布式主键ID 生成方案，挺全乎的
- 亿级数据库毫秒级查询？看完这一篇，海量数据赋能你也行
- MySQL8.0大表秒加字段，是真的吗？
- 优雅的drop掉mysql库中1TB大表
- 淘宝技术分享：手淘亿级移动端接入层网关的技术演进之路
- 你们要的MyCat实现MySQL分库分表来了
- 亿级 ELK 日志平台构建实践
- 亿级流量场景下，大型缓存架构设计实现，你知道吗？
- 儿童脾胃不好七大表现
- 阿里数据库开发规范解释：关联查询，为什么要建议小表驱动大表？