随着微服务架构的流行，应用程序越来越多地采用微服务方法。这种方法涉及将整个业务流分解为可以独立缩放和部署的单个微服务。

微服务架构提供了许多好处，但它也提出了独特的挑战。分布式系统要解决的关键问题之一是处理跨越多个服务的交易，也称为分布式交易。

实施回滚机制是处理此类故障的基本方法。基于微服务的应用程序为每个业务流提供不同的服务。如果应用程序在特定服务中失败，则应将所有先前完成的服务卷回去，以使应用程序正确运行。这样可以确保应用程序保持可靠和连贯，从而最大程度地减少了失败的影响。

您需要一个强大而可靠的平台，例如Orkes导体，以确保您的应用程序具有完美的回滚机制。 Orkes导体建于经过战斗测试的Netflix导体上，是一个现代的应用程序构建平台，有助于构建分布式应用程序的速度10倍。

在这篇博客文章中，我们将探讨Orkes导体如何促进用于处理分布式应用程序中故障的回滚机制的设置。

分布式交易 - 解释

与整体应用不同，所有组件通常共享一个数据库，设计了微服务体系结构，以便每个服务都具有单个数据库。因此，开发人员拥有最高的权力，可以选择技术而不是不同的数据库。

例如，一个服务可以使用PostgreSQL，而另一个服务使用MySQL。在微服务体系结构中，此方法称为“ 数据库”。

在数据库中，每个服务都负责其自己的数据库，并执行顺序操作以完成应用程序的整个交易。在分布式系统上发生的整个交易称为分布式事务。

有不同的方法来处理数据库交易，例如本地酸和2pc。

酸交易

酸（原子能，一致性，隔离，耐用性）交易可确保每项交易符合酸性。

• Anomicity 确保所有交易已执行，或者没有执行。
• 一致性确保交易应从一个状态到另一种状态保持一致。
• 隔离确保单个交易不应互相干扰。
• 耐用性确保一旦交易实施，即使在任何系统失败的情况下，也应该持续存在。

在涉及多个数据库的分布式交易中，由于几个原因，交易的传统酸性可能不是理想的拟合：

• Polyglot持久性 - 由于微服务架构包含与单个数据库的不同服务，因此将它们与不同的交易功能集成在一起可以创建瓶颈场景，并且可能并不总是可行的。
• 最终一致性 - 这是一种策略，可以使用异步通信来确保数据一致性。它确保如果在特定过程中发生错误，则最终将解决错误，而无需完整的整个过程回滚。

另一种广泛用于分布式交易的模式是2PC协议。

两相提交（2PC）协议

2pc是一种协议，其中交易以2个不同阶段完成，即准备相位和提交阶段。

要理解这个概念，让我们以电子商务应用程序为例：

现在让我们看看微服务之间的交易是如何在2PC协议中进行的：

在 准备阶段 中，有一个中央协调员和参与节点。参与的节点不过是微服务。在此阶段，协调员检查微服务是否准备就绪。微服务可以用是/否。

响应

如果所有微服务都同意提交，则交易进入下一阶段， commit阶段 。在此阶段，通知所有微服务以提交交易，如果其中任何一个失败，协调员将向所有先前完成的微服务发出回滚命令。

但是，2pc有几个缺点，例如所有服务都应等到最慢的服务完成交易，这可能会导致应用程序部署时间进一步增加。

那么，我们如何在分布式应用程序中实施交易以克服所有这些挑战？

那是传奇图案出现的地方。

传奇图案

传奇模式introduced in 1987 by Hector Garcia Molina & Kenneth Salem将传奇模式定义为一系列交易序列，可以相互交织。在这种模式下，协调员确保所有个人交易都成功完成，并且在失败的情况下，对所有先前完成的交易进行补偿交易。因此，可以使用补偿事务将每笔交易都回滚。

让我们查看电子商务应用程序示例：

为了保持应用程序的一致状态，传奇模式包括 saga执行控制器（SEC），该>由捕获分布式应用程序中事件序列的日志组成。 /p>

SEC组件在识别事件序列中的失败并执行必要的回滚事务中起着至关重要的作用。与其他模式相比，传奇模式的优点是，SEC组件中的故障不会影响应用程序的功能。从失败中恢复后，SEC组件可以查询传奇日志以识别发生的回滚交易并采取相应行动。

可以根据 编排 或 编排 方法来实现传奇模式。编舞模式有许多陷阱，更适合具有少量微服务的场景。另一方面，传奇编排模式可确保单个协调员负责管理整体交易状态。

在此示例中，如果付款失败，则集中式协调员确保进行薪酬交易以撤销付款，更新库存和取消订单。这样，应用程序是一致的，没有任何情况，例如付款失败，但仍下达订单。

因此，很明显，传奇模式是解决分布交易中面临的挑战的解决方案。

使用Orkes导体实施补偿模式

对于应用程序的平稳运行，必须实现补偿机制。 Orkes导体使用编排模式实现补偿机制。

您可以使用导体中的failureWorkflow功能来实现此目标。这些应用程序是作为导体中的工作流程构建的。在创建工作流定义时，您可以指定失败工作流，如果主要工作流量失败，该工作流将被触发。失败工作流将接收失败的工作流的ID和任务作为输入，使您能够实现补偿逻辑来处理失败。

一个例子看起来像这样：

在这里，如果工作流程 rollback_example 失败，则将触发失败工作流程 rollback_workflow 。

您可以从UI看到故障工作流已触发。这是恢复更改的补偿工作流程。

在我们讨论的电子商务应用程序示例中，我们可以将每个服务称为单个sub-workflows，每个子工作流可以具有相应的失败工作流程。

包起来

必须在分布式应用程序中无缝管理中的无缝管理中起着不可或缺的作用。这些框架对于解决不可预见的情况和从失败中恢复，保证申请的完整性和可靠性至关重要。

您是否考虑过探索Orkes Conductor-一种用于构建分布式应用程序的有力解决方案，以及管理补偿模式的能力？快来设置meeting with Conductor Experts now！

如果您想免费尝试指挥，请查看Orkes Playground。

如果您有任何疑问或需要帮助，请随时加入我们充满活力的Slack community。