实体服务是一种反模式

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

原文 

http://www.infoq.com/cn/news/2018/01/entity-services-antipattern

本站部分文章源于互联网,本着传播知识、有益学习和研究的目的进行的转载,为网友免费提供。如有著作权人或出版方提出异议,本站将立即删除。如果您对文章转载有任何疑问请告之我们,以便我们及时纠正。

PS:推荐一个微信公众号: askHarries 或者qq群:474807195,里面会分享一些资深架构师录制的视频录像:有Spring,MyBatis,Netty源码分析,高并发、高性能、分布式、微服务架构的原理,JVM性能优化这些成为架构师必备的知识体系。还能领取免费的学习资源,目前受益良多

转载请注明原文出处:Harries Blog™ » 实体服务是一种反模式

赞 (0)
分享到:更多 ()

评论 0

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址