在微服务架构中,最重要的是要保持服务间的隔离。实体服务( Entity Service )是被广泛应用于微服务架构上的一种模式,但其实它是一种反模式,因为它背离了服务隔离的原则。 Michael Nygard 在他的微服务系列博客中提到了这一点。
Nygard 是“ Release It! ”的作者,他说实体服务被用于解决一个非常常见的问题,在微软的一本关于微服务架构的电子书中和Spring 的两个教程中均用到了这种模式。
在Nygard 看来,反模式只会让事情变得更糟。为了说明实体服务是一种反模式,他使用一个大型的遗留单体作为例子。这个应用程序有多个实例,每个实例都包含了所有特性:
根据Spring 的教程,使用微服务架构对这个应用程序进行重构,将特性分解到单独的服务中。但Nygard 说,大部分特性仍然需要多个实体,这样就会在多个实体之间形成依赖。比如,计算购物车的价钱需要所有服务的介入:
Nygard 认为,这些依赖会造成耦合,从而影响可用性、性能和容量。他还强调说,这些依赖导致语义上的耦合,一个服务的变更会波及到其他服务。在最糟糕的情况下,这样会导致一个服务需要与不同版本的服务打交道。
Nygard 总结了在微服务架构中使用实体服务将会产生的结果:
- 团队仍然可以按照他们的节奏发布服务。
- 语义上的耦合导致了跨团队的协商。
- 大量请求需要调用实体服务,增加了流量负载。
- 整体的可用性取决于更多的服务。
基于以上几点,Nygard 认为实体服务是一种反模式。
来自 Fourth.com 的首席架构师 Ben Morris 在另一篇博文中引用了 Nygard 的文章,他说,在微服务架构中使用实体服务比单体架构还要糟糕。Morris 认为,微服务的优势之一就是它的自治性,但细粒度的服务越多,它们之间的耦合就越大,从而降低了自治性。他强调说,流程的变更会变得很困难,因为困难涉及到大量的服务,而如果服务是由不同的开发团队进行维护的,那么变更会变得更加困难。使用大量小型耦合服务的另一个风险在于,一个服务发生故障会产生级联效应,影响到更多的服务。
Nygard 的博文引发了长时间的讨论。微软那本电子书的作者说,他们在书中已经针对使用 HTTP 调用来耦合微服务这样的做法提供了警告。他也强调,正确使用领域模型可以提升微服务的自治性。
在 Nygard 后续的博文中,他将会介绍实体服务的替代方案。
评论