问：传统单体项目（SSH 自研框架，未做业务拆分，阅读困难），新团队微服务改造，该基于老代码改造，还是？
2018yuli · 2023-01-24 09:25:18 +08:00 · 1537 次点击这是一个创建于 669 天前的主题，其中的信息可能已经有所发展或是发生改变。
 |
1
guisheng 2023-01-24 09:31:07 +08:00 via iPhone
单体项目理论上阅读不困难吧，都在一个包里面。屎山堆积这没办法的。给的时间和成本足够重构吗？支持的话看你们团队协商，不支持就没事好说的了。如果仅仅是为了微服务而微服务其实没这个必要，微服务我个人觉得的作用在于 熔断和降级优先保证重点服务。
|
 |
2
ql562482472 2023-01-24 09:59:33 +08:00
微服务还有个好处是强制对代码做了业务分割，避免了一次更新影响过大的问题 基于老代码改造在很多强业务领域项目是没办法的事情 因为老代码太值钱了 真的不能动 做过证券行业的人肯定懂什么意思
|
 |
3
Chad0000 2023-01-24 10:04:46 +08:00 via iPhone
老项目改成接口，一开始使用本地实现。然后换成远程调用。基本上就是这么个思路。
|
 |
4
silentsky 2023-01-24 10:25:35 +08:00 via Android
如果单体阅读都困难 那拆分之后应该更难阅读才对吧。阅读应该不是拆分的理由
|
 |
5
adoal 2023-01-24 11:07:30 +08:00 via iPhone  2
建议拖几年，拖到业界流行“微服务改造成单体”…
|
 |
6
2NUT 2023-01-24 13:05:02 +08:00
非必要不改造
一般都是重头写 原来的千万不能动 |
 |
7
yufeng0681 2023-01-24 15:38:31 +08:00
问得很不专业。 为了上微服务而上。 这估计又是个国企 /政府的项目。 有钱重新做一遍。
1 、业务要重新梳理，把功能描述清晰，不需要的功能全部拿掉，重要的功能先设计 2 、业务要平滑切，那数据库整改应该是最麻烦的。 重新开发要把重要数据割接到新数据库内。这个业务不熟练，有个遗漏闪失，也是要有人背锅的。 3 、上微服务的目的不明确，未来做出来的新业务，一样要各团队同步升级。项目没有超过 50 人，都不需要考虑微服务 |
 |
8
2018yuli OP 哈哈，我也来吐槽下：我们现在使用界面原型驱动😒，开发水平拆分的伪服务；外加 k8s 等先进技术；打造的专业坑人不讲理平台；不过业务+团队都有在升级呢，虽然现在骂声一片……😔
|
 |
9
coolair 2023-01-24 17:19:59 +08:00 via Android
时间充裕，人员充足，直接重写，否则，继续堆屎山吧。
|
 |
10
potatowish 2023-01-24 22:02:00 +08:00 via iPhone 1
先拆成模块，不要动不动就上微服务，很多项目做个负载均衡就够了，模块拆分是有利于后期做升级。
|
Select Language