实体服务是一种反模式
在微服务架构中，最重要的是要保持服务间的隔离。实体服务（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
正文到此结束
热门推荐
相关文章
近期评论
-
666
-
文章和留言都翻到11页了 没有OOM
-
-
朋友，翻页到11页，及以后，会出现OOM，无法访问
-
-
-
-
版本号是多少，你可以下载哪个代码仓库，jdk选1.8 直接跑就行
-
-
Loading...
![[HBLOG]公众号](https://www.liuhaihua.cn/img/qrcode_gzh.jpg)
