所谓的微服务架构，是不是类似面向对象中的 GOTO 函数？

[liudaqi]

遇到一些拆分不合理的微服务架构，其实发现没有必要拆分。很多地方还是要把多个微服务请求数据再重新组合，还不如不拆分了。

[xuanbg]

拆分不合理不代表没有拆分的必要，只是拆分得不对而已。微服务的拆分，业界公认原则是按领域来进行拆分。

微服务的好处是一次建设终身受益。因为你在建设微服务体系的时候，会把业务无关的东西都拆分出来，变成整个系统所有业务共享的基础设施。这样一来，下一个业务就不需要重复建设这些基础设施，只需要关注业务本身就可以了，开发效率自然就大大提高。

[DoctorCat]

或许是因为康威定律呢

[xylophone21]

@xuanbg 技术探讨一下，拆分层一个模块和拆分成一个微服务，大家觉得区别在哪里？

[acmore]

其实确实没有必要为了微服务而微服务，虽然有很多理论指导和论证，但是真正应用的时候大多都是趟泥地。当拆分的好处远大于不拆分的坏处时自然就会拆分，而很多情况下微服务都会显著增加开发和维护成本。项目首先还得是个 Monolith 或者至少是有演化成为 Monolith 的趋势，这个时候开始制定拆分策略应该是比较合适的，很多项目大概都活不到这个时候。当然大多数时候都是拍板者拍板，干活的执行。

不过把微服务结果组合这件事是肯定要做的，在网关或者代理中集成数据然后统一返回对于消费端肯定效率更高，这点并不是不使用微服务的理由。

[xuanbg]

@xylophone21

单体服务：要死一起死。一个模块挂掉导致整个服务挂掉
微服务：死道友不死贫道。一个服务挂掉不影响非依赖服务
单体服务：要上一起上。搞点小改动，整个系统都升级
微服务：你上你的，我上我的。改哪个升级哪个
单体服务：搬来一大家子新邻居。每个系统都有一大堆基础功能模块
微服务：欢迎小朋友加入大家庭。多个系统可以共享基础设施

[xuanbg]

@acmore 不存在是否需要微服务，只存在是不是会搞微服务。不会搞瞎搞微服务，就会显著增加开发和维护成本。会搞微服务的，是显著减少开发和维护成本。因为基础设施的建设是前期一次性投入，后期只需要开发和维护纯粹的应用服务。单个应用服务相对于庞大的单体架构，只需要实现业务逻辑，复杂度会大大降低。