SAGA

旅程3：订单和注册限界上下文 CQRS之旅的第一站 “寓言家和鳄鱼是一样的，只是名字不同” --约翰·劳森 描述： 订单和注册上下文有一部分职责在会议预订的过程中，在此上下文中，一个人(注册者)可以购买特定会议的座位。还可以为已购买的座位分配与会者的名称(这在第5章“ 准备发布V1版本 ”中进行了描述)。 这是我们CQRS旅程的第一站，因此团队决定实现一个核心的、但自包含的系统部分——订单和注册。对与会者来说，注册过程必须尽可能地轻松。该流程必须确保业务客户能够预订到尽可能多的座位，并为他们提供灵活的，在会议上为不同类型的座位设置价格的功能。 因为这是团队处理的第一个限界上下文，所以我们还实现了系统的一些基础设施来支持领域域的功能。包括命令和事件消息总线以及聚合的持久化机制。 备注：本章描述的Contoso会议管理系统并不是该系统的最终版本。本此旅程描述的是一个过程，因此一些设计决策和实现细节在过程的后期会发生变化。这些变化将在后面的章节中描述。 在将来的某个旅程中，对这个限界上下文的改进计划包括支持等待列表(如果没有足够的座位可用，对座位的请求将放在等待列表中)，以及允许业务客户为座位类型设置各种类型的折扣。 备注：在这个版本中没有实现等待列表，但是社区成员正在开发这个特性和其他特性。任何带外发布和更新都将在“ CQRS之旅 ”网站上公布。 本章的工作术语定义：

Saga相关概念 你已经使用 database ber service 模式，每个service拥有自己的database。一些业务事务会跨越多个service，所以你需要来确保data consistency。应用程序不能简单的使用本地的ACID事务。 saga事务模型又被叫做长时间运行的事务(long running transaction)，一个长活事务可被分解成可以交错运行的子事务集合。其中每个子事务都是一个保证数据库一致性的真实事务。 对于分布式事务2PC(两阶段提交)不是一个好的选择, 把跨越多个service的每一个单独的事务实现成saga模式。一个saga是由local transaction组成的序列。每个local transaction更新本地数据库，然后发布一个message 或者event来触发下一个事务。如果有一个本地事务失败了，saga就会执行一系列的补偿事务来回滚之前的事务所做的修改。 举例 如：如电商下单，需要冻结商品库存，然后扣取用户的余额，最终完成订单。库存不足或账户余额不足都会导致下单失败，这里订单、库存、支付都是不同的模块service，都有自己的database 2PC的实现方式 2PC在JTA规范中实现如下 JTA控制器统一向3个服务发起prepare请求，如果3个请求都已确认，那3个服务都同时发起commit请求

前情提要： 通俗地说逻辑回归【Logistic regression】算法（一） 逻辑回归模型原理介绍 上一篇主要介绍了逻辑回归中，相对理论化的知识，这次主要是对上篇做一点点补充，以及介绍sklearn 逻辑回归模型的参数，以及具体的实战代码。 1.逻辑回归的二分类和多分类 上次介绍的逻辑回归的内容，基本都是基于二分类的。那么有没有办法让逻辑回归实现多分类呢？那肯定是有的，还不止一种。 实际上二元逻辑回归的模型和损失函数很容易推广到多元 逻辑回归。比如总是认为某种类型为正值，其余为0值。 举个例子，要分类为A，B，C三类，那么就可以把A当作正向数据，B和C当作负向数据来处理，这样就可以用二分类的方法解决多分类的问题，这种方法就是最常用的one-vs-rest，简称OvR。而且这种方法也可以方便得推广到其他二分类模型中（当然其他算法可能有更好的多分类办法）。 另一种多元逻辑回归的方法是Many-vs-Many(MvM)，它会选择一部分类别的样本和另一部分类别的样本来做逻辑回归二分类。 听起来很不可思议，但其实确实是能办到的。比如数据有A，B，C三个分类。 我们将A，B作为正向数据，C作为负向数据，训练出一个分模型。再将A，C作为正向数据，B作为负向数据，训练出一个分类模型。最后B，C作为正向数据，C作为负向数据，训练出一个模型。 通过这三个模型就能实现多分类，当然这里只是举个例子

【推荐阅读】微服务还能火多久？>>> 本文首发于 vivo互联网技术 微信公众号 链接： https://mp.weixin.qq.com/s/Z3uJhxJGDif3qN5OlE_woA 作者：wenbo zhang 【领域驱动设计实践之路】系列往期精彩文章： 《 领域驱动设计(DDD)实践之路(一) 》 主要讲述了战略层面的DDD原则。 这是“领域驱动设计实践之路”系列的第二篇文章，分析了如何应用事件来分离软件核心复杂度。探究CQRS为什么广泛应用于DDD项目中，以及如何落地实现CQRS框架。当然我们也要警惕一些失败的教训，利弊分析以后再去抉择正确的应对之道。 一、前言：从物流详情开始 大家对物流跟踪都不陌生，它详细记录了在什么时间发生了什么，并且数据作为重要凭证是不可变的。我理解其背后的价值有这么几个方面：业务方可以管控每个子过程、知道目前所处的环节；另一方面，当需要追溯时候仅仅通过每一步的记录就可以回放整个历史过程。 我在之前的文章中提出过“软件项目也是人类社会生产关系的范畴，只不过我们所创造的劳动成果看不见摸不着而已”。所以我们可以借鉴物流跟踪的思路来开发软件项目，把复杂过程拆解为一个个步骤、子过程、状态，这和我们事件划分是一致的，这就是事件驱动的典型案例。 二、领域事件 领域事件（Domain Events）是领域驱动设计（Domain Driven Design

3 月，跳不动了？>>> 近期，微服务解决方案Apache ServiceComb(incubating) 捷报频传，除了LC3大会ServiceComb Workshop成功举办之外，Java-Chassis 1.0.0-m2、Service-Center 1.0.0-m2和Saga 0.2.0版本顺利通过投票，完成发版。 版本变更概览 Java-Chassis 服务间通讯提供文件流传输能力，支持音乐、图片等多媒体场景。 在服务级别QPS控制基础上，新增支持API级别QPS控制 增加脚手架和start.servicecomb.io，支持用户快速构建工程，提供完整的开箱即用能力 新增支持使用Gradle构建 异步编程模型支持CompletableFuture和AsycRestTemplate 扩展Swagger支持类循环依赖，允许服务调用时的出入参数中存在类循环依赖场景 支持使用hibernate注解进行参数校验 新增支持Http2协议 实现错误注入接口，允许通过拦截服务请求构造异常场景 新增服务Dev运行模式，开启Dev模式时，支持契约动态修改 实现优雅停机，关闭服务时进行反注册，确保完成已接受请求并完整释放资源 Service-Center 支持获取Service-Center的服务和实例信息，在集群部署场景下，可动态发现Service Center实例

SOFA:Channel/ ，有趣实用的分布式架构频道。 本文根据 SOFAChannel#12 直播分享整理，主题：蚂蚁金服分布式事务实践解析。 回顾视频以及 PPT 查看地址见文末。欢迎加入直播互动钉钉群 : 30315793，不错过每场直播。 大家好，我是今天分享的讲师仁空，目前是蚂蚁金服分布式事务产品的研发。今天跟大家分享的是蚂蚁金服分布式事务实践解析，也就是分布式事务 Seata 在蚂蚁金服内部的实践。 今天我们将从以下 4 个主题进行详细介绍： 为什么会有分布式事务产品的需求； 理论界针对这个需求提出的一些理论和解决方案； 蚂蚁金服在工程上是如何解决这个问题的； 针对蚂蚁金服业务场景的性能优化； 分布式事务产生背景 首先是分布式事务产生的背景。 支付宝支付产品在 2003 年上线的时候，那时候的软件形态是单体应用，在一个应用内完成所有的业务逻辑操作。随着软件的工业化，场景越来越复杂，软件也越做越大，所有的业务在一个应用内去完成变的不可能，出现了软件模块化、服务化。 在从单体应用升级到分布式架构过程中，很自然得需要进行业务服务拆分，将原来糅在一个系统中的业务进行梳理，拆分出能独立成体系的各个子系统，例如交易系统、支付系统、账务系统等，这个过程就是服务化。业务服务拆分之后，原来一个服务就能完成的业务操作现在需要跨多个服务进行了。 另一个就是数据库拆分，分库分表

分布式事务模型 TCC 模型：TCC-Transaction、Hmily XA 模型：Sharding Sphere、MyCAT 2PC 模型：raincat、lcn MQ 模型：RocketMQ BED 模型：Sharding Sphere Saga 模型：ServiceComb Saga TCC TCC事务解决方案本质上是一种补偿的思路，它把事务运行过程分成try、confirm/cancel 两个阶段，每个阶段都由业务代码来控制。需要注意的是，TCC事务和2pc的思想类似，但与2pc实现不同，TCC不再是两阶段提交，而只是它对事务的提交/回滚是通过执行一段confirm/cancel业务逻辑来实现，并且也并没有全局事务来把控整个事务逻辑。 实现过程： try：完成所有业务检查（一致性），预留业务资源。 confirm：确认执行业务操作，只使用try阶段预留的业务资源。 cancel：取消try阶段预留的业务资源。 XA模型（规范） xa是个规范，根据这个思想衍生二阶段提交协议和三阶段提交协议。 XA分布式事务是由一个或者多个Resource Managerd，一个事务管理器Transaction Manager以及一个应用程序 Application Program组成。 资源管理器：提供访问事务资源的方法，通常一个数据库就是一个资源管理器。 事务管理器

随着业务的快速发展、业务复杂度越来越高，传统单体应用逐渐暴露出了一些问题，例如开发效率低、可维护性差、架构扩展性差、部署不灵活、健壮性差等等。而微服务架构是将单个服务拆分成一系列小服务，且这些小服务都拥有独立的进程，彼此独立，很好地解决了传统单体应用的上述问题，但是在微服务架构下如何保证事务的一致性呢？本文作者将为大家详细解答。 从本地事务到分布式事务的演变 什么是事务？回答这个问题之前，我们先来看一个经典的场景：支付宝等交易平台的转账。假设小明需要用支付宝给小红转账 100000 元，此时，小明帐号会少 100000 元，而小红帐号会多 100000 元。如果在转账过程中系统崩溃了，小明帐号少 100000 元，而小红帐号金额不变，就会出大问题，因此这个时候我们就需要使用事务了。 这里，体现了事务一个很重要的特性：原子性。事实上，事务有四个基本特性：原子性、一致性、隔离性、持久性。其中，原子性，即事务内的操作要么全部成功，要么全部失败，不会在中间的某个环节结束。一致性，即使数据库在一个事务执行之前和执行之后，数据库都必须处于一致性状态。如果事务执行失败，那么需要自动回滚到原始状态，换句话说，事务一旦提交，其他事务查看到的结果一致，事务一旦回滚，其他事务也只能看到回滚前的状态。隔离性，即在并发环境中，不同的事务同时修改相同的数据时，一个未完成事务不会影响另外一个未完成事务。持久性

原文地址： 梁桂钊的博客 博客地址： http://blog.720ui.com 欢迎关注公众号：「服务端思维」。一群同频者，一起成长，一起精进，打破认知的局限性。 从本地事务到分布式事务的演变 什么是事务？回答这个问题之前，我们先来看一个经典的场景：支付宝等交易平台的转账。假设小明需要用支付宝给小红转账 100000 元，此时，小明帐号会少 100000 元，而小红帐号会多 100000 元。如果在转账过程中系统崩溃了，小明帐号少 100000 元，而小红帐号金额不变，就会出大问题，因此这个时候我们就需要使用事务了。请参见图 6-1。 这里，体现了事务一个很重要的特性：原子性。事实上，事务有四个基本特性：原子性、一致性、隔离性、持久性。其中，原子性，即事务内的操作要么全部成功，要么全部失败，不会在中间的某个环节结束。一致性，即使数据库在一个事务执行之前和执行之后，数据库都必须处于一致性状态。如果事务执行失败，那么需要自动回滚到原始状态，换句话说，事务一旦提交，其他事务查看到的结果一致，事务一旦回滚，其他事务也只能看到回滚前的状态。隔离性，即在并发环境中，不同的事务同时修改相同的数据时，一个未完成事务不会影响另外一个未完成事务。持久性，即事务一旦提交，其修改的数据将永久保存到数据库中，其改变是永久性的。 本地事务通过 ACID 保证数据的强一致性。ACID是 Atomic（原子性）

SOFA:Channel/ ，有趣实用的分布式架构频道。 本文根据 SOFAChannel#10 直播分享整理，主题：分布式事务 Seata 长事务解决方案 Saga 模式详解。 回顾视频以及 PPT 查看地址见文末。欢迎加入直播互动钉钉群：23372465，不错过每场直播。 大家好，我是陈龙，花名: 屹远（ long187@github ），是蚂蚁金服分布式事务核心研发，也是 Seata Committer。今天分享的主题是《分布式事务 Seata 长事务解决方案 Saga 模式详解》，将从金融分布式应用开发的痛点出发，结合 Saga 分布式事务的理论和使用场景，讲解如何使用 Seata Saga 状态机来进行服务编排和分布式事务处理，构建更有弹性的金融应用，同时也会从架构、原理、设计、高可用、最佳实践等方面剖析 Saga 状态机的实现。 Seata： https://github.com/seata/seata 金融分布式应用开发的痛点 分布式系统有一个比较明显的问题就是，一个业务流程需要组合一组服务。这样的事情在微服务下就更为明显了，因为这需要业务上的一致性的保证。也就是说，如果一个步骤失败了，那么要么回滚到以前的服务调用，要么不断重试保证所有的步骤都成功。---《左耳听风-弹力设计之“补偿事务”》 而在金融领域微服务架构下的业务流程往往会更复杂，流程很长