微服务学习八--什么时候用微服务架构

分布式服务集群产生的问题:

  1、分布式系统的数据一致性,当所有代码和数据都在一起的时候,可以利用事务和锁来解决,但是拆分成微服务架构后,要想很好的解决我们就需要引入分布式锁和事务的基本设施,如何用好它们?

  2、分布式系统因为大量节点和网络通信的存在,问题和故障的产生在设计的时候,其实就是一个常态。这样发现问题和定位问题就必须要比单体应用做的更好,但是因为系统的拆分,问题的定位也变的更复杂。对应的我们就需要设计一套故障管理的基础设施,实现指标收集、监控、报警和恢复,防止出现更严重的问题。

  3、在微服务架构中,变更变的更加的常见和频繁,而且因为服务拆分,应用本身也变的更多。这就需要一整套 CI/CD 的基础设施来支持管理这些应用以及应用的变更。持续集成Continuous Integration(CI)和持续交付Continuous Delivery(CD)

  4、早期设计的服务架构是否能很好的和组织架构匹配,其中一方发生变化的时候,另一方能否适应这种变化?持续重构带来的问题。

确定使用为服务需要考虑的问题:流畅的 CI/CD 系统、可靠的监控系统、变更管理系统、资源管理平台、良好的组织架构设计。

如果你的系统不到足够复杂的程度不要考虑使用微服务。

当业务不复杂,团队规模不大的时候,单块架构比微服务架构具有更高的生产率(productivity)。因为建立微服务架构需要额外的开销来支持和管理微服务,从而降低生产率;但是随着业务复杂性的增加和团队规模的扩大,单块架构比微服务架构的生产率下降更趋明显。

当复杂性达到一个临界点,微服务架构的生产率会优于单块架构,因为微服务的松散耦合自治特性减缓了生产率的下降趋势。

相关推荐