实体服务是一种反模式

  • Jan Stenberg
  • 薛命灯

2018 年 1 月 2 日

话题:SOA语言 & 开发架构

在微服务架构中,最重要的是要保持服务间的隔离。实体服务(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

SOA语言 & 开发架构