【问题标题】:distributed transactions with micro-services and Spring Boot使用微服务和 Spring Boot 的分布式事务
【发布时间】:2019-03-06 07:17:44
【问题描述】:

目前我正在将单体应用程序迁移到微服务中,我遇到的第一个问题是著名的分布式事务问题。

我有一个称为身份验证微服务的微服务,其任务是使用 Oauth2 对用户进行身份验证。

我的问题如下:

前端正在填写表格并发送大量数据,其中一部分属于员工微服务,另一部分属于身份验证服务

所以当我收到这些数据时,我必须同时添加一个用户和一个员工。 现在想象一下,添加了用户但员工不是由于某种失败?或者更糟糕的是想象当我删除用户并且员工不会被删除时?

所以您可能想到了 2PC 或 saga 模式,我花了 2 天时间阅读并权衡使用这些解决方案的可能性,但这使事情变得复杂,我认为我的问题不值得。

我发布这个问题是为了寻求任何新想法,或者我可能缺少一些新技术。

谢谢你

【问题讨论】:

    标签: spring-boot distributed-transactions


    【解决方案1】:

    添加用户不需要是身份验证服务的工作。在同一个服务中插入员工和用户,并通知新用户的身份验证服务。 (使用许多事件/消息系统之一)

    【讨论】:

    • 嗯,这个想法似乎很有趣,我会在与团队讨论后回复您
    • 所以当我通知新用户的身份验证服务时,我的身份验证服务将不得不将该用户保存在其数据库中以确保将来的登录......所以回到我们开始需要插入用户的地方在我们和员工之后,他们俩共享数据库的可能性是不可能的
    【解决方案2】:

    通常有两种方法可以达到相同的目的:

    1. SAGA 模式 - 你读过
    2. 您在一个服务中进行事务处理,然后另一个服务侦听该事件并执行更新。就像在用户移除时一样,生成一个事件 UserRemoved 并且员工服务会监听它并移除员工。

    在微服务中理解这一点非常重要:

    有时您公开的 api 可以说是创建员工,它应该同时创建用户和员工,并同时返回员工 ID 和用户 ID,因此这些事情无法在任何异步事务中处理。

    对于这些类型的事情,我们需要让系统自动纠正这种不一致。例如:

    让我们在 CreateEmployee 中说,首先创建的用户 id 由于某些错误而没有创建员工,然后再次如果有人创建具有相同用户名的员工,该 id 应该做什么。在这种情况下,如果创建员工处理这种情况,如果已经存在该用户,则检查员工是否也存在,如果不创建员工并返回。

    这样的情况会越来越多,所以在微服务系统中应该是自动更正并最终保持一致的。每次都尝试完全一致并不是正确的目标。

    【讨论】:

    • 拜托,你能澄清一下你的答案吗?
    • 如果你能说出需要澄清的具体部分会有帮助
    • 重新表述“这对理解微服务非常重要:”下的段落会有所帮助
    猜你喜欢
    • 2023-03-22
    • 2019-04-14
    • 1970-01-01
    • 2020-02-10
    • 2019-01-02
    • 1970-01-01
    • 1970-01-01
    • 2019-02-20
    • 2017-09-10
    相关资源
    最近更新 更多