何时不应该使用微服务

我们从以下四个方面来考量：

1.构建分布式系统的复杂性

因为微服务是分布式和细粒度的，所以他们在应用程序中引入了一层复杂性，而在单体应用程序中就不会出现这样情况。微服务架构需要高度的运维熟练度。除非组织愿意投入高分布式应用程序获得成功所需的自动化和运维工作（监控、伸缩），否则不要考虑使用微服务。

2.虚拟服务器/服务散乱

微服务最常用的部署模式之一就是在一个服务器上部署一个微服务实例。在基于微服务的大型应用程序中，最终可能需要50-100台服务器或容器，这些服务器或容器必须单独搭建和维护。及时在云中运用这些服务的成本较低，管理和监控这些服务器的操作复杂性也是巨大的。

3.应用程序的类型

微服务面向可服用性，并且对构建需要高度弹性和可伸缩性的大型应用程序非常有用。这就是这么多云计算公司采用微服务的原因之一。如果读者正在构建小型、部门级的应用程序或具有较小应用群的应用程序，那么搭建一个分布式模型（如微服务）的复杂性可能太昂贵了。

4.数据事务和一致性

开始关注微服务时，需要考虑服务的数据使用模式以及服务消费者如何使用他们。微服务包装并抽象出少量的表，作为执行“操作型”任务的机制，如创建、增加和执行针对存储的简单查询，其工作效果很好。

如果应用程序需要跨多个数据源进行复杂的数据聚合或转换，那么微服务的分布式性质会让这项工作变得很困难。这样的微服务总是承担太多的职责，也可能变得容易受到性能问题的影响。

还要记住，在微服务间执行事务没有标准。如果需要事务管理，那就需要自己构建逻辑。

参考 Spring微服务实战