使用Spring Boot介绍Saga模式

28c3e41e95e960c01ac18d7ab742f018.png

微服务是由许多较小的服务组成的分布式系统,它们共同提供整体应用功能。尽管这种架构风格具有许多优点,但也存在一些缺点。其中最大的问题之一是如何管理涉及多个服务的事务。

在分布式事务场景中,尽管事务涉及多个服务,但始终要保持ACID(原子性、一致性、隔离性和持久性)的特性。第二个困难是控制事务的隔离级别,它决定了在其他服务同时访问相同数据时,事务中可见的数据量。

两阶段提交协议(2PC)

2PC是一种常用的实现分布式事务的方法。它包括一个协调器组件负责控制事务并包含事务逻辑,以及其他参与节点执行其本地事务。

2PC协议的阶段如下:

b63fd3de3dbe0b83081959eab9cf5c4a.png

1.第一阶段:协调器询问参与节点是否准备好提交事务,并等待它们的是或否响应。如果在第一阶段所有节点都回答是,协调器指示所有节点提交事务;否则,协调器指示所有节点回滚事务。

以上是使用Spring Boot介绍Saga模式和2PC协议的基本内容。Saga模式可以帮助解决涉及多个服务的复杂分布式事务场景,并提供可靠的事务管理机制。请注意,实现Saga模式需要一些复杂的编程和设计技巧,因此在开始之前请确保你对Spring Boot和分布式事务有一定的了解。

2PC协议的缺点[1]:

•协调器负责所有服务,可能导致单点故障。•由于协调器决定所有服务何时完成,操作的整体性能受到最慢服务的限制。•NoSQL数据库不支持2PC。

Saga架构模式

Saga架构模式通过一系列的本地事务来管理事务。在成功完成前一个阶段后,Saga模式会触发下一步操作。

每个Saga参与者的工作由本地事务表示。Saga中的每个操作都可以通过补偿事务进行撤销。补偿事务必须是可逆且幂等的。

Saga执行协调器

Saga执行协调器是将Saga流程实施的关键组件。它包括一个Saga日志,记录分布式事务中事件的顺序。

在发生故障时,协调器通过检查Saga日志来确定受影响的组件以及执行补偿事务的顺序。

如果协调器组件发生故障,它可以在重新启动时读取Saga日志。然后,它可以确定哪些事务已成功回滚,哪些事务仍在等待,并采取适当的操作。

Saga模式可以通过编排和协同两种方式实现。

Saga编排模式

微服务由编排器或指挥者控制。这允许对Saga或工作流进行集中控制。编排器或指挥者可以对所有Saga或工作流进行集中控制,也可以作为每个Saga或工作流的单独服务进行分布式。这为每个微服务提供了不同程度的独立性。

8c79ec9f2db262a272b023de8c93b7d4.png
0*i03oqc0jR9JmVGks.png

Saga编排模式的优点[2]:

•集中处理分散的事务。•设置和测试简单。•简化回滚管理。•随着添加新步骤,比编舞技术的流程变得不那么复杂。•有能力管理未决的事务。

Saga编排模式的缺点[2]:

•当您管理额外的Saga编排器服务时,基础架构的复杂性增加。

Saga编舞模式

微服务独立工作,但通过信号或事件协调彼此。Saga或工作流的控制方式由预定义的一组信号或事件确定。

0916b87a491fe899d52373dbc69c542f.png

Saga编舞模式的优点[2]:

•它对于理解和安装到现有系统来说非常简单,因为触发事件的服务彼此不同。•如果您的过程有两到四个步骤,它可能非常有用。

Saga编舞模式的缺点[2]:

•但是,随着流程变得更加复杂,跟踪哪个服务正在监听哪些事件可能变得更加复杂。•因为服务必须相互订阅,可能会出现循环依赖。•测试很困难,因为为了彻底测试系统,所有服务必须运行。

Axon Saga框架可以用于实现Saga模式。Axon Saga框架是基于Spring Boot的轻量级Saga模式框架。

如何决定使用哪种Saga模式?

系统复杂性:编排模式适用于具有复杂业务逻辑的系统,其中控制流必须集中控制以保持一致性和符合业务需求。而编舞模式更适用于具有简单业务逻辑的系统,其中服务可以独立工作,并通过基于事件的通信进行交互。

协调要求:当需要服务之间紧密协调和交互时,编排模式有益,因为协调器可以处理通信,并确保每个服务在进入下一步之前完成其任务。而编舞设计更适用于松散连接的系统,其中每个服务可以独立工作,并根据需要与其他服务进行通信。

容错性和可伸缩性:由于中央编排器可以处理错误和重试,并改善系统流程,因此编排模式可以具有更好的容错性和可伸缩性。而编舞模式则可以更具适应性和灵活性来应对变化,因为每个服务可以对事件作出反应并更新其行为,而无需依赖中央组件。

集中化与分散化的权衡:编排模式集中了控制和决策,简化了系统的开发和管理,但引入了单点故障和潜在的瓶颈。而编舞模式则分散了权力和决策,可以增加服务的自治性和灵活性,但也使系统变得更加复杂和难以操作。

在Spring Boot中实现基于编舞的Saga模式

事件溯源

应用程序状态的每次更改都记录为事件。此事件保存在数据库/事件存储中(用于跟踪目的),同时也在事件总线上广播,以供其他参与方消费。

“order-service”接收到创建新订单的命令。当创建订单时,此请求将被执行并作为事件引发。订单创建事件(过去式,因为已经发生)只是通知“order-service”已收到新订单请求,并且该

请求正在等待处理/已创建状态并且尚未完成。

付款/库存服务现在可能有兴趣监听这些事件并保留/拒绝付款/库存。即使这些也可能被视为事件。付款已保留/拒绝的事件和订单服务可以监听这些事件并完成/取消初始购买请求。

4cf0615ee8088fb0d12b29319d4e7362.png
0*ouwU6txzMEqSU-i2.png

在Spring Boot中实现基于编排的Saga模式

编排器是一个独立的服务,将协调所有微服务之间的事务。如果一切正常,将将“order-request”标记为完成;否则,将其标记为取消。为了使其无状态,编排器和其他服务之间的通信将通过基本的非阻塞异步方式进行,可以使用Kafka主题进行此通信。为此,我们必须使用分散/聚集模式,这更像是一种有状态的方式。


  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

小技术君

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值