微服务架构和分布式事务

Question

微服务架构和分布式事务

3

微服务已经存在一段时间了，这种方法有其优点和缺点，但你最终将不得不面对的一个问题是交易的原子性或者说没有原子性。企业应用程序通常在api层面上具有某种工作单位，但在你的微服务调用另一个微服务（或api）并且它不知道分布式事务的情况下，会出现一些问题，当发生故障时需要处理：假设您有微服务“为项目付款”。当客户调用您的微服务api时，该方法内部：在自己的数据库中放置一些数据，创建发票文件，将其发送到另一个微服务，发送电子邮件，可能调用另一个不知道你的工作单位的系统。如果该序列的每个部分都成功了，那么一切都很好，但问题是如何处理错误，你正在调用的另一个api不可用，但你已经在许多其他系统中更改了状态，该怎么办？有没有一种好的方法来应对这种情况？

- Macko

2个回答

0

在微服务架构中，有一种称为“Saga”的模式，它解决了你所描述的分布式业务事务问题。 Saga模式描述了一系列由不同服务覆盖的本地事务。每个事务都封装在一个服务中。如果一个本地事务因违反业务规则而失败，那么Saga将执行一系列补偿事务，撤销之前本地事务所做的更改。

通常有两种协调saga的方式：编排在Saga模式的编排风格中，每个本地事务发布领域事件，触发其他服务中的本地事务。这可以通过服务调用或发送事件来实现。这通常是解决问题的自然方法。这种方法的缺点在于服务之间的耦合度增加，因为通常需要从外部域管理事件。

如果业务事务非常简短，编排可能是一个很好的解决方案。 管弦乐

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

工作流引擎是协调一个业务交易中的不同服务的好方法。还可以查看如何使用BPMN 2.0模型来描述saga模式here。

- Ralph

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- muradm · Accepted Answer

其实并没有对错之分。以下是我的看法。微服务已经存在一段时间了，这种方法有利也有弊，但你最终会面临的一个重要问题是事务的原子性或者说没有原子性。通常情况下，你应该避免使用分布式事务。企业应用程序通常在 API 级别上有某种工作单元，但在微服务调用另一个微服务（或 API）的环境中，你通常不会这样做。否则，这将变成“分布式单体”，即所谓的“微服务”相互依赖，就像它们位于单个可执行文件中一样。当谈到“微服务”时，关键是尽可能使它们独立。这可以通过各种技术实现，例如“事件溯源”，其中定义了事件和处理它们的微服务。

当客户端调用您的微服务API时，这个方法内部会：在所拥有的数据库中放置一些数据，创建发票文件，将其发送到另一个微服务，发送电子邮件，也许调用另一个不知道您的工作单元的系统。

在“事件溯源”的术语中，这里谈论的是“Saga”——协调完成的工作的过程。

但是您已经在许多其他系统中更改了状态，如何从那里恢复？这是设计问题，正如之前所指出的，微服务形成“分布式单体”实际上并不是微服务。总的来说，“微服务”不仅仅是一个独立的可执行文件，它是一种设计实践。你要以某种方式设计你的系统，使得这种问题不会发生。我建议阅读关于“DDD（领域驱动设计）”、“事件溯源”、“CQRS”、“有界上下文”等作者的文章。这可能会让事情更加清晰。像 Martin Fowler，Greg Young 这样的名字也可以试着添加到我的列表中。