独立软件顾问 Tareq Abedrabbo 认为，实体服务是一种微服务反模式。主要是因为实体服务形成了浅模块，接口和功能之间的关系比较复杂。
实体服务是在定义了系统实体（或名词）之后才开始建模的。例如，帐户服务、订单服务和客户服务。通常，它们具有 CRUD 风格的接口，用于操作这些实体。
因为采用了这种 CRUD 的方法，实体服务往往不包含任何有意义的业务功能。相反，它们是浅模块，并不真正提供任何复杂或有用的抽象。因此，为了实现功能需求，最终会在这些服务之间引入耦合：
从概念上看，实体服务是小型的“浅”服务。除了操作或暴露内部状态之外，它们所作的事情很少。因此，通常需要将它们组合起来使用，因此从这个意义上讲，它们并非真正解耦或独立的。
当复杂的查询需要访问多个数据源时，它们不是实体服务，并且通常会作为单独的服务或视图。
良好的抽象最小化或隐藏不必要的细节，从而简化了我们对系统的思考方式。相比实体服务给我们带来的复杂性，它们的价值微不足道。
Abedrabbo 说，这些浅实体服务最终将形成一个高度耦合的组件集群。这会导致运营负担，因为他们必须部署、扩展和监控更多的组件。这种高度耦合也可能导致具有挑战性的发布流程，为了交付一个单独的功能，不得不部署大量的微服务。
它还会造成单点故障，服务之间相互依赖，如果其中有一个发生故障，可能会导致整个系统崩溃。
Abedrabbo 还解释说，实体服务带来了概念上的复杂性，因为我们无法立即得知它们是如何组合在一起的。服务组合可以发生在系统中的任何地方，并且通常不是很直观。
这种模式还很容易导致发生突破性变更：
更巧妙的是，实体服务和浅服务通常不会在它们公开的接口和它们实现的功能之间提供有意义的中间层。因此，客户端不知不觉地与这些服务的实现细节相耦合，一直到数据库。在这种情况下，由于接口和实现之间缺少中间层，服务实现者很难在不破坏所有内容的情况下修改或优化系统。
Abedrabbo 总结说，没有一种完美的方法可以将系统分解为微服务，不过他建议了一些最佳实践。包括基于业务需求驱动的设计、有效地隐藏信息，以及避免在微服务之间共享上下文。在进行分解时还应该避免创建单点故障，允许系统的各个部分独立扩展，并通过将其保持在单个微服务边界内来轻松实现新功能。
暂无签名
Java 避坑指南：Java 高手笔记代码篇
本迷你书包括 86 个业务开发中常见踩坑点。每一个知识点都相当的实用，是程序员业务开发中的必备避坑指南...
评论