【问题标题】:How to handle delete in microservice architecture?如何处理微服务架构中的删除?
【发布时间】:2021-02-05 23:51:29
【问题描述】:

我想创建一个带有任务/问题/聊天的项目管理系统。这不是出于学习目的的商业用途。它是简化的描述,仅包含提出问题所必需的内容。

如果用户是给定项目的成员,我遇到的第一个问题是如何使用任务服务添加任务,而无需每次都询问项目服务。我知道更多的 beetwen 服务通信 == 更多的问题、更多的延迟和通常的 AvoidBadTM。所以我决定为每个微服务使用 JWT。想要使用任务服务添加任务的用户需要先询问 Auth 服务:给我任务的 jwt、projectX 和包含权限。 Auth 将调用 Project 服务来验证用户是否是成员并生成正确的 JWT 令牌。我们仍然有通信 beetwen 服务,但它是对令牌生命周期的一次调用,而不是每次调用任务服务时都这样做。问题来了。

如果用户从项目中删除/禁止或项目被删除怎么办? 如果任务服务不关心项目 - 它只关心 JWT 是否有效,因此用户可以为项目 ID Y 创建任务 X,那么如何防止被禁止(来自项目)用户访问此服务?此外,如果项目被删除并且项目服务向事件总线“我删除项目 X”发出事件,那么任务服务会读取此事件并删除分配给项目 X 的​​所有任务。但是当某些用户仍然拥有有效的访问令牌并且他创建时该怎么办事件处理后的另一个任务?任务服务不检查项目是否仍然存在,结果我们在数据库中有悬空任务。

我对这个问题的解决方案是在任务服务数据库中存储有关现有项目的信息。只有 id,因此内存/存储空间占用很小。因此,当项目服务发出“项目已删除事件”时,任务服务不仅会清除具有给定 projectId 的所有任务,还会删除存储的 projectId,因此无法创建任务。这是一个好方法吗?被禁用户怎么办?要订阅的数据库和事件中的另一个条目?

【问题讨论】:

  • 任务服务中的项目 ID 对我来说似乎不错。它遵循聚合关系的 DDD 原则。对于被禁止的用户,为什么不通过跟踪任务/项目服务中的活动用户来使用类似的技术。只需用更合适的名称重命名用户,例如项目经理与 DDD 有界上下文规则保持一致。

标签: design-patterns architecture event-handling microservices domain-driven-design


【解决方案1】:

我对这个问题的解决方案是在任务服务数据库中存储有关现有项目的信息。只有 id,因此内存/存储空间占用很小。因此,当项目服务发出“项目已删除事件”时,任务服务不仅会清除具有给定 projectId 的所有任务,还会删除存储的 projectId,因此无法创建任务。这是一个好方法吗?

当然,任务应该知道它属于哪个项目,所以我看不出有什么问题 - 这是有道理的。

被禁止的用户怎么办?要订阅的数据库和事件中的另一个条目?

您提到“Auth 将调用项目服务来验证用户是否是成员并生成正确的 JWT 令牌”,因此结果应该是项目服务应该说用户不是项目的成员。现在,在您的系统中,您可能会拥有users 服务,该服务将有一个 API 来禁止用户。我认为应该发生的情况如下:

  • projects 服务中,您有一个名为members 的表,它在user_idproject_id 之间具有N to N 关系
  • 当管理员(不确定禁止过程在您的系统中如何工作)想要禁止用户时,它会调用 users 服务中的 API
  • users 服务将发出一个事件,表明 user 1 was banned
  • projects 服务将监听此事件并从members 表中删除此user_id 的记录

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2018-09-24
    • 2015-04-30
    • 2016-11-05
    • 1970-01-01
    • 2018-08-11
    • 2018-01-07
    • 2017-03-19
    • 1970-01-01
    相关资源
    最近更新 更多