重构老旧电商服务CMS系统，数据表结构变化较大，不停服切换到新系统。有什么具体的解决方案，实现切换过程中基本数据无错误

每天逛逛论坛 ，发现自己啥也答不上来

顶一下帖,我也想知道

能想到的办法：使用 Canel 先做好老数据到新数据的实时同步（部分逻辑处理），保证老新均可访问。然后网关分流一点点切换过去直到新系统完全正常可用无异常。再下掉数据同步和老系统。

之前我们公司也有过类似的需求，而且我们是做sass平台的。跟你不同的是我们是其中一个模块重构了。表结构基本都换了，同时还需要兼容原本系统的功能。 当时我们的做法是： 1.同步旧系统数据转化成新表数据 2.在重构业务的模块的入口做数据复制（相当于维护新旧数据） 3.在新旧数据保持一致的时候逐步灰度测试新系统的出口数据是否一致。 4.在灰度测试没问题之后全量放开新系统出口（这个时候入口的数据也必须要同步维护，防止新系统出现问题还能快速切换为老系统） 5.等新系统逐步稳定后，停止旧系统入口数据的维护

其中难点在于如何保证新旧系统数据一致性的问题，以及要保证影响范围。在新系统没稳定之前，旧系统数据的入口必须维护，防止新系统出现问题能够切回旧系统继续正常运行。

重构的难度并不大，难度主要在于无缝切换的同时能够保证业务数据不出问题，即使在出问题的时候也能快速切换为原来的系统，控制好影响范围。

如果是部分服务, 或者微服务一个一个来重构, 可以考虑这样

1. 新服务部署, 暴露一个内网服务
2. 旧服务代码的业务逻辑全部去掉, 改成调用新服务的内网服务
3. 灰度部署旧服务, 看新服务的数据是否增长
4. 全量旧服务, 客户端改调用新服务.

如果是没有什么人访问的话，可以先搞个新的域名。然后写一套脚本，读取旧数据，写入数的数据库。然后切域名指向。

如果随时都有几十万人访问，分分钟几万条数据，不停服务器，觉的不可能做的到

你是马仔么？是的话这种东西找你们技术老大+产品+其它关联部门负责人出个切换方案出来，然后你这技术方案去执行。

如果你是技术老大，那就自己出个 step by step 的切换方案出来，让你的马仔去执行。

需要着重注意两点：

1. 完善的切换技术方案
2. 做好回滚策略

• 迁移新系统业务接口 的入参和出参 保持不变
• 新系统业务逻辑层完成双写（新旧数据库同步写入）
• 读的时候如果数据耦合度高且新增较快，读旧库（如果数据耦合度不高且可以独立的数据表，直接读新库）
• 灰度放量，完成流量切换
• 通过脚本旧库数据完全同步到新库
• 运行观察一段时间确保两侧数据增量一致
• 新系统业务逻辑层摘除双写，读逻辑切换为新库读取
• 迁移完成

我特别不喜欢做这种需求，还不停服转，这肯定得通宵搞。伤身体。。