微服务之saga模式

标签: | 发表时间:2021-10-16 21:54 | 作者:
出处:https://blog.csdn.net

背景

你已经使用 database ber service 模式。每个service拥有自己的database。一些业务事务会跨越多个service,所以你需要来确保data consistency。例如,假设你正在构建一个电子商务网站,这个网站的用户的会有一个最大欠款限制,应用程序必须确保一个新订单不能超过用户的最大前款限制,但是orders表和customers表不在同一个数据库,所以应用程序不能简单的使用本地的ACID事务。

难题

怎么确保跨越多个service的数据一致性

驱动力

2pc(两阶段提交)不是一个好的选择

解决方案

把跨越多个service的每一个单独的事务实现成saga模式。一个saga是由local transaction组成的序列。每个local transaction更新本地数据库,然后发布一个message 或者event来触发下一个事务。如果有一个本地事务失败了,saga就会执行一系列的补偿事务来回滚之前的事务所做的修改。

saga模式有如下两种协作方式。

Choreography(编排)--每个本地事务发布domain  event来触发别的service的local transaction.

Orchestration --有一个orchestrator 对象来告诉参与者执行哪一个事务。

Example: Choreography-based saga

一个电子商务网站使用choreography-based saga 来创建一个order。

  1. order service创建一个处于pending 状态的order,然后发布一个 ordercreated event
  2. customer service接受到ordercreated  event ,然后为订单冻结金额。然后customer service 发布一个creait reserved event 或者creait limit exceeded event(如果账户的金额不够的话)
  3. order service接受到creait reserved event或者creait limit exceeded event,然后将订单状态修改为 approved 或者cancelled

Example: Orchestration-based saga 

这是一个使用Orchestration-based saga 模式来创建一张order的例子

  1. order service 创建一个order,设置order为pending 状态,然后在创建一个create order saga对象
  2. create order saga对象发送一个reserve credit reserved命令到customer service
  3. customer service尝试来为这张order 预留金额,然后返回一个应答
  4. createordersaga接受customer service返回的应答,然后返回一个ApprovedOrder或者RejectedOrder命令给order service
  5. order service将订单状态改成approved或者rejected

结果 

saga模式有如下好处

  • 不适用分布式事务来确保微服务的数据一致性

saga模式的缺点

  • 编程模型太复杂。例如,开发人员必须设计能够回滚的补偿事务 

需要解决的问题

  • 为了确保可靠性,一个service必须atomically 的更新数据库,然后发布一个message/event。不能够使用传统的分布式事务机制来横跨database和message broker。

相关 [微服务 saga 模式] 推荐:

微服务之saga模式

- -
你已经使用 database ber service 模式. 每个service拥有自己的database. 一些业务事务会跨越多个service,所以你需要来确保data consistency. 例如,假设你正在构建一个电子商务网站,这个网站的用户的会有一个最大欠款限制,应用程序必须确保一个新订单不能超过用户的最大前款限制,但是orders表和customers表不在同一个数据库,所以应用程序不能简单的使用本地的ACID事务.

微服务数据一致性的演进:SAGA,CQRS,Event Sourcing的由来和局限-InfoQ

- -
讲微服务数据一致性的文章,网上比较多. 此前 EAWorld 与发过几篇,包括《 微服务架构下的数据一致性保证(一)》、《 微服务架构下的数据一致性保证(二)》、《 微服务架构下的数据一致性保证(三):补偿模式》,以及《 使用消息系统进行微服务间通讯时,如何保证数据一致性》. 本篇文章在我看来,是从一个纵向的维度把相关的一致性概念的演进过程,讲的比较清晰,简单的逻辑是这样的:.

微服务性能模式

- - 互联网 - ITeye博客
前言:基于微服务系统越来越普遍. 下面我们就来看看五种常见的特定微服务性能的挑战,以及如何应解他们. 背景:在IT界微服务架构为基础的系统越来越多, 每一个应用系统都集成了不同的组件和服务,几乎所有的特定业务应用程序都需要集成一个或更多的应用服务. 但是一个综合性系统集成不同的服务这无疑是一个巨大的挑战.

微服务的反模式和陷阱

- - 鸟窝
前几天我写了篇读书笔记: 《产品级微服务的八大原则》,介绍了Uber的SRE工程师 Susan J. Fowler 的免费书: Microservices in Production,文中提出了一个微服务成功与否的唯一标准就是可用性,非常有实践意义. 但是这本书偏向于从 SRE (site reliability engineer)的视角看待微服务,对于开发工程师 (SWE, software engineer)来说,更关注的是如何正确地从单体程序重构到微服务架构,或者从头设计微服务架构, 这篇读书笔记主要就是介绍这方面的实践和经验.

微服务的十个反模式和陷阱

- - 后端技术杂谈 | 飒然Hang
O’Reilly的电子书《Microservices AntiPatterns and Pitfalls》讲述了在微服务设计实现时十种最常见的反模式和陷阱. 书籍地址: https://www.oreilly.com/programming/free/microservices-antipatterns-and-pitfalls.csp,更全的反模式和陷阱可见作者的视频: http://oreil.ly/29GVuDG.

微服务分布式一致性模式 – ThoughtWorks洞见

- -
微服务拆分后遇到的一个麻烦是分布后的一致性问题. 单体架构的业务处理和数据都在一个进程里面,一致性保障很成熟,开发人员基本上不用关心. 当把业务系统拆分到不同进程时,就遇到了技术性一致性问题. 这带来了纠结,我们希望有一颗银弹,一把解决问题. 但由于分布式一致性在(CAP)理论上没有完美的解决方案,我们所能选择的方案是在特定业务场景下的选择.

[ 翻译 ] 微服务架构及设计模式

- -
本文介绍了主流常见的微服务模式. 因此,了解如何处理微服务架构(MSA)以及一些微服务设计模式,一个微服务架构的一些通用目标或者设计原则是很有价值的. 下面是在微服务架构方案中值得考虑的四个目标[1]. 1、缩减成本:MSA将会降低设计、实现和维护IT服务的总体成本. 2、加快发布速度:MSA将会加快服务从想法到部署的落地速度.

从单体迁移到微服务的几种模式

- -
正确实现的微服务较单体应用有很多优势. 许多组织都希望将他们的单体应用程序代码换成微服务代码. 但事实证明,迁移到微服务并非易事. 你应该问的第一个问题是,你真的需要微服务吗. 单体存在的许多问题都可以使用模块化的单体架构轻松解决. 一旦你确定自己真的需要微服务,就必须制定一套将单体应用转换为微服务的计划.

微服务架构设计模式 - XuMinzhe - 博客园

- -
单体地狱的银弹-微服务架构. 大型的复杂应用程序可以持续交付和持续部署. 每个服务都相对较小并容易维护. 分布式系统带来的各种复杂性. 开发者需要思考到底应该在应用的什么阶段使用微服务架构. 随着网络基础设施的高速发展,以及越来越多的个体接入互联网,在考虑构建支持海量请求以及多变业务的软件平台时,微服务架构成为多数人的首选.

微服务架构及设计模式 - DockOne.io

- -
【编者的话】本文作者详细介绍了微服务架构里一些常见的设计模式和它们各自的使用场景. 因此,了解如何处理微服务架构(MSA)以及一些微服务设计模式,一个微服务架构的一些通用目标或者设计原则是很有价值的. 下面是在微服务架构方案中值得考虑的四个目标. 缩减成本:MSA 将会降低设计、实现和维护IT服务的总体成本.