【发布时间】：2018-02-05 06:30:32
【问题描述】：
在什么场景下，我们不应该使用微服务架构？到目前为止，我可以看到微服务的设计，在许多用例中看起来都不错。
我不会推荐用于 POC（概念证明）项目的基本用例之一。
【问题讨论】：
标签： architecture microservices software-design
【发布时间】：2018-02-05 06:30:32
【问题描述】：
这是一个非常广泛的问题，并且可能非常固执己见。当您拥有一个具有许多共享依赖项且通常始终作为一个单元部署的单个应用程序时，我不提倡使用微服务。
微服务很棒，它们也有自己的位置 - 但如果您的应用程序的性质总是作为一个单元部署，那么微服务会严重扩展复杂性 - 现在您正在部署大量单独的工件，一次完成，而不仅仅是一个应用程序。我想到的例子是 ERP 系统。
编辑：为了扩展这一点，微服务不应该是您应用程序的默认架构。让它尽可能简单，如果你遇到可扩展性问题，或者其他证明走微服务路线的理由，那就去做吧。尽可能保持简单。那么，恕我直言，“我什么时候不应该使用微服务？”的答案。是“当你不需要它们时”。
见YAGNI。
【讨论】：
在什么场景下，我们不应该使用微服务架构？
对于没有该风格试图解决的问题的场景，您不必应用微服务架构风格。那么是哪些问题呢？
在给出答案之前 - 微服务是一个流行词，它描述了一种试图回答“如何将应用程序分解为逻辑组件”这一古老问题的架构风格。虽然没有确切的定义，但它通常归结为具有特定领域目的的可独立开发和可部署的组件。所以考虑到这一点 - 以下是微服务架构风格试图解决的问题：
最重要的问题是在大型组织中扩展开发。微服务允许独立团队通过独立的发布周期快速行动。将其与必须聚合所有依赖项并且最多可以每几个月发布一个版本的大型“单体”进行比较。因此，每当一家公司试图组织数百名开发人员来开发基于服务器的大型应用程序时，他们可能应该考虑建立负责微服务的团队。这是因为“架构遵循组织”(Conway's law)。
应用程序本身的可扩展性。结合无状态设计，可以以集群方式大规模部署服务。因此，只要用户群随着时间的推移而增长，您很可能会从微服务架构风格中受益。
强制分离关注点。在“单体”开发中，通常会最小化持久性数据模式并让许多组件使用相同的数据库持久性。这通过添加间接依赖关系增加了复杂性，从而增加了发布新软件版本的沟通和组织开销。不允许微服务共享数据持久性，因此可以避免此问题。
通信问题。如果组件之间的通信没有很好地定义，那么重用组件的工作量就会急剧增加。尤其是在一个组件的多个版本的生命周期中。因此，微服务架构风格非常关注与外部世界定义良好的接口。这包括为下游消费者定义接口版本（主要/次要）。
那么关于你的结论：
我不会推荐用于 POC（概念证明）项目的基本用例之一。
基于以上几点，您的陈述不一定成立。如果它是一个大型团队的 POC 开发，并且您预见到任何提到的问题，您仍然会从微服务架构风格中受益。
【讨论】：