微服务架构与分布式事务

Question

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

Answer 1

这个问题其实没有对错之分。但这是我的观点。

让我们分解一下:

microservices are present some time ago, there are pros and cons of this approach but one of the points u will eventually have to face with is transaction atomicity or rather not having it

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

Enterprise apps usually have some kind of Unit Of Work on api level but in environment where your microservice is calling another microservice (or api)

通常，您不会调用另一个微服务，否则它会变成分布式单体，所有所谓的微服务都相互依赖，就好像它们在单个可执行文件。在谈论微服务时，就是要让它们尽可能独立。这可以通过多种技术实现，例如，Event Sourcing 就是其中之一。您定义事件和处理它们的微服务的位置。

When client calls your microservice api this method internally: place some data in owned database, create invoice file, sends it to another microservice, send email, maybe call another system which knows nothing about your unit of work.

在 Event Sourcing 方面，您在这里谈论的是 Saga。协调已完成工作的流程。

but your have changed state in many other systems, how to recover from there

这是设计问题，如前所述，让微服务形成分布式单体实际上并不是微服务。

一般来说，微服务不仅仅是一个分离的可执行文件。这是设计实践。在您以这种方式设计系统的地方，不会发生此类问题。我建议阅读有关 DDD(领域驱动设计)、Event Sourcing、CQRS、Bounded Context 等方面的作者。这可能会让你更清楚。像马丁福勒，格雷格杨。我会尝试在此处添加名称。