实体服务增加了系统复杂性
极客时间编辑部
讲述：杜力大小：1.21M时长：02:39
最近，独立软件顾问塔里克·阿贝德拉博（Tareq Abedrabbo）认为，实体服务是一种微服务的反模式，主要是因为实体服务在浅模块、接口和功能之间的关系比较复杂。
据了解，实体服务是在定义了系统实体（或名词）之后才开始建模的，例如帐户服务、订单服务和客户服务。通常来说，它们具有类似 CRUD 风格的接口，用于操作这些实体。
因为采用了类似 CRUD 的方法，实体服务往往不包含任何有意义的业务功能。它们是浅模块的，并不能真正提供任何复杂或有用的抽象功能。因此，为了实现对功能的需求，最终会在以下这些服务之间进行耦合：
从概念上看，实体服务是小型的“浅”服务。除了操作或暴露内部状态之外，它们所作的事情很少。因此，通常需要将它们组合起来使用，从这个意义上讲，它们并不是真正解耦或独立的；
当复杂的查询需要访问多个数据源时，它们不是实体服务，并且通常会作为单独的服务或视图；
良好的抽象可以最小化或隐藏不必要的细节，从而简化我们对系统的思考方式。
阿贝德拉博表示，这些浅实体服务最终将形成一个高度耦合的组件集群。这会为运营带来负担，因为他们必须部署、扩展和监控更多的组件。这种高度耦合也可能会为发布流程带来挑战，为了交付一个单独的功能，不得不部署大量的微服务。
另外，它还会造成单点故障，服务之间是相互依赖的，如果其中有一个发生故障，可能会导致整个系统崩溃。
阿贝德拉博介绍，实体服务带来了概念上的复杂性，因为无法立即得知它们是如何组合在一起的，而服务组合可以发生在系统中的任何地方，并且通常不能直观地看出来。
这种模式还很容易发生改变，通常情况下，实体服务和浅服务不会在它们的接口和功能之间，提供有意义的中间层。因此，客户端不知不觉地与这些服务的实现细节相耦合，一直到数据库，维护人员很难在不破坏所有内容的情况下，来修改或优化系统。
阿贝德拉博表示，没有一种完美的方法可以将系统分解为微服务，他提出了一些最佳实践的建议。包括基于业务需求驱动的设计、有效地隐藏信息，以及避免在微服务之间共享上下文。他还建议，在进行分解时应该避免创建单点故障，允许系统的各个部分独立扩展，并通过将其保持在单个微服务边界内来轻松实现新功能。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
该免费文章来自《极客视点》，如需阅读全部文章，
请先领取课程
请先领取课程
免费领取
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
精选留言
由作者筛选后的优质留言将会公开显示，欢迎踊跃留言。
收起评论