一、现状梳理

       需要改造的xx系统为一个较为陈旧的技术栈系统，其中MongoDB作为核心数据存储中间件，承担着存储全部xx数据的重要任务。该系统目前的配置为1主1副本模式，涉及1个数据库和2张表，服务于7个不同的应用。尽管系统架构相对简单，但其在日常运营中发挥着不可或缺的作用。由于遇到了性能问题和公司不再运维MongoDb，2024公司集团要求下线整个mongoDB数据库，因此需要将MongoDB存储在其它介质中。如何能够保障在不影响线上使用的情况下，平滑切流到新库，是本文主要探讨的问题。

二、迁移方案

与架构师经过多轮评审，最终沉淀了如下方案。

2.1 迁移节奏

整体节奏分为

1.梳理范围，因为系统内不仅有mongo还同时有mysql数据源，需要梳理出使用mongo的所有业务范围

2.确定好原有的数据，应该存储在哪个介质中，确定好存储标准，需要能够cover住原有的所有业务，包括读写性能

3.对原有数据结构的DAO层进行改造

4.需要对数据进行双写并进行数据迁移

5.R2流量验证/测试回归/数据比对 进行验证

6.切量:放量节奏

2.2 代码改造/数据异构

采用装饰器模式，统一控制双写逻辑（主写，辅写），统一控制切量逻辑，下线逻辑

抽取代码中原有的直接调用底层mongodb API的代码，将其不改业务逻辑的情况下迁移到Dao层。这样做的目的是为了后续做切流适配逻辑。不改逻辑及出入参的目的是为了避免对当前业务造成影响。如下图所示

另外选用数据源的依据为

2.3 存量数据迁移

考虑整体的数据量并不大单表300w，通过大数据离线表的方式效率并不高，通过代码更加的灵活，可以随时调整速度和范围存量数据分了两部分1、已经审核通过，申请单不会在有任何变更，可以随时迁移，比对2、申请单处于过程中的数据，数据随时会变更。凌晨迁移，打开双写

2.4 增量数据同步

创建申请单和更新不包含状态字段时的操作

先写mongo再写mysql，以mongo写入成功为准，写mysql失败，mq异步补偿

三、上线三板斧(灰度/监控/回滚)

3.1 可监控(数据对比读逻辑)

增量数据比对

双写数据完成后发送MQ，消息里面查询新库，老库的数据进行实时比对，不一致数据记录不一致字段，关键字业务报警，写入日志文件，导出分析

存量数据比对

遍历全量老库数据，与新库查出数据，转换成相同对象对比数据一致性，异常数据写入日志文件分析

3.2 可监控(对比读逻辑)

对比逻辑，引入R2流量回放对比，提高对比速度，

3.3 可灰度(灰度切量读)

读切流，按照供应商和采销白名单+百分比来切流

切流时，由于需要根据pin对流量分散，但是不在同一线程内，使用threadlocal对商户信息进行设置和读取

3.4 可回滚(灰度切量写)

写切流 分为四步

1.首先验证 写新库没问题 相当于对新加代码进行灰度 如果有问题 进行回切

2.当验证写新库没问题，需要补齐数据库数据

3.当数据补齐后 转换为主写新库

4.后续如果读写新库都没问题 可以彻底下线旧库存

3.5 可灰度(具体放量计划)

提前创建灰度切量沟通群，拉取最近一个月的活跃供应商和采销，定向加白名单，第一次放量提前和采销沟通，确保使用过程中如果有问题可以第一时间周知。

四、总结

本文梳理了一次线上生产库的全流程梳理和迁移切换对比灰度方案，希望能够为遇到同样的问题的同学提供一些参考，有意愿交流的同学可以私信我