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

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

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

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

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

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

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

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

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

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