实体服务是现在应用于微服务的一种常见模式

科技 2020-02-05 16:30:04

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

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

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

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

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

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

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

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

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

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

郑重声明:本文版权归原作者所有,转载文章仅为传播更多信息之目的,如作者信息标记有误,请第一时候联系我们修改或删除,多谢