根据我的理解，当数据库事务跨越微服务时，我们可以通过发布事件使用message-broker（kafka，RabbitMQ等）来解决这个问题，以便Subscriber Microservices可以通过监听这些事件来更新他们的数据库。
如果发生异常，我们可以发送失败事件，以便订阅者服务可以更新其状态。
这还不够吗？这种方法有什么问题？
为什么以及何时需要事件采购？
我们真的需要事件采购吗？
答案 0 :(得分：4)
完全没有。您可以拥有一个非常明确的微服务式架构，而无需CQRS和事件源。 CQRS和Event Sourcing是微服务内设计的解决方案。您可以选择使用CQRS和事件采购来实施全部或部分微服务。
让我们看看事件采购如何帮助您。 Event Sourcing是使用事件而不是像Entity Framework或Hibernate和SQL数据库这样的ORM来恢复实体当前状态的替代方法。假设您有一个微服务来存储有关Books的数据。如果使用SQL，则可以使用控制器和端点来创建，更新和删除书籍，并将这些书籍存储在SQL表中。如果要更新该书，那么为了获得当前状态，您将返回到SQL表并查询该书（通过其id），然后您的ORM将该表表示转换为书籍对象（对象关系）阻抗不匹配问题）然后您将应用更改并将更改的书对象保存回SQL表。作为替代方案，您可以将书籍对象的事件存储在NoSQL数据库（如MongoDB）或事件存储库中。现在，为了更新本书，首先您需要恢复当前状态，并且可以通过返回与本书相关的所有事件并重播这些事件来恢复当前状态来实现。您的事件成为事实的来源，您完全避免了ORM映射和SQL连接的瓶颈。事件存储为JSON文档，通常超快。
现在，来到CQRS - CQRS纯粹是一种分离关注点的模式。您可以使用CQRS从写入端分叉您的读取端。与写入端相关的端点（如创建，更新和删除）存在于一个服务中，端点用于读取端存在于另一个服务中。您在这里获得的优势是独立扩展，部署，维护等等。如果您的应用程序是读取密集型的，则会为读取端服务部署多个实例。
如果您想了解更多信息，请随时与我联系。祝你好运！
答案 1 :(得分：3)
我认为您对微服务的东西感到困惑:)他们是设计可扩展应用程序的解决方案，与数据库事务无关。更重要的是，db事务（理想情况下）不应跨越进程，永远不要使用微服务。
pub-sub方法是不同的微服务（也适用于过程模型）进行通信的方式。与db事务无关。事件采购就是将域状态视为相关变更的集合。与微服务相比，目标非常不同。
我们正在使用ES，因为我们希望将域事件存储为真正的单一来源，微服务与否。这完全是关于域模型设计的。
了解有关ES，DDD，CQRS的更多信息，并为将来留下微服务。它们现在太过流行，很少有应用程序需要它们，很少有开发人员能够正确地使用它们。
答案 2 :(得分：3)
您正在将补偿模式描述为分布式事务的替代。在面向微服务的体系结构中，这是一种通过利用最终一致性来关注可用性的好方法：每个服务不是在服务之间进行集中协调的分布式事务，而是在没有事务上下文的情况下执行其子任务。如果出现问题，将向每个服务通知失败并对先前的操作执行某种（语义）补偿。因此，交易操作最终会被撤消。
正如您已经说过的，可以通过消息总线系统进行通信，并且不需要事件源或CQRS，补偿模式不依赖于这些原则。