模式指南和在分布式体系结构（微服务）中实现数据库原子性的建议

Question

伙计们，我正在评估在分布式（微服务）体系结构中面临的维护数据库原子性（跨多个表）的关键挑战的选项/模式和实践。

原子性，可靠性和可扩展性对于企业来说都是至关重要的（它可能在企业中很普遍，只是将其放在那里）。

我很少读到有关实现目标的文章，但这一切都是付出了高昂的代价，而且并非没有权衡取舍，这是我不准备做的。

阅读了几个SO问题，一个概念SAGA似乎很有趣，但是我认为我们的旧数据库并不是要处理它。

因此，我在这里向专家询问他们的个人意见，指导和过去的经验，这样我就可以节省时间和精力，而无需尝试学习很多选择。

感谢您的时间和精力。

Answer 1

CAP定理

CAP定理是分布式系统的关键。首先要知道您是否要可用性与一致性。

分布式交易

您是正确的，需要权衡取舍，没有正确的答案。当涉及分布式事务时，没有什么不同。在微服务架构中，原子性并不容易实现。通常，我们通过牢记最终的一致性来设计微服务。强大的一致性非常困难，而不是简单的解决方案。

SAGA与2PC

2PC ，使用两阶段提交很容易实现原子性，但是该选项不适用于微服务。您的系统无法扩展系统，因为如果任何微服务发生故障，您的事务将挂起异常状态，并且这种方法非常常见。

SAGA 是最可接受且可扩展的方法。一旦完成，就提交本地事务（从原子上来说），您需要发布事件，并且所有感兴趣的服务都必须使用该事件并更新自己的本地数据库。如果存在异常或特定的微服务无法接受事件数据，则会引发赔偿交易，这意味着您必须撤消所有服务并针对该事件撤消所有操作。这是被广泛接受的模式，并且可以扩展。

我没有遗留数据库部分。是什么让您认为旧版DB将出现问题？ SAGA与遗留系统无关。这只是意味着您是否必须接受事件。如果是，则将其保存到数据库中。如果没有，则进行补偿交易，以便所有其他服务都可以撤消。

什么是正确的方法？

嗯，这最终取决于您。保存交易的方式很多。看一下用于保存所有域事件的CQRS和事件源模式。由于交易受干扰可能很复杂。 CQRS解决了许多问题，例如最终一致性等

希望有帮助！如果有的话向我提问。

Answer 2

一个可能的选择是命令查询责任隔离（CQRS）-维护一个或多个包含来自多个服务的数据的实例化视图。这些视图由订阅每个服务在更新其数据时发布的事件的服务保存。例如，在线商店可以通过维护连接客户和订单的视图来实施查询，以查找特定区域中的客户及其最近的订单。该视图由订阅客户和订单事件的服务更新。