微服务是在一段时间前出现的，这种方法有其优点和缺点，但是您最终必须面对的问题之一是事务原子性，或者甚至没有它。企业应用程序通常在api级别上具有某种工作单元，但是在您的微服务正在调用另一个微服务（或api）并且不了解分布式事务的环境中，当出现问题时，您将不得不处理一些问题：假设您有微服务“为商品付款”。当客户端内部调用您的微服务api时，该方法：将一些数据放入拥有的数据库中，创建发票文件，将其发送到另一个微服务，发送电子邮件，或者调用另一个对您的工作单位一无所知的系统。如果此序列的每个部分都成功，但问题是如何处理错误，则您正在调用的另一个api不可用，但是您在许多其他系统中的状态已更改，如何从那里恢复？这种情况有什么好的办法吗？
答案 0 :(得分：2)
实际上没有对与错的问题。但这是我的观点。
让我们分解一下：
微服务在很早以前就已经存在，这种方法有其优点和缺点，但是您最终将要面对的问题之一是事务的原子性，或者甚至是没有原子性。
实际上，通常，您要避免进行分布式事务，这是重要的一点之一。
企业应用程序通常在api级别具有某种工作单元，但是在您的微服务正在调用另一个微服务（或api）的环境中
通常，您不会调用另一个微服务，否则它将变成distributed monolith，在这里所有您所谓的microservices彼此依赖，就好像它们在单个可执行文件中一样。在谈论microservices时，将使它们尽可能独立。这可以通过各种技术来实现，例如，其中一种是Event Sourcing。您在哪里定义事件并处理它们的微服务。
当客户端在内部调用您的微服务api时，该方法：将一些数据放入拥有的数据库中，创建发票文件，将其发送到另一个微服务，发送电子邮件，或者调用另一个对您的工作单位一无所知的系统。
在Event Sourcing方面，您谈论的是Saga。安排完成的工作的过程。
但是您已经在许多其他系统中更改了状态，如何从那里恢复
如前所述，这是设计问题，使微服务形成distributed monolith实际上不是微服务。
通常，microservice不仅仅是一个独立的可执行文件。这是设计实践。在以这种方式设计系统的地方，不会发生此类问题。我建议阅读DDD (Domain Driven Design)，Event Sourcing，CQRS，Bounded Context等上的作者。这可能会使您更清楚。就像马丁·福勒（Martin Fowler），格雷格·杨（Greg Young）。我会想到这里会尝试添加名称。
答案 1 :(得分：0)
在Microservice Architecture中，有一个名为“ Saga”的模式，该模式涵盖了您描述的分布式业务交易的问题。
Saga pattern描述了由不同服务覆盖的一系列本地交易。每个事务都封装在服务中。如果本地事务因为违反业务规则而失败，那么该传奇将执行一系列补偿事务，以撤消先前的本地事务所做的更改。
通常，有两种协调Sagas的方法：
编舞
以Saga模式的编排样式，每个本地事务都会发布触发其他服务中本地事务的域事件。这可以通过服务调用或发送事件来完成。通常，这是解决问题的自然方法。这种方法的缺点在于服务之间的耦合不断增加，因为通常必须从外部域来管理事件。
如果业务交易非常短，那么编排可能是一个很好的解决方案。
编排
使用编排样式实施Saga模式是一种不同的方法，编排者告诉参与者要执行哪些本地事务。协调器也称为Saga协调器。这是放置业务逻辑的地方。 Saga协调员根据声明性业务逻辑调用服务，并在发生异常情况时也处理补偿。
工作流引擎是一种在一项业务交易中协调不同服务的好方法。另请参见有关如何使用BPMN 2.0来对传奇模式here
进行建模的描述。