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
先拆成模块,不要动不动就上微服务,很多项目做个负载均衡就够了,模块拆分是有利于后期做升级。
|