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

• 資深大佬 : xuanbg

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

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

• 資深大佬 : DoctorCat

  或许是因为康威定律呢

• 資深大佬 : xylophone21

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

• 資深大佬 : acmore

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

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

• 資深大佬 : xuanbg

  @xylophone21

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

• 資深大佬 : xuanbg

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