这是一个创建于 1488 天前的主题，其中的信息可能已经有所发展或是发生改变。
遇到一些拆分不合理的微服务架构，其实发现没有必要拆分。很多地方还是要把多个微服务请求数据再重新组合，还不如不拆分了。
 |
1
xuanbg 2020-10-28 22:42:34 +08:00
拆分不合理不代表没有拆分的必要，只是拆分得不对而已。微服务的拆分，业界公认原则是按领域来进行拆分。
微服务的好处是一次建设终身受益。因为你在建设微服务体系的时候，会把业务无关的东西都拆分出来，变成整个系统所有业务共享的基础设施。这样一来，下一个业务就不需要重复建设这些基础设施，只需要关注业务本身就可以了，开发效率自然就大大提高。 |
 |
2
DoctorCat 2020-10-29 00:02:55 +08:00
或许是因为康威定律呢
|
 |
3
xylophone21 2020-10-29 10:13:03 +08:00
@xuanbg 技术探讨一下，拆分层一个模块和拆分成一个微服务，大家觉得区别在哪里？
|
 |
4
acmore 2020-10-29 11:18:19 +08:00
其实确实没有必要为了微服务而微服务，虽然有很多理论指导和论证，但是真正应用的时候大多都是趟泥地。当拆分的好处远大于不拆分的坏处时自然就会拆分，而很多情况下微服务都会显著增加开发和维护成本。项目首先还得是个 Monolith 或者至少是有演化成为 Monolith 的趋势，这个时候开始制定拆分策略应该是比较合适的，很多项目大概都活不到这个时候。当然大多数时候都是拍板者拍板，干活的执行。
不过把微服务结果组合这件事是肯定要做的，在网关或者代理中集成数据然后统一返回对于消费端肯定效率更高，这点并不是不使用微服务的理由。 |
|
5
xuanbg 2020-10-29 13:29:46 +08:00
@xylophone21
单体服务：要死一起死。一个模块挂掉导致整个服务挂掉 微服务：死道友不死贫道。一个服务挂掉不影响非依赖服务 单体服务：要上一起上。搞点小改动，整个系统都升级 微服务：你上你的，我上我的。改哪个升级哪个 单体服务：搬来一大家子新邻居。每个系统都有一大堆基础功能模块 微服务：欢迎小朋友加入大家庭。多个系统可以共享基础设施 |
Select Language