求指教后端项目迁移方案

[seedhk]

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

其实是我主动提的

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

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

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

发布方案

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

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

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

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

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

[macaodoll]

某国产是啥？

[seedhk]

@macaodoll nutz

[flyqie]

为啥要主动提，是没办法维护了吗

[seedhk]

@flyqie 确实不好维护，一是官方已经不管更新了，全靠爱好者和使用者推送更新，他们再 merge 。
二是框架太老，很多东西都没有，很多东西也没法接。

[lsk569937453]

结论:大聪明。你完蛋了，准备提桶跑路吧。

如果我的老大给我提个需求要换个框架重构，我都要自己跑路。你还自己提出来，这就是挖坑给自己跳。我自己碰到现实中不得不重构的原因:
1.新来的领导换技术栈，招自己心腹来，把老员工排挤走。
2.公司合并，老的组离职了，老代码维护不了，线上频繁出问题，需要重构。

说下为啥不推荐超大项目重构的原因：
1.重构期间还接新需求吗，你这 700 个接口大概率半年是搞不完的。这半年期间，你不接新需求了吗？如果一边接新需求一半重构肯定对重构进度/接新需求进度有影响(否则就需要招人来做，你和老板说我自己干不过来，那你提重构搞毛啊)。
2.越大的项目需要的回归测试周期越长，有的代码单元测试都没有，就是黑盒。只要这 700 个接口有一个重要接口重构有问题，你就得负责背锅。
3.腾讯的 QQ 重构的时候都会出问题，你是不是觉得你比腾讯的工程师还 6 。

再说下重构的方案:
1.先把当前受影响的接口重构(你生产环境跑的好好的，没有问题。重构就是自己找罪受)
2.不重构，新需求直接上 springboot 那一套。

[frank1256]

方案 1 就行了，用同一个域名，请求头或者请求体加个参数例如 x-new:true ，nginx 之类的根据参数反向代理到不同新旧就行了

[seedhk]

@lsk569937453
1.小公司没那么严格，没有绩效考核，半年内不接新需求问题也不大
2.领导只是有这个想法，如果把时间节点列给他看(比如超过半年，是否要做看他意见)；
3.我只是提过建议，没说一定要做，是领导说要换框架，我才开始做技术方案；
4.测试确实是个大问题，怎么测试还没想好；

[seedhk]

@frank1256 谢谢

[ruiyinjinqu]

方案一比较靠谱，风险小，对于已经稳定的服务没必要管，毕竟又不是啥非得迁，对于不适合用老框架的接口用 springboot ，然后用微服务一套，可以用 gateway 作为中间层转发请求，可以慢慢迁移，接口有问题了切回老接口就行了，当然要是想迁移的顺利，新的一套东西要好好考虑兼容性，如果是国企，考虑好国产化合规方面，然后想说的这个完全吃力不讨好

[seedhk]

@lsk569937453 谢谢大佬提醒。补充下，这个重构不涉及业务重构，只是单纯把代码迁过去，能保证访问通，数据对得上就行了。理论上只要传参、返回值不出问题，应该没问题。

[seedhk]

@ruiyinjinqu 提这个主要是原有框架确实太恶心 之前也想过新接口走新的一套框架，老接口如果涉及业务改动再迁移。奈何领导今年想直接把框架还掉。

[thevita]

看具体签约什么东西, 如果整体架构不动，仅迁移 web 层（也就是 controller ），可以搞个自动转换一步到位，再手动改改，当然，前提是 web 这层得薄，但你提到维护性有问题，所有这个假设概率不成立，框架并不能帮你解决维护问题

[seedhk]

@thevita 框架会变，但是业务逻辑和代码逻辑不动。目前正在开发一个工具，支持将原有代码分层(原有代码没有分层的概念，所有代码都写在 controller 上)。这个工具有两个目的：
1.进行分层(controller 、service 、dao);
2.将原有框架中的一些自定义的类(主要是一些工具类，比如 NutMap 等)进行转换

[sagaxu]

单元测试覆盖率有没有 90%？接口测试覆盖率有没有 90%？两样都没有，人力测试的工作量是巨大的，且一定会出错。

700 个接口了，且半年不接新需求都 OK ，换句话说基本上功能稳定不做改动了，一个养老项目而已，那换框架的意义何在？

能多盈利还是能降低成本？在管理层看来，做成了你等于啥也没做，出问题了全怪你。

这种高投入高风险且无收益的事情，就是领导要推进也得劝他三思啊。

[seedhk]

@sagaxu
1.原有项目没有任何的单元测试和接口测试；
2.项目是核心项目，半年不接新需求都 OK 指的是我个人可以半年都投在这个项目里面而不需要担心因为没接新需求导致绩效很差。其他同事会在新项目上继续开发。

[seedhk]

@sagaxu
补充：
3.从公司层面看，确实是如此

我会把这些内容和领导说清楚，具体弄不弄看他的意见。

[yrj]

方案一吧，还能看到点成果。方案二我怕还没等重构完，公司都黄了 ：）

[amon]

作为一个有着丰富大重构和迁移经验（踩坑）的人，友情提示几句：

重构的前提条件：
1. 业务在持续增长，甚至增长迅速，原有的系统无法满足
2. 领导层和业务方对这个事情知悉，并且是不反对的态度
3. 你准备在这家公司长久地呆下去

[hui9000]

太天真了，刚开始都想着只迁移业务代码，迁过去后，哪哪都飘红，改完还得测。
能不动就别动。

[hui9000]

我就没见过这种迁移能顺利的。真的。