BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

实体服务增加了系统复杂性

| 作者 Andrew Morgan 关注 3 他的粉丝 ,译者 无明 关注 1 他的粉丝 发布于 2018年7月16日. 估计阅读时间: 2 分钟 | QCon上海2018 关注大数据平台技术选型、搭建、系统迁移和优化的经验。

独立软件顾问Tareq Abedrabbo认为,实体服务是一种微服务反模式。主要是因为实体服务形成了浅模块,接口和功能之间的关系比较复杂。

实体服务是在定义了系统实体(或名词)之后才开始建模的。例如,帐户服务、订单服务和客户服务。通常,它们具有CRUD风格的接口,用于操作这些实体。

因为采用了这种CRUD的方法,实体服务往往不包含任何有意义的业务功能。相反,它们是浅模块,并不真正提供任何复杂或有用的抽象。因此,为了实现功能需求,最终会在这些服务之间引入耦合:

从概念上看,实体服务是小型的“浅”服务。除了操作或暴露内部状态之外,它们所作的事情很少。因此,通常需要将它们组合起来使用,因此从这个意义上讲,它们并非真正解耦或独立的。

当复杂的查询需要访问多个数据源时,它们不是实体服务,并且通常会作为单独的服务或视图。

良好的抽象最小化或隐藏不必要的细节,从而简化了我们对系统的思考方式。相比实体服务给我们带来的复杂性,它们的价值微不足道。

Abedrabbo说,这些浅实体服务最终将形成一个高度耦合的组件集群。这会导致运营负担,因为他们必须部署、扩展和监控更多的组件。这种高度耦合也可能导致具有挑战性的发布流程,为了交付一个单独的功能,不得不部署大量的微服务。

它还会造成单点故障,服务之间相互依赖,如果其中有一个发生故障,可能会导致整个系统崩溃。

Abedrabbo还解释说,实体服务带来了概念上的复杂性,因为我们无法立即得知它们是如何组合在一起的。服务组合可以发生在系统中的任何地方,并且通常不是很直观。

这种模式还很容易导致发生突破性变更:

更巧妙的是,实体服务和浅服务通常不会在它们公开的接口和它们实现的功能之间提供有意义的中间层。因此,客户端不知不觉地与这些服务的实现细节相耦合,一直到数据库。在这种情况下,由于接口和实现之间缺少中间层,服务实现者很难在不破坏所有内容的情况下修改或优化系统。

Abedrabbo总结说,没有一种完美的方法可以将系统分解为微服务,不过他建议了一些最佳实践。包括基于业务需求驱动的设计、有效地隐藏信息,以及避免在微服务之间共享上下文。在进行分解时还应该避免创建单点故障,允许系统的各个部分独立扩展,并通过将其保持在单个微服务边界内来轻松实现新功能。

查看英文原文Entity Services Increase Complexity

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT