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