logo标签列表

微服务架构中的分布式事务

microservicesdistributed-transactionssaga
7
我有两个微服务 S1 和 S2。 S1 调用 S2 更新数据，然后 S1 插入另一个数据，但是如果 S1 失败了，我们需要回滚由 S2 更新的数据，否则我们将处于不一致状态。
我也研究过 Saga 模式，它能解决这种不一致性吗？
还有其他更好的解决方案吗？
3个回答
4
分布式事务在大多数情况下都有问题，对服务也不利。
  • 服务边界-服务边界是信任边界。原子事务需要保持锁定并代表外部服务持有它们，这会打开安全漏洞（使得拒绝服务攻击变得更容易）。你不能假设两个不同实体或资源之间具有原子性，尤其是当这些资源属于不同的企业时。
  • 事务引入了严格的耦合关系，包括时间和操作上的。
  • 事务阻碍了可扩展性-并不是说你不能扩展，而是更难。

Saga模式（顺便说一句，不需要编排）作为协调解决方案出现，因为它们可以让服务更加灵活-实际上更接近于现实生活的工作方式。您可以将另一种模式与Saga相结合，以帮助延迟效果，例如预订。

您还有另一个选择，即重新考虑如何分区服务。可能现在您拥有的服务边界不正确，重新设计将把所需的事务包含到一个服务中。

2
我认为Saga模式（编排）使应用程序能够在不使用分布式事务的情况下在多个服务之间维护数据一致性。
这种解决方案有以下缺点：
编程模型更复杂。例如，开发人员必须设计补偿事务，显式地撤消先前在saga中进行的更改。
还需要解决以下问题：
为了可靠，服务必须原子地更新其数据库并发布事件。它不能使用传统机制跨数据库和消息代理进行分布式事务。
0

如果S1和S2都是“在您的控制范围内”，那么最好设计它们的方式，不需要分布式事务。毕竟，微服务应该是独立的服务。如果它们必须共享一个事务，则它们显然不是独立的。

如果只有其中一个在您的控制范围内，而另一个不在，则最简单的方法是按一种不需要回滚不在您控制范围内的服务的方式进行调用。如果幸运的话，您甚至可以按一种方式排序调用，即使在您的服务中也不需要任何回滚。记住，您不必解决分布式事务的一般问题，只需解决您面临的实际用例！

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接