简介

从核心原理和真实的上下文来看，基于微服务的应用程序天然是一个分布式系统，整个系统由多个较小的服务组成，并且这些服务一起提供了整体应用程序功能。尽管这种体系结构样式提供了许多好处，但是它也有一些局限性，微服务体系结构中的主要问题之一是如何处理跨多个服务的事务。

在本教程中，我们将探索Saga架构模式，该模式可让我们在微服务架构中管理分布式事务。

服务中的数据库

微服务架构的好处之一是，它使我们可以选择每种服务的技术堆栈。例如，我们可以决定对服务A使用关系数据库，对服务B选择NoSQL数据库。

该模型使服务可以在最适合的数据类型和架构，进行数据存储，独立管理自己服务的域数据。此外，它还允许服务按需扩展其数据存储，并将其与其他服务的故障隔离。

但是，有时事务可以跨多个服务，因此确保跨服务数据库的数据一致性是一个挑战，在下一节中，我们将通过一个示例来研究分布式事务管理的挑战。

分布式交易

为了演示分布式事务的使用，我们将以采用微服务架构实现的铁路座位预订系统为例。有一个微服务可以阻止座位，一个微服务接受付款，另一个微服务分配预订的座位。这些微服务中的每一个都执行本地事务以实现各个功能：

为了确保成功预订机票，所有三个微服务都必须完成单独的本地交易。如果任何微服务未能完成其本地事务，则所有已完成的先前事务都应回滚以确保数据完整性。这是分布式事务的示例，因为事务边界跨越了多个服务和数据库。

分布式交易的挑战

在上一节中，我们提供了一个分布式事务的真实示例，微服务架构中的分布式事务带来了两个关键挑战。

• 第一个是维护ACID。 为了确保事务的正确性，它必须是原子的，一致的，隔离的和持久的（ACID）。原子性确保事务的所有步骤或不应该完成。一致性将数据从一个有效状态转移到另一有效状态。隔离保证并发事务产生的结果应与顺序事务产生的结果相同。最后，持久性意味着无论任何类型的系统故障，已提交的事务都将保持已提交状态。在分布式事务场景中，由于事务跨多个服务，因此始终要确保ACID仍然是关键问题。
• 第二个是管理事务隔离级别。 它指定当其他服务同时访问相同数据时在事务中可见的数据量。换句话说，如果一个微服务中的一个对象保留在数据库中，而另一个请求读取该数据，则该服务应返回旧数据还是新数据？

了解两阶段提交

两阶段提交协议（2PC）是实现分布式事务的一种广泛使用的模式，我们可以在微服务架构中使用此模式来实现分布式事务。

在两阶段提交协议中，有一个协调器组件，负责控制事务并包含管理事务的逻辑，另一个组件是执行其本地事务的参与节点（例如，微服务）：

顾名思义，两阶段提交协议分两个阶段执行分布式事务：

• 准备阶段：协调器询问参与节点是否准备好提交事务。参与者返回的是或否
• 提交阶段：如果所有参与节点在阶段1中都做出了肯定的响应，则协调器会要求所有它们都进行提交。如果至少一个节点返回负值，则协调器会要求所有参与者回滚其本地交易

两阶段提交的问题

尽管2PC是实现分布式事务的一种有用方法，但它具有以下缺点：

事务的责任在协调器节点上，它可能成为单点失败，所有其他服务都需要等待，直到最慢的服务完成其确认。因此，事务的整体性能受最慢的服务约束

两阶段提交的协议在设计上由于依赖于协调器而变慢，因此，它可能会在涉及多个服务的基于微服务的体系结构中导致可伸缩性和性能问题。

NoSQL数据库不支持两阶段提交协议。因此，在一个或多个服务使用NoSQL数据库的微服务体系结构中，不能应用两阶段提交

Saga模式的引入

1、什么是Saga模式

Saga架构模式使用一系列本地事务来提供事务管理，本地交易是由Saga参与者执行的工作单元，Saga的每个操作都可以通过补偿事务回滚。此外，Saga模式可确保所有操作都成功完成，或者运行相应的补偿事务以撤消先前完成的工作。

在Saga模式中，补偿交易必须是幂等且可重试的。这两个原则确保无需任何人工干预就可以管理交易。Saga执行协调员（SEC）确保保证以下原则：

上图显示了如何可视化先前讨论的火车票预订场景的Saga模式。

2、Saga执行协调员

Saga执行协调器是实现一个Saga工作流的中心组件，它包含一个Saga日志，可捕获分布式事务的事件序列。对于任何失败，SEC组件都会检查Saga日志，以识别受影响的组件以及补偿事务应执行的顺序。

对于SEC组件中的任何故障，一旦备份，它都可以读取Saga日志。然后，它可以识别成功回滚的事务，哪些事务尚未完成，并可以采取适当的操作：

有两种实现Saga模式的方法：集中式协调（Choreography-based coordination）和分布式协调（Orchestration-based coordination）。让我们在下一部分中讨论它们。

=========================

3、集中式协调（Choreography-based coordination）

在Saga Choreography模式中，作为事务一部分的每个微服务都发布一个事件，该事件由下一个微服务处理。要使用此模式，需要确定微服务是否将成为Saga的一部分。因此，微服务需要使用适当的框架来实现Saga。在这种模式下，Saga执行协调器要么嵌入在微服务中，要么可以作为独立组件。

在Saga中，如果所有微服务都完成了本地事务，并且没有任何微服务报告失败，则编排流程将成功。下图演示了预订应用程序成功的Saga流程：

如果发生故障，微服务会向SEC报告故障，并且SEC的责任是调用相关的补偿交易：

在此示例中，“支付”微服务报告失败，并且SEC调用补偿交易以解除对座位的限制。如果对补偿事务的调用失败，则SEC有责任重试它，直到成功完成为止。回想一下，在Saga中，补偿交易必须是幂等且可重试的。

编排模式适用于未开发微服务应用程序开发。同样，当交易中的参与者较少时，此模式也适用。

以下是一些可用于实现编排模式的框架：

• Axon Saga：一个轻量级框架，广泛用于基于Spring Boot的微服务
• Eclipse MicroProfile LRA：在Saga中为基于REST原理的HTTP传输实现分布式事务
• Tram Saga：基于Spring Boot和Micronaut的微服务的Saga编排框架
• Seata：具有高性能和易于使用的分布式事务服务的开源分布式事务框架

4、分布式协调（Orchestration-based coordination）

在业务流程模式中，一个业务流程负责人管理总体交易状态。如果任何微服务遇到故障，那么协调器负责调用必要的补偿事务：

Saga编排模式对于Brownfield微服务应用程序开发体系结构很有用。换句话说，如果我们已经拥有一组微服务并且想要在应用程序中实现Saga模式，则此模式是合适的。我们需要定义适当的补偿交易以继续这种模式。

以下是一些可用于实现编排器模式的框架：

• Camunda：这是一个基于Java的框架，支持用于工作流和流程自动化的业务流程模型和表示法（BPMN）标准。
• Apache Camel：提供Saga企业集成模式（EIP）的实现

结论

在本文中，我们讨论了Saga架构模式以在基于微服务的应用程序中实现分布式事务。

我们介绍了在基于微服务的应用程序中实现分布式事务的挑战。然后，我们探索两阶段提交协议，这是Saga的流行替代方案，并研究了其在基于微服务的应用程序中实现分布式事务的局限性。

最后，我们讨论了Saga架构模式，如何工作以及在基于微服务的应用程序中实现Saga模式的两种主要方法。

2021-05-18 16:45 刘高飞