Microservices 微服务体系结构与分布式事务

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

实际上没有对错问题。但这是我的观点

让我们把它分解一下：

微服务早就出现了，这种方法有优点也有缺点，但是你最终必须面对的一点是事务原子性，或者说没有事务原子性

确切地说，通常情况下，您应该避免使用分布式事务，这是一个重要的问题

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

通常情况下，您不会调用另一个微服务，否则它会变成

分布式整体

，所有所谓的

微服务

彼此依赖，就像它们在单个可执行文件中一样。当谈到

微服务时

，就是要让它们尽可能独立。这可以通过各种技术实现，例如

事件源

。您可以在其中定义事件和处理它们的微服务

当客户机在内部调用您的微服务api时，请使用以下方法：将一些数据放在自己的数据库中，创建发票文件，将其发送到另一个微服务，发送电子邮件，或者调用另一个对您的工作单元一无所知的系统

在

事件来源方面

这里您谈论的是

Saga

s。协调已完成工作的流程

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

正如前面所指出的，这是设计问题，让微服务形成分布式整体并不是真正的微服务

一般来说，

microservice

不仅仅是一个独立的可执行文件。这是设计实践。在你设计系统的时候，这样的问题不会发生。我建议阅读

DDD（域驱动设计）

，

事件源

，

CQRS

，

受限上下文

等方面的作者。这可能会让你更清楚。像马丁·福勒，格雷格·杨。我将尝试在这里添加名称，因为我会想到这一点。

其中有一个模式称为“Saga”，它涵盖了您描述的分布式业务事务的问题

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

一般来说，有两种方法来协调传奇故事：

编舞

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

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

编曲

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

---

工作流引擎是在一个业务事务中协调不同服务的好方法。另请参阅如何使用BPMN 2.0对saga模式进行建模的说明。上述调用流只是一个简单的例子，从microservice调用其他API是同步处理的标准方式。要求是对我的微服务的调用必须立即返回执行结果，所以在将信息返回给客户端之前，我必须确保一切都以成功结束，包括解决与其他API通信中的错误，这些错误大部分无法根据我的需要更改。这就是重点。如果你想确保一切都结束了，那么你的

微服务如何确保一切都结束了呢。Microservice负责某些
受限上下文
，用于单一类型的任务。否则，如果它知道
一切
，它似乎就不是微服务。它是
分布式巨石
或
传奇
，选择一个。
microservices
的要点是以确定边界和负责的microservices的方式划分您的体系结构，然后您需要协调它们，或者设计面向前面的API accor