微服务架构和分布式事务

Question

微服务是前一段时间出现的，这种方法有利有弊，但您最终必须面对的问题之一是事务原子性，或者说没有它。企业应用程序通常在 api 级别上具有某种工作单元，但是在您的微服务正在调用另一个微服务（或 api）并且它不了解分布式事务的环境中，当出现问题时，它会引发一些您必须处理的问题：假设你有微服务“为项目付款”。当客户端在内部调用您的微服务 api 时：将一些数据放入拥有的数据库中，创建发票文件，将其发送到另一个微服务，发送电子邮件，也许调用另一个对您的工作单元一无所知的系统。如果这个序列的每个部分都成功了，一切都很好，但问题是如何处理错误，你正在调用的另一个 api 不可用，但是你在许多其他系统中改变了状态，如何从那里恢复？这种情况有什么好的方法吗？

Answer 1

实际上没有正确或错误的问题。但这是我的观点。

让我们分解一下：

微服务是前段时间出现的，这种方法有利有弊，但您最终必须面对的一个问题是事务原子性，或者说没有它

确切地说，通常情况下，您要避免分布式事务，这是重点之一。

企业应用程序通常在 api 级别具有某种工作单元，但在您的微服务正在调用另一个微服务（或 api）的环境中

通常，您不会调用另一个微服务，否则它会变成distributed monolith，其中所有所谓的microservices 相互依赖，就好像它们在单个可执行文件中一样。谈到microservices，就是要让它们尽可能独立。这可以通过各种技术来实现，例如Event Sourcing 就是其中之一。您在哪里定义事件和处理它们的微服务。

当客户在内部调用您的微服务 api 时：将一些数据放入自己的数据库中，创建发票文件，将其发送到另一个微服务，发送电子邮件，也许调用另一个对您的工作单元一无所知的系统。

就Event Sourcing 而言，这里指的是Sagas。协调已完成工作的流程。

但是您在许多其他系统中已经改变了状态，如何从那里恢复

如前所述，这是设计问题，形成distributed monolith 的微服务实际上并不是微服务。

一般来说，microservice 不仅仅是一个单独的可执行文件。这是设计实践。如果您以这种方式设计系统，则不会发生此类问题。我建议阅读DDD (Domain Driven Design)、Event Sourcing、CQRS、Bounded Context 等上的作者。这可能会让你更清楚。就像马丁·福勒、格雷格·杨一样。会尝试在此处添加名称，我会想到它。

Answer 2

在Microservice Architecture 中有一个名为“Saga”的模式，它涵盖了您描述的分布式业务事务的问题。

Saga pattern 描述了由不同服务覆盖的一系列本地事务。每个事务都封装在一个服务中。如果本地事务由于违反业务规则而失败，则 saga 会执行一系列补偿事务，以撤消先前本地事务所做的更改。

一般有两种方式来协调sagas：

编舞

在 Saga 模式的编排风格中，每个本地事务都会发布域事件，这些事件会触发其他服务中的本地事务。这可以通过服务调用或发送事件来完成。这通常是解决问题的自然方法。这种方法的缺点在于服务的耦合度增加，因为通常必须从外部域管理事件。

如果业务交易非常短，编排可能是一个很好的解决方案。

编排

使用编排风格实现 Saga 模式是一种不同的方法，其中编排器告诉参与者要执行哪些本地事务。协调器也称为 Saga 协调器。这是放置业务逻辑的地方。 Saga Coordinator 基于声明性业务逻辑调用服务，并在出现异常时处理补偿。

工作流引擎是一种在一个业务事务中编排不同服务的好方法。另请参阅描述如何使用 BPMN 2.0 对 saga 模式进行建模 here