在分布式架构(微服务)中实现数据库原子性的模式和建议指南

Question

朋友们，我正在评估在分布式(微服务)架构中维护数据库原子性(跨多个表)的关键挑战的选项/模式和实践。

原子性、可靠性和可扩展性对于业务来说都是至关重要的(这可能在整个业务中都很常见，只是把它放在那里)。

我很少读到关于实现的文章，但这一切都是以巨大的成本为代价的，而且不是没有某些权衡，这是我还没有准备好的。

读几个SO问题，一个概念传奇似乎很有趣，但我不认为我们的遗留数据库意味着要处理它。

因此，我在这里向专家请教他们的个人意见、指导和过去的经验，这样我就可以节省时间和精力，而不需要尝试和学习一堆选项。

感谢您的时间和努力。

Answer 1

CAP定理

当涉及到分布式系统时，上限定理是关键。从这里开始，了解您是否需要可用性和一致性。

分布式事务

你是对的，权衡是涉及到的，没有正确的单一答案。当涉及到分布式事务时，它也是如此。在微服务架构中，原子性并不容易实现。通常，我们通过保持最终的一致性来设计微服务。强一致性是非常困难的，也不是一个简单的解决方案。

SAGA vs 2PC

2PC使用两阶段提交很容易实现原子性，但该选项不适用于微服务。

SAGA是最可接受和可伸缩的方法。提交本地事务(原子地)完成后，您需要发布事件，所有感兴趣的服务都必须使用该事件并更新它们自己的本地数据库。如果出现异常或特定的微服务不能接受事件数据，它将引发补偿事务，这意味着您必须撤销和撤消所有微服务对该事件所做的操作。这是被广泛接受的模式，并且是可伸缩的。

我不明白遗留的数据库部分。是什么让你认为遗留数据库会有问题？SAGA与遗留系统无关。这仅仅意味着你是否必须接受事件。如果是，则将其保存到数据库中。如果不是，则引发补偿事务，以便所有其他服务都可以撤消。

什么是正确的方法?

好吧，这最终真的取决于你。当涉及到保存事务时，有许多模式。看看CQRS和事件源模式，它用于保存所有域事件。因为受干扰的事务可能很复杂。CQRS解决了许多问题，例如最终的一致性等。

希望这能有所帮助！如果你有问题可以问我。

Answer 2

一种可能的选择是命令查询责任隔离(CQRS) -维护一个或多个包含来自多个服务的数据的实体化视图。视图由订阅每个服务在更新其数据时发布的事件的服务保留。视图由订阅customer和order事件的服务更新。