在基于微服务的体系结构中，将不同的服务分离开来是很重要的。但是实体服务是一种反模式，它反对分离，Michael Nygard在一篇关于如何使用微服务的系列博客文章中声称。

Nygard是《释放它》的作者之一。他指出，实体服务是对一个经常被重新发现的问题的解决方案，并参考了微软(Microsoft)的微服务体系结构电子书和Spring的教程，后者提供了使用该模式的许多新示例中的两个。

对于Nygard来说，反模式是使事情变得更糟的模式。在论证实体服务实际上是一种反模式时，他以大型遗留单片应用程序为例。在这个应用程序中有多个实例的进程与所有功能本地和进程内:

将这个应用程序移动到一个微服务体系结构中，使用Spring教程中的一个示例，一些功能仍然包含在一个服务中，但是Nygard声称，大多数功能将需要由多个实体组成的聚合，从而在两个或多个实体服务之间创建依赖关系。一个例子是在购物车中设置的价格将涉及所有服务描述:

对于Nygard来说，这些依赖关系会导致操作耦合，从而影响可用性、性能和容量。他还注意到，它们创建了语义耦合，其中一个服务中的更改可能波及到其他服务。在最坏的情况下，这甚至可能导致服务需要处理不同版本的服务。

对于Nygard，当使用实体服务迁移到微服务体系结构时，产生的上下文包括:

因此，Nygard认为实体服务是反模式的声明符合标准。

在另一篇博客文章中，Fourth.com的首席架构师Ben Morris声称，在微服务体系结构中使用的实体服务比一块巨石还要糟糕，并引用了Nygard的文章。Morris认为，微服务的一个重要方面是自治，但是粒度越细的服务与其他服务的耦合就越多，从而破坏了这种重要的自治。他指出，对流程的更改可能很困难，因为它往往涉及许多服务，如果它们由不同的开发团队维护，情况会更糟。小型耦合服务的风险还在于，单个服务中的故障可能会产生级联效应，导致多个进程宕机。

尼加德的帖子引发了长时间的讨论。微软电子书的一位作者指出，他们在书中警告不要将微服务与HTTP调用耦合。他还指出了拥有正确的领域模型使微服务自治的重要性。

在即将发表的一篇博客文章中，Nygard将研究实体服务的替代方案。