谢谢大佬，适合纯新人阅读吗?

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

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

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

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

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

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

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

@frank1256 谢谢

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

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

@macaodoll nutz

稳字第一，方案三。不同意再考虑其他的

一楼的办法，nginx 可以限制访问频率，超过就拉黑

spring 是你给他越多，他吃的越多。可以远程连接上去，或者借助一些三方工具看下具体的内存占用。
一般项目可能 256-512 就够用了