微服务中的分布式事务

Question

我有2个微服务S1和S2。 S1调用S2更新数据，然后S1插入另一个数据，但是让我们考虑S1失败，然后我们需要回滚S2更新的数据否则我们将处于不一致状态。

我也经历了Saga模式，它将满足这种矛盾

有人可以为此提出任何更好的解决方案吗？

Answer 1

我认为Saga模式（编排）使应用程序可以在不使用分布式事务的情况下跨多个服务维护数据一致性。

此解决方案具有以下缺点：

编程模型更复杂。例如，开发人员必须设计补偿性交易，以明确撤消先前在传奇中所做的更改。

还需要解决以下问题：

为了可靠，服务必须自动更新其数据库并发布事件。它不能使用跨越数据库和消息代理的分布式事务的传统机制。

Answer 2

在大多数情况下，分布式事务都存在问题，并且不利于服务

• 服务边界–服务边界是信任边界。原子 交易需要持有锁并代表他们持有 外交部门正在开设一个安全漏洞（这使得 进行拒绝服务攻击）您不能假设 两个不同的实体或资源。 Esp。这些资源何时属于 到不同的业务。
• 事务引入了时间和操作上的紧密耦合
• 交易阻碍了可扩展性–这不是您无法扩展 但这要困难得多

Sagas（顺便说一句，不需要进行编排）之所以成为一种协调解决方案，是因为它们使服务更灵活-实际上更接近现实生活的工作方式。您可以与Sagas结合使用以帮助延缓效果的另一种模式是reservation。

您拥有的另一个选择可能是重新考虑如何划分服务。可能是您现在所拥有的服务边界不正确，并且重新设计会将所需的事务包含到一项服务中

Answer 3

如果S1和S2都在“您的控制之下”，那么比以不需要分布式事务的方式设计它们要好得多。毕竟，微服务应该是独立服务。如果必须共享交易，它们显然不是独立的。

如果只有其中一个处于您的控制之下，而另一个则不在您的控制之下，那么最简单的方法就是以一种不需要回滚不在您控制之下的服务的方式来订购呼叫。如果幸运的话，您甚至可以以不需要任何回滚的方式来订购电话，甚至在您的服务中也不需要。请记住，您通常不必解决分布式事务，只需解决您面临的实际用例即可！