求指教后端项目迁移方案

[seedhk]

公司原有项目是使用某个国产框架的，现在这框架已经很久没维护了，论坛也没啥人更新，于是要求迁移到 springboot 上

其实是我主动提的

前端是若干个小程序，项目架构是小程序通过 nginx 访问后端服务，没有网关，没有中间层；

梳理完业务和功能后，发现工作量巨大，700 多个接口。几乎所有接口都要手动改一遍。

目前正在确定发布方案和回滚方案，我思考的方案如下：

发布方案

• 方案一： 渐进式发布方案

1. 后端服务隔一定周期(比如一周)，或若干个模块，完成开发和测试后，先行上线一部分接口；
2. 新老项目同时并存，线上重新发布一个服务，端口待定，老的小程序访问老的项目，新的小程序访问新的项目；
3. 小程序端修改这部分接口的访问域名为新项目，并发布体验版进行内部测试；
4. 内部测试完成后上线；
5. 优点：
   1. 上线范围可控，数量可控，能减少一次性大规模部署带来的风险；
6. 缺点：
   1. 接口出现问题，因为小程序端修改了 URL ，无法快速回滚；

• 方案二： 整体迁移发布方案

1. 项目迁移完成且测试完毕后一起上线；
2. 新服务，或通过权重配置，切换一部分流量到新项目；
3. 新老项目同时并存，线上重新发布一个服务，端口待定，将 nginx 流量切换到新项目；
4. 内部测试完成后上线；
5. 优点：
   1. 接口出现大范围问题，可以快速切换回原项目；
6. 缺点：
   1. 接口多，出现问题几率大；

请问大佬们，有什么好的补充点以及方案吗？ 谢谢！

[dlmy]

我司把一个 20 年前的 php 项目用 Java 重构了一遍，2 年过去了，换了一个又一个的负责人，现在还没完全迁移成功。

主要原因如下：
1 、项目代码量 30w 行，接口上千个，以前开发不太规范，也没有注释，理解起来很困难
2 、项目存在时间久远，换了一波又一波的人，很多历史遗留问题跟业务问题没人能说得清
3 、与其他系统存在大量的交互，跨部门协调效率差，责任边界划分不明确，每天都在扯皮
4 、工作量巨大，每天都在无休止的加班赶进度，导致人心涣散，干好了没功劳，出问题得背锅

[timethinker]

你以为的重构，是使用新语言新框架重新写一遍已经存在的接口。但实际上这不叫重构，顶多算是用另一种语言重新翻译了一遍相同的东西。比如你提到的 700 多个接口，如果重构完毕之后还是有 700 个，那么意义何在呢？纯粹技术上的重构，不涉及业务改动真没必要。从成本收益上来考虑，如果不成正比，成功的可能性不大，当然你要为爱发电主动加班，领导何乐而不为呢？

[xuanbg]

你看，这个时候要是微服务的话，一个个服务慢慢换就是了。当然，现在要换也可以按微服务的方法来。就是旧服务当作微服务中一个特别大的服务，然后拆解一个上一个，直到拆完再下掉这个巨石服务就好了。

[8355]

这种相当于全部重构，整体流程不是这样的，这种项目对公司没有产出，现有功能是正常运行的，随时可能停止。
类似的活我干过，主要是为了性能优化，原来项目也是类似的需求，只不过原始版本太老了，性能差。
1.先用写一个代理工具，先收集一下请求流量的多少和接口的响应速度以及请求的高低峰。
2.了解现有项目接口的串行调用逻辑，按照业务系统操作流形成接口脑图同时制定重构计划（方便测试和定位问题）。
3.了解老系统用了哪些中间件，比如缓存/阿波罗/队列消费之类的，这里需要做好迁移方案尽量一起动。
4.根据因为前期有了代理工具可以收集入参出参可以进行数据对比检查和测试。
5.上线后的调用逻辑是
客户端请求 -> springboot 重构系统 -> 老系统
未重构的接口走老系统返回的数据直接返回
重构的上线前期对比自己的数据结果和老系统的结果是否一致，一致正常返回，不一致返回老系统的值并告警排查，稳定一段时间后减少老系统的请求转发（也可以等项目整体上线全部稳定以后再整体切换）。

整体切换对中间件的依赖连贯性更好，但是会产生双倍流量负载，包括数据库和缓存需要考虑扩容

[veapon]

如果真要搞，感觉方案一的缺点也可以克服啊，就是麻烦点，接口地址不变，新的接口地址通过 nginx 来代理到新项目，回滚时，把这部分配置注释掉就行。

[muyiluop]

看标题我就猜是不是 nutz 。因为我们之前也用，好多东西得自己接

[lizy0329]

改好就有由头辞退你了，你好生想想。上线之日就是你 fire 之时:)

[seedhk]

@yrj @veapon 我也倾向于方案一
@amon 感谢大佬的分享，我也会把这些东西跟领导说清楚
@hui9000 @dlmy @timethinker 就算顺利，估计时间上也要半年至少,加班是不可能加班的
@xuanbg 别说微服务了，，，之前连日志都没记下来
@8355 感谢大佬，我也打算写一个代理工具，收集原有项目的接口、参数、返回值，调用频率等，不过不是为了做代理，而是为了拿来做接口测试
@muyiluop 哈哈哈哈，这框架性能上可能比 spring 好(没经过测试，体感)，就是社区生态不够
@lizy0329 哈哈哈哈，说的我有点慌

[flmn]

700 多个接口的项目，这边不推荐重构呢。