伙计们，我正在评估关于维护我们在分布式（微服务）架构中面临的db原子性（跨多个表）的关键挑战的选项/模式和实践。
原子性，可靠性和规模都对业务至关重要（它可能在各个业务中很常见，只是把它放在那里）。
我读过几篇关于实现的文章，但这一切都需要付出巨大的代价，并且没有一定的权衡，我还没准备好。
阅读几个SO问题，一个概念SAGA似乎很有趣，但我不认为我们的遗留数据库是为了处理它。
所以我在这里向专家询问他们的个人意见，指导和过去的经验，这样我就可以节省时间和精力，而无需尝试和学习一系列选项。
感谢您的时间和精力。
CAP定理
CAP定理是分布式系统的关键。从此开始，了解您是否需要可用性与一致性。
分布式事务
你是对的，权衡利弊，没有正确的答案。当谈到分布式交易时，它没有什么不同。在微服务架构中，Atomicity并不容易实现。通常我们通过记住最终的一致性来设计微服务。强一致性非常困难，而不是简单的解决方案。
SAGA vs 2PC
2PC使用2阶段提交很容易实现原子性，但该选项不适用于微服务。您的系统无法扩展系统，因为如果任何微服务发生故障，您的事务将陷入异常状态，并且锁定在此方法中非常常见。
SAGA是最可接受和可扩展的方法。一旦完成需要发布事件，就提交本地事务（原子），所有感兴趣的服务都必须使用事件并更新自己的本地数据库。如果存在异常或特定微服务无法接受事件数据，则会引发补偿事务，这意味着您必须撤消并撤消所有微服务针对该事件采取的操作。这是广泛接受的模式并且是可扩展的。
我没有得到遗留数据库部分。是什么让你认为遗留数据库会有问题？ SAGA与遗留系统无关。它只是意味着你必须接受这个事件。如果是，则将其保存到数据库中。如果没有则提高补偿交易，以便所有其他服务可以撤消。
什么是正确的方法？
嗯，这最终取决于你。在保存事务方面有很多模式。查看用于保存所有域事件的CQRS和事件源模式。由于受干扰的交易可能很复杂。 CQRS解决了许多问题，例如最终的一致性等
希望有所帮助！如果你有问题，请给我一些问题
一种可能的选项是命令查询责任隔离（CQRS） - 维护一个或多个包含来自多个服务的数据的物化视图。这些视图由订阅每个服务在更新其数据时发布的事件的服务保留。例如，在线商店可以通过维护加入客户和订单的视图来实现查询特定区域中的客户及其最近订单的查询。该视图由订阅客户和订单事件的服务更新。