背景
在集团金融的业务集群中，我们拥有多条蓬勃发展的业务线。在业务高速增长的阶段，数据库数据隔离的问题并未引起我们足够的关注。部分业务线是从原有的业务组中独立出来，各自为战。因此，所有团队的数据都被塞进了同一个数据库实例，同一个库里。在这个过程中，我们偶尔也遇到了一些技术瓶颈和挑战，但只要我们充分利用资金能力，再加上阿里巴巴的在线客服小蜜的热情帮助，这些问题也就不算什么了。
然而，当业务稳健地上了正轨，加之集团对数据资产安全性的日益重视，数据库迁移的任务终于摆在了桌面上。但这绝不仅仅是迁移几张表那么简单，这几乎等同于动了企业的"龙脉"。虽然这是一件好事，但当这个重任落在我的肩上时，快乐仿佛离我远去。我深知：这是泼天的富贵！
现状
不同业务的数据都在同一个数据库实例同一一个下，存在以下问题：
- 性能影响：不同业务的查询和事务可能会互相影响，尤其是在高负载情况下。例如，一个业务的复杂查询可能会占用大量的CPU和内存资源，导致其他业务的性能下降。
- 维护难度：随着数据量的增加，备份和恢复操作会变得更加复杂和耗时。同时，对于数据库的维护，如索引优化、数据清理等操作也会变得更加困难。
- 安全性问题：如果不同业务间的数据安全级别不同，放在同一个数据库中可能会导致安全隔离不够，增加数据泄露的风险。
- 可扩展性问题：随着所有业务数据的增长，单个数据库的可扩展性可能成为瓶颈。分布式数据库或数据库分片等策略可能因为业务间的耦合而难以实施。
- 灾难恢复：一个业务的问题可能会影响到整个数据库，增加了灾难恢复的复杂性。例如，一个业务需要回滚到特定的时间点，这可能会影响到其他业务的数据。
把业务组的表特定迁出来是能解决以上问题，但是迁移过程是存在风险的：
- 数据丢失：在迁移过程中，如果没有正确备份和验证数据，可能会导致数据丢失。
- 数据不一致：迁移过程中，如果源数据库和目标数据库之间的数据同步没有得到妥善处理，可能会出现数据不一致的情况。
- 业务中断：迁移通常需要一定的停机时间，这可能会导致业务中断。即使是在线迁移，也可能因为迁移操作而影响系统性能，间接导致业务中断。
- 兼容性问题：可能会遇到软件版本差异、字符集和排序规则不一致等兼容性问题，导致应用程序无法正常工作。
- 技术挑战：迁移过程中可能会遇到技术障碍，如大数据量迁移的速度问题、流量隔离问题，特殊数据类型的迁移支持等。
风险>问题。本章就说到这里吧！完结撒花。✿✿ヽ(°▽°)ノ✿
在这次数据库迁移的征途上，我的目标清晰而坚定。首先，我要确保数据的完整性，这意味着在迁移过程中，每一条数据都应当被精确地搬迁，不容有任何污点、遗漏或误差。其次，我们追求的是服务的平稳过渡，务必避免任何剧烈波动，确保业务运行如丝般顺滑。最后，而且同样重要的，是保卫我们的“饭碗”——确保我们的业务和职位的安全稳固。
三个步骤
为此，我分为三个步骤走
假设：财务组有表A，表B，表C。有微服务甲，乙，丙，丁
1、分析，枚举出数据迁移对服务的所有影响点
- 梳理出财务组所有的微服务（12个）
- 梳理出财务组有用到的和已废弃的表（80+多张，数千万的数据量）
- 梳理出流量入口：api网关，feign调用，定时任务xxljob
- 考虑中间件对数据的影响，这里主要是mq里面的消息
2、制定迁移步骤
| 停服更新 | 灰度发布 | |
|---|---|---|
| 描述 | 切断⽹关流量 | 增加⼀套环境，等所有的服务启动后，再统⼀经由路由染⾊，把流量切到新环境 |
| 外部流量 | 通过Nginx统⼀拦截，mock返回系统升级 | 统⼀切换到新环境 |
| 内部流量 | 改写代码，添加开关，统⼀抛出特定异常和告警 | 梳理接⼝，经过原生网关，调⽤到新节点去 |
| 优点 | 实现简单，不存在数据新旧库不⼀致的问题 | 不需要停服，对业务⽅⽆感 |
| 缺点 | 需要停服通知业务端针对⾦融内部调⽤财务的接⼝，需修改代码，增加开关逻辑 | mq消息消费问题⽆法解决fegin调⽤接⼝也需要梳理，转发复杂度较⼤ |
经过线上流量时间分布与次数调用统计，一番battle下来，领导决定选择地狱难度，把困难留给我，把方便留给人家。
事已至此，全面考虑，定出上线步骤才是我最后倔强。
| 1 | 创建新数据库，通过DTS服务，同步需要迁移的表数据到新实例（提前） |
|---|---|
| 2 | 修改nacos配置，禁用所有旧节点服务（prod环境）的mq消费能力，只投递不消费，让消息堆积，重启让配置生效。这是为了避免新节点（huidu环境）的mq消息旧节点的服务消费，导致数据又落到旧服务（prod环境）去。配置：spring.cloud.stream.rocketmq.bindings.costTradeResult-in.consumer.enabled=false |
| 3 | 关闭xxljob的所有定时任务调度，切断流量达到减少流量进入的目的。 |
| 4 | 修改nacos配置，修改数据源地址，部署灰度环境（huidu环境）服务并启用，，这时候新节点服务还是没有任何流量进来的。 |
| 6 | 切换流量到灰度环境，通过nginx对流量打上对应灰度环境标⽰，通过配置MSE路由规则配置财务路由前缀规则+标签路由选择对应灰度环境下的zuul，这样做路由染⾊可以串联整个灰度环境。 |
| 7 | 修改nacos配置，开启mq消费能力，重启prod环境节点的服务，这时候prod环境=（myslq新实例，mq支持投递消费），huidu环境=（myslq新实例，mq支持投递），到此，数据源已经切换 |
| 8 | 下线灰度环境（去掉路由染色，回收服务） |
| 9 | 停掉DTS,新库不再同步旧库数据 |
| 10 | 启动定时任务，恢复流量 |
10步，通过添加中间商，左手倒右手的方式，完成了数据源的切换。
3、制定qb环境演练与线上环境验证计划
确实，为了保证数据库迁移过程中的数据完整性、服务平稳过渡，以及职位的安全，关键在于实施细致的服务监控。以下是一些监控措施的例子，这些措施能够帮助我实现目标：
- 消息队列（MQ）监控：对于基于消息队列的系统，监控是确保消息的正确传递、无丢失、无重复的关键。可以使用各种工具来监控队列的长度、处理时间和失败的消息等指标。
- 数据源监控：对于数据库服务，重要的是监控连接池的状态、查询响应时间、事务的持续时间以及读写操作的性能。这有助于我们及时发现性能瓶颈并进行优化。
- 日志监控：通过集成日志平台，我们可以实时观察系统的运行状态，包括错误日志、警告和其他关键事件。染色日志（日志染色）是一种技术，可以帮助我们追踪特定请求或事务的执行路径，这对于诊断问题非常有用。
- 性能监控：监控系统的CPU、内存、磁盘I/O和网络使用情况，可以帮助我们判断系统是否正常运行，以及是否存在资源瓶颈。
- 业务指标监控：监控业务关键指标，如交易量、用户活跃度等，可以帮助我们了解业务运行的整体状况。
阿里云云服务提供商提供了一整套的监控工具和服务，可以帮助企业轻松地实现上述监控需求。通过这些工具，可以及时发现并响应系统中的问题，确保迁移过程中的稳定性和连续性。
实战演习是确保迁移成功的关键环节，通过模拟迁移过程中可能出现的各种情况，我可以提前发现潜在的问题并制定相应的解决方案。这样的准备工作可以大大减少实际迁移时出现的风险，增加成功的可能性，从而保护我的“饭碗”。
写在最后
最终的上线过程是顺利的，也达到了预设的目的。
虽然前期考虑了很多业务上的场景，保留的数据的一致性，即使做了充分的准备和考虑，有时仍然会出现一些难以预见的问题，表现为有个简单的单表查询，没有排序，在旧库的查询是给到的结果是A-B-C,业务拿第一个A是正确的，通过DTS同步结果后，物理地址发生变化，导致记录顺序也发生了改变，查出来是B-A-C。这个也是这个任务的少少遗憾。
