微服务和Spring Boot进行分布式交易

时间:2019-03-06 07:17:45

标签: spring-boot distributed-transactions

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

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

我的问题如下:

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

因此,当我收到此数据时,必须立即添加用户和雇员。 想象现在添加了用户,但员工不是由于某种原因失败了吗?甚至更糟的是,当我删除用户时,员工不会被删除?

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

我发布问题是为了寻求新的想法,或者也许我缺少一些新技术。

谢谢

2 个答案:

答案 0 :(得分:0)

添加用户不必是身份验证服务的工作。将员工和用户都插入同一服务,然后将新用户通知auth服务。 (使用许多事件/消息传递系统之一)

答案 1 :(得分:0)

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

  1. SAGA模式-您已阅读
  2. 您在一项服务中进行交易,然后另一项服务侦听该事件并执行更新。就像在删除用户上一样,生成一个事件UserRemoved,然后Employee服务监听该事件并删除employee。

这对于在微服务中理解非常重要:

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

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

让我们在CreateEmployee中说,创建第一个用户ID的雇员由于某种错误而没有创建,然后再说一次,如果有人用相同的用户名创建了一个雇员,ID应该做什么。在这种情况下,如果创建员工来处理这样的情况,即如果该用户已经存在,那么检查员工是否也存在(如果不创建员工并返回)。

这样的情况将会更多,因此在微服务​​系统中应该是自动可纠正的,并且最终是一致的。每次都尝试完全一致的做法不是正确的目标。