事件溯源是构建业务逻辑和持久化聚合的另一种选择，它将聚合以一系列的方式持久化保存，每个事件代表聚合的一次状态变化。应用通过重放事件来重新创建聚合的当前状态。
微服务架构，独享数据库、事件驱动、CQRS、Saga、BFF、API 网关、Strangler、断路器、外部化配置、消费端驱动的契约测试
从软件开发早期（1960 年代）开始，应对大型软件系统中的复杂性一直是一项令人生畏的任务。多年来为了应对软件系统的复杂性，软件工程师和架构师们做了许多尝试：David Parnas 的模块化和封装 （1972）， Edsger W. Dijkstra （1974）的关注点分离以及 SOA（1988）。
而如果后端有缓存的关系（cookie或者服务端保存会话，是保存在内存中，而不是数据库），就不能适用水平扩展或者不能只简单地水平扩展，所以这个水平扩展更新用单机服务的扩展。
作者 | Gunnar Morling 译者 | 张卫滨 核心要点 Saga 能够实现长时间运行的、分布式的业务事务，这样的事务会跨多个微服务执行一组操作，实现一致的全有或全无的语义。 为了实现解耦，微服务之间的通信最好按照异步的方式来进行，比如借助 Apache Kafka 使用分布式的提交日志。 发件箱模式为服务作者提供了一种解决方案，能够让他们在本地数据库执行写入，同时通过 Apache Kafka 发送消息，避免依赖不安全的“双重写入（dual writes）”。 Debezium 是一个分布式
众所周知，Node.js中的JavaScript代码执行在单线程中，非常脆弱，一旦出现了未捕获的异常，那么整个应用就会崩溃。
自从软件开发的早期(1960年代)以来，解决大型软件系统中的复杂性一直是一项艰巨的任务。多年来，软件工程师和架构师为解决软件系统的复杂性进行了许多尝试：David Parnas的模块化和信息隐藏(1972)，Edsger W. Dijkstra的关注分离(1974)，面向服务的体系结构(1998)。
数据一致性是构建业务系统需要考虑的重要问题 ， 以往我们是依靠数据库来保证数据的一致性。但是在微服务架构以及分布式环境下实现数据一致性是一个很有挑战的的问题。ServiceComb作为开源的微服务框架致力解决微服务开发过程中的问题。我们最近发起的ServiceComb-Saga项目来解决分布式环境下的数据最终一致性问题。本文将向大家介绍为什么数据一致性如此重要？Saga又是什么？
经常会有A.getb().getc().d()的方法调用，有没有什么方法将调用链变短比呢，联想到操作系统是通过消息触发一系列操作，我们也可以模仿这一操作，用事件的方式调用方法，当然也有弊端会让事件到处跑，不知道有哪些方法被调用了，我在写代码的时候就喜欢事件的方式（不过聚合根还是设计的简单一些，不要嵌套太深，从根源上避免这种太深的设计）
目前业界公认 Saga 是作为长事务的解决方案。而seata作为目前最流行的分布式事物解决方案也提供了Saga的支持。而采用Seata的Saga模式进行事物控制，核心就是通过状态机来进行控制，本文重点介绍Seata Saga状态机设计器的使用实战。
saga是分布式事务领域里一个非常重要的事务模式，特别适合解决出行订票这类的长事务，本文将深度剖析saga事务的设计原理，以及在解决订票问题上的最佳实践
ServiceComb是华为云PaaS部门在2017年开源的微服务开发框架，它提供了Java和Go语言的微服务开发框架、微服务注册中心，还提供了基于Sagas的数据一致性实现的ServiceComb Saga。
applyMiddleware 是一个辅助函数，为 redux 的 dispatch 函数添加了功能。
如果redux需要用到 side effect 异步操作,redux-thunk 和 redux-saga 绝对是目前两个最受欢迎的中间件插件。
微服务架构（MSA）已经变得非常流行。但是，一个常见问题是如何跨多个微服务管理分布式事务。当微服务架构将单体系统分解为自封装服务时，意味着单体系统中的本地事务现在分布到将按顺序调用的多个服务中。
在分析Seata的saga模式实现时，实在是被其复杂的 json 状态语言定义文件劝退，我是有点没想明白为啥要用这么来实现状态机；盲猜可能是基于可视化的状态机设计器来定制化流程，更方便快捷且上手快吧，毕竟可以通过UI直接操作，设计状态流转图，但我暂时不太能get到。对于Saga模式的实现，之前的博文中已经阐述了基于状态机模式实现Saga，是比较常见且合适的做法，因此了解了下Java中的状态机实现方案，以后有相关的业务场景也可以直接上手使用状态机。
上一篇文章我们分析了Redux-Thunk的源码，可以看到他的代码非常简单，只是让dispatch可以处理函数类型的action，其作者也承认对于复杂场景，Redux-Thunk并不适用，还推荐了Redux-Saga来处理复杂副作用。本文要讲的就是Redux-Saga，这个也是我在实际工作中使用最多的Redux异步解决方案。Redux-Saga比Redux-Thunk复杂得多，而且他整个异步流程都使用Generator来处理，Generator也是我们这篇文章的前置知识，如果你对Generator还不熟悉，可以看看这篇文章。
该文章讲述了如何使用 Redux 和 Redux Saga 管理应用程序的状态和行为。通过使用 Redux，可以轻松地将状态存储在全局变量中，并在组件之间轻松共享数据。Redux Saga 是一种异步处理程序，可以处理异步操作，例如网络请求，从而提高应用程序的性能。
使用 dispatch 往 store 发送 action 的这个过程是可以被拦截的, 自然而然地就可以在这里增加各种中间件Middleware。redux-saga是redux的中间件，主要负责从action派发到更新store中间具有副作用行为的处理。
微服务架构下的事务往往需要横跨多个服务，每个服务都有属于自己的私有数据库。传统的分布式事务管理并不是合适选择，需要使用Saga机制。
最近的工作主要是微服务框架的设计与开发，期间要解决多个微服务的分布式事务问题，由于要解决的主要场景是用spring boot写的java项目，最终选择了业界成熟的servicecomb-saga方案，这里稍微记录下以备忘。
本文地址 我们知道redux-saga 也是通过中间件的形式与 redux 本身连接起来。例如下面使用了redux-saga的react项目需要以下这样的 初始化
作为一个Redux中间件，想让Redux应用中的副作用（即依赖/影响外部环境的不纯的部分）处理起来更优雅
因为Generator。结合yield yield操作符会获取右边表达示的值返回 可以用于异步变同步操作 中间件的特性: 以前的 action -> reducers -> store 现在的 action -> middleware -> reducers -> store
我先介绍一下我自己，我叫姜宁，来自于华为开源研究中心，现在负责的是ServiceComb这个开源项目。ServiceComb这个项目已经进到Apache孵化，应该是去年11月份时进到Apache孵化的，这个月我们帮刚发了1.0M1版，但对于SAGA来说我们属于探索的阶段，发布了0.1.0。
译自：Distributed transaction patterns for microservices compared
在前面文章《分布式事务》中介绍了几种分布式事务，其中Saga介绍了相关的概念，接下来介绍Saga使用案例，案例来源《微服务架构设计模式》。
实际上，这个术语出自康奈尔大学的一篇论文：http://www.cs.cornell.edu/andru/cs711/2002fa/reading/sagas.pdf
Saga事务模型又叫做长时间运行的事务（Long-running-transaction）, 它是由普林斯顿大学的H.Garcia-Molina等人提出，它描述的是另外一种在没有两阶段提交的的情况下解决分布式系统中复杂的业务事务问题。
今年 4 月，Meta 发布「分割一切（SAM）」AI 模型，这项成果不仅成为很多 CV 研究者心中的年度论文，更是在 ICCV 2023 上斩获最佳论文提名 。
saga这个名词通常被用在CQRS的讨论中，它是指一段在限定上下文（bounded contexts ）和聚合（aggregates）之间起协作和路由（coordinates and routes ）消息作用的代码。然而，在这个指南中我们更喜欢用Process manager这个词语去表示saga。有两个原因： 之前已经有了一个广泛被熟知的名词saga，这个saga和CQRS中的saga有着不同的含义。 process manager 是一个更合适用来描述saga在这里扮演角色的名词。 虽然saga经常在C
Saga模式使用一系列本地事务来提供事务管理，而一个本地事务对应一个Saga参与者，在Saga流程里面每一个本地事务只操作本地数据库，然后通过消息或事件来触发下一个本地事务，如果其中一个本地事务失败了，Saga就会执行一系列补偿事务来实现回滚操作。（补偿事务简单来讲就是对之前本地事务做的修改导致不一致的情况执行反向操作来消除掉不一致的状态）。
https://mp.weixin.qq.com/s/n6bI335w7mJFoBeR2aJqVw
React的作用View层次的前端框架，自然少不了很多中间件（Redux Middleware）做数据处理, 而redux-saga就是其中之一，目前这个中间件在网上的资料还是比较少，估计应用的不是很广泛，但是如果使用得当，将会事半功倍的效果，下面仔细介绍一个这个中间件的具体使用流程和应用场景。
redux官方中文文档：https://www.redux.org.cn/docs/introduction/CoreConcepts.html
最强大的事务类型之一称为两阶段提交，当第一个事务的提交取决于第二个事务的完成时，它是摘要。特别是当您必须同时更新多个实体时，例如确认订单和立即更新库存时，它非常有用。
TodoApp中使用了ES6的“...”语法，由于webpack无法识别，只能借助 babel 的 transform-object-rest-spread 插件完成语法降级转换；
随着微服务架构的兴起，越来越多的公司会在实际场景中遇到分布式事务的问题。特别是在金融应用场景，几个跨进程的应用共同完成一个任务，就更离不开分布式事务的参与。而对于分布式事务而言，2PC、TCC也是经常被提到了，不过在面对长业务流程，并且很难进行TCC改造的场景，会选择使用Saga分布式事务。今天会给大家介绍Saga实现分布式事务的内容：
越是用来解决具体问题的技术，使用起来越容易，越高效，学习成本越低；越是用来解决宽泛问题的技术，使用起来越难，学习成本越高。
这就是分布式事物问题,当APP要买东西,这个操作会涉及到多个服务,意味着要操作多个数据库,这样本地事物就无法保证数据的一致性,所以就产生了分布式事物问题.
Workflow Core 中，用于构建工作流的类继承 IWorkflow，代表一条有任务规则的工作流，可以表示工作流任务的开始或者 Do() 方法，或工作流分支获取其它方法。
因此我们首先得学习Redux，中文官网地址：http://cn.redux.js.org/
Seata 意为：Simple Extensible Autonomous Transaction Architecture，是一套一站式分布式事务解决方案，提供了 AT、TCC、Saga 和 XA 事务模式，本文详解其中的 Saga 模式。
Saga 最初出现在1987年Hector Garcaa-Molrna & Kenneth Salem发表的一篇名为《Sagas》的论文里。其核心思想是将长事务拆分为多个短事务，借助Saga事务协调器的协调，来保证要么所有操作都成功完成，要么运行相应的补偿事务以撤消先前完成的工作，从而维护多个服务之间的数据一致性。举例而言，假设有个在线购物网站，其后端服务划分为订单服务、支付服务和库存服务。那么一次下订单的Saga流程如下图所示：
QGIS是一个开放源码的地理信息系统。该项目诞生于2002年5月，并于同年6月作为SourceForge上的一个项目建立。我们一直在努力使GIS软件(传统上是昂贵的专有软件)成为任何人都可以使用个人电脑的可行前景。QGIS目前运行在大多数Unix平台、Windows和macOS上。QGIS是使用Qt工具包和c++开发的。这意味着QGIS有一个清爽、易于使用的图形用户界面(GUI)。
学习Seata分布式事务看这一篇就够了 一、事务的特性 二、本地事务与分布式事务 三、分布式事务理论依据 3.1、CAP定律 3.2、BASE理论 四、Seata简介 4.1、Seata是什么 4.2、官网地址 4.3、Seata基本架构 4.4、分布式事务解决方案 4.4.1、Seata-AT模式 4.4.2、Seata-XA模式 4.4.2.1、XA模式 什么是XA协议 Seata的事务模式 4.4.2.2、Seata的XA模式 为什么要在Seata中支持XA XA的价值 4.4.2.3、项目中应用XA模式 4.4.2.4、XA模式如何切换 4.4.3、Seata-TCC事务模式 4.4.3.1、什么是TCC 4.4.3.2、Seata的TCC模式 4.4.4、Seata-Saga事务模式 4.4.4.1、基本概念 4.4.4.2、为什么需要Saga 4.4.4.3、Saga状态机 4.4.4.4、Saga状态机设计器 4.5、四种模式的对比 五、部署Seata TC服务 5.1、下载seata-server 5.2、解压修改配置 5.3、初始化数据库配置 5.4、Nacos配置中心添加配置 5.5、测试启动TC服务 六、项目集成Seata 6.1、业务背景 6.2、数据表创建 6.3、搭建基本服务 6.3.1、代码基本结构 6.3.2、pom.xml引入依赖 6.3.3、配置文件application.yml 6.3.4、创建订单接口 6.3.5、声明Feign接口 6.3.6、测试验证 6.4、使用Seata全局事务注解@GlobalTransactional 6.5、配置数据源代理 6.6、启动服务测试
dva 首先是一个基于redux[1]和redux-saga[2]的数据流方案，然后为了简化开发体验，dva 还额外内置了react-router[3]和fetch[4]，所以也可以理解为一个轻量级的应用框架。
在微服务架构盛行的情况下，在分布式的多个服务中保证业务的一致性，即分布式事务就显得尤为重要。本文将讲述分布式事务及其解决方案，有XA协议、TCC和Saga事务模型、本地消息表、事务消息和阿里开源的Seata。
大家好！我们再次聚焦在分布式事务问题上。在上一篇文章中，我们详细探讨了两阶段提交（2PC）方案。然而，两阶段提交也有其局限性，比如需要一个非常可靠的协调者，以及协调者崩溃时可能会造成系统阻塞。那么，有没有其他的方案可以处理这个问题呢？答案是有的，那就是补偿事务，也被称为Saga模式。今天，我们就一起来了解一下这个方案。
领取专属 10元无门槛券
手把手带您无忧上云
