问：传统单体项目（SSH 自研框架，未做业务拆分，阅读困难），新团队微服务改造，该基于老代码改造，还是？

[2018yuli]

[guisheng]

单体项目理论上阅读不困难吧，都在一个包里面。屎山堆积这没办法的。给的时间和成本足够重构吗？支持的话看你们团队协商，不支持就没事好说的了。如果仅仅是为了微服务而微服务其实没这个必要，微服务我个人觉得的作用在于 熔断和降级优先保证重点服务。

[ql562482472]

微服务还有个好处是强制对代码做了业务分割，避免了一次更新影响过大的问题 基于老代码改造在很多强业务领域项目是没办法的事情 因为老代码太值钱了 真的不能动 做过证券行业的人肯定懂什么意思

[Chad0000]

老项目改成接口，一开始使用本地实现。然后换成远程调用。基本上就是这么个思路。

[silentsky]

如果单体阅读都困难 那拆分之后应该更难阅读才对吧。阅读应该不是拆分的理由

[adoal]

建议拖几年，拖到业界流行“微服务改造成单体”…

[2NUT]

非必要不改造

一般都是重头写

原来的千万不能动

[yufeng0681]

问得很不专业。 为了上微服务而上。 这估计又是个国企 /政府的项目。 有钱重新做一遍。
1 、业务要重新梳理，把功能描述清晰，不需要的功能全部拿掉，重要的功能先设计
2 、业务要平滑切，那数据库整改应该是最麻烦的。 重新开发要把重要数据割接到新数据库内。这个业务不熟练，有个遗漏闪失，也是要有人背锅的。
3 、上微服务的目的不明确，未来做出来的新业务，一样要各团队同步升级。项目没有超过 50 人，都不需要考虑微服务

[2018yuli]

哈哈，我也来吐槽下：我们现在使用界面原型驱动😒，开发水平拆分的伪服务；外加 k8s 等先进技术；打造的专业坑人不讲理平台；不过业务+团队都有在升级呢，虽然现在骂声一片……😔

[coolair]

时间充裕，人员充足，直接重写，否则，继续堆屎山吧。

[potatowish]

先拆成模块，不要动不动就上微服务，很多项目做个负载均衡就够了，模块拆分是有利于后期做升级。