拆分成微服务疑问,按 controller 还是按照 project 拆?
先说个人不懂微服务,也没搞懂过
按照我的经验,通常就是拆分 controller 跟 service 由不同同事负责
不会刻意拆分不同 project,除非像是统一账号验证才会额外拆
但现在遇到一个顾问说,微服务要尽量拆分到不同 project 维护,各自有自己的 docker
这样才不会有严重依赖耦合
我不太能理解这样概念,工程复杂度直线上升
拆分成微服务疑问,按 controller 还是按照 project 拆?
先说个人不懂微服务,也没搞懂过
按照我的经验,通常就是拆分 controller 跟 service 由不同同事负责
不会刻意拆分不同 project,除非像是统一账号验证才会额外拆
但现在遇到一个顾问说,微服务要尽量拆分到不同 project 维护,各自有自己的 docker
这样才不会有严重依赖耦合
我不太能理解这样概念,工程复杂度直线上升
2 回答2.4k 阅读✓ 已解决
2 回答826 阅读✓ 已解决
1 回答1.4k 阅读✓ 已解决
2 回答1.5k 阅读
2 回答1.4k 阅读
2 回答1.2k 阅读
1 回答1.6k 阅读
如果老代码互相依赖很严重,不如不拆,就把基础模块拆出来行了,业务模块一个模块也没什么;
比如A用b,b用a就不如不拆,很简单的一个例子A业务上来了,扩容吧,A也用了B,B阔不阔?
有时候盲目拆没必要,做好灰度发布,维护好全局事务就行了