实体服务是一种反模式

在微服务架构中，最重要的是要保持服务间的隔离。实体服务（ Entity Service ）是被广泛应用于微服务架构上的一种模式，但其实它是一种反模式，因为它背离了服务隔离的原则。 Michael Nygard 在他的微服务系列博客中提到了这一点。

Nygard 是“ Release It! ”的作者，他说实体服务被用于解决一个非常常见的问题，在微软的一本关于微服务架构的电子书中和Spring 的两个教程中均用到了这种模式。

在Nygard 看来，反模式只会让事情变得更糟。为了说明实体服务是一种反模式，他使用一个大型的遗留单体作为例子。这个应用程序有多个实例，每个实例都包含了所有特性：

根据Spring 的教程，使用微服务架构对这个应用程序进行重构，将特性分解到单独的服务中。但Nygard 说，大部分特性仍然需要多个实体，这样就会在多个实体之间形成依赖。比如，计算购物车的价钱需要所有服务的介入：

Nygard 认为，这些依赖会造成耦合，从而影响可用性、性能和容量。他还强调说，这些依赖导致语义上的耦合，一个服务的变更会波及到其他服务。在最糟糕的情况下，这样会导致一个服务需要与不同版本的服务打交道。

Nygard 总结了在微服务架构中使用实体服务将会产生的结果：

• 团队仍然可以按照他们的节奏发布服务。
• 语义上的耦合导致了跨团队的协商。
• 大量请求需要调用实体服务，增加了流量负载。
• 整体的可用性取决于更多的服务。

基于以上几点，Nygard 认为实体服务是一种反模式。

来自 Fourth.com 的首席架构师 Ben Morris 在另一篇博文中引用了 Nygard 的文章，他说，在微服务架构中使用实体服务比单体架构还要糟糕。Morris 认为，微服务的优势之一就是它的自治性，但细粒度的服务越多，它们之间的耦合就越大，从而降低了自治性。他强调说，流程的变更会变得很困难，因为困难涉及到大量的服务，而如果服务是由不同的开发团队进行维护的，那么变更会变得更加困难。使用大量小型耦合服务的另一个风险在于，一个服务发生故障会产生级联效应，影响到更多的服务。

Nygard 的博文引发了长时间的讨论。微软那本电子书的作者说，他们在书中已经针对使用 HTTP 调用来耦合微服务这样的做法提供了警告。他也强调，正确使用领域模型可以提升微服务的自治性。

在 Nygard 后续的博文中，他将会介绍实体服务的替代方案。

查看英文原文： Entity Services is an Antipattern