day05-服务保护和分布式事务

YangeIT大约 35 分钟

day05-服务保护和分布式事务

课程背景

在微服务远程调用的过程中，还存在几个问题需要解决。

业务健壮性问题
级联失败问题
跨服务的事务问题

首先是业务健壮性问题：

例如在之前的查询购物车列表业务中，购物车服务需要查询最新的商品信息，与购物车数据做对比，提醒用户。大家设想一下，如果商品服务查询时发生故障，查询购物车列表在调用商品服务时，是不是也会异常？从而导致购物车查询失败。但从业务角度来说，为了提升用户体验，即便是商品查询失败，购物车列表也应该正确展示出来，哪怕是不包含最新的商品信息。

还有级联失败问题：

还是查询购物车的业务，假如商品服务业务并发较高，占用过多 Tomcat 连接。可能会导致商品服务的所有接口响应时间增加，延迟变高，甚至是长时间阻塞直至查询失败。

此时查询购物车业务需要查询并等待商品查询结果，从而导致查询购物车列表业务的响应时间也变长，甚至也阻塞直至无法访问。而此时如果查询购物车的请求较多，可能导致购物车服务的 Tomcat 连接占用较多，所有接口的响应时间都会增加，整个服务性能很差，甚至不可用。

依次类推，整个微服务群中与购物车服务、商品服务等有调用关系的服务可能都会出现问题，最终导致整个集群不可用。

这就是级联失败问题，或者叫雪崩问题。

还有跨服务的事务问题：

1.比如昨天讲到过的下单业务，下单的过程中需要调用多个微服务：

商品服务：扣减库存
订单服务：保存订单
购物车服务：清理购物车

2.又如用户购买商品的业务逻辑。整个业务逻辑由3个微服务提供支持：

这些业务全部都是数据库的写操作，我们必须确保所有操作的同时成功或失败。但是这些操作在不同微服务，也就是不同的 Tomcat，这样的情况如何确保事务特性呢？

上述问题都会在今天找到答案。🎯

今天的内容会分成几部分：

微服务保护
- 服务保护方案
- 请求限流
- 隔离和熔断
分布式事务
- 初识分布式事务
- Seata

通过今天的学习，你将能掌握下面的能力：

知道雪崩问题产生原因及常见解决方案
能使用 Sentinel 实现服务保护
理解分布式事务产生的原因
能使用 Seata 解决分布式事务问题
理解 AT 模式基本原理

1.微服务保护

1.1.服务保护方案

前言

保证服务运行的健壮性，避免级联失败导致的雪崩问题，就属于微服务保护。

这章我们就一起来学习一下微服务保护的常见方案以及对应的技术。🎯

微服务保护的方案有很多，比如：

请求限流
线程隔离
服务熔断

这些方案或多或少都会导致服务的体验上略有下降，比如:

请求限流，降低了并发上限；
线程隔离，降低了可用资源数量；
服务熔断，降低了服务的完整度，部分服务变的不可用或弱可用。

因此这些方案都属于服务降级的方案。但通过这些方案，服务的健壮性得到了提升👍

接下来，我们就逐一了解这些方案的原理。

解决方案：

1.1请求限流

服务故障最重要原因，就是并发太高！

解决了这个问题，就能避免大部分故障。当然，接口的并发不是一直很高，而是突发的。因此请求限流，就是限制或控制接口访问的并发流量，避免服务因流量激增而出现故障。

请求限流往往会有一个限流器，数量高低起伏的并发请求曲线，经过限流器就变的非常平稳。这就像是水电站的大坝，起到蓄水的作用，可以通过开关控制水流出的大小，让下游水流始终维持在一个平稳的量。

1.2.线程隔离

当一个业务接口响应时间长，而且并发高时，就可能耗尽服务器的线程资源，导致服务内的其它接口受到影响。

所以我们必须把这种影响降低，或者缩减影响的范围。线程隔离正是解决这个问题的好办法。

线程隔离的思想来自轮船的舱壁模式：

轮船的船舱会被隔板分割为 N 个相互隔离的密闭舱，
假如轮船触礁进水，只有损坏的部分密闭舱会进水，
而其他舱由于相互隔离，并不会进水。
这样就把进水控制在部分船体，避免了整个船舱进水而沉没。

为了避免某个接口故障或压力过大导致整个服务不可用，我们可以限定每个接口可以使用的资源范围，也就是将其“隔离”起来。

如图所示，我们给查询购物车业务限定可用线程数量上限为 4，这样即便查询购物车的请求因为查询商品服务而出现故障，也不会导致服务器的线程资源被耗尽，不会影响到其它接口。

1.3.服务熔断

线程隔离虽然避免了雪崩问题，但故障服务（商品服务）依然会拖慢购物车服务（服务调用方）的接口响应速度。而且商品查询的故障依然会导致查询购物车功能出现故障，购物车业务 也变的不可用了。

所以，我们要做两件事情：

编写服务降级逻辑：就是服务调用失败后的处理逻辑，根据业务场景，可以抛出异常，也可以返回友好提示或默认数据。
异常统计和熔断：统计服务提供方的异常比例，当比例过高表明该接口会影响到其它服务，应该拒绝调用该接口，而是直接走降级逻辑。

服务保护技术:

hystrix 豪猪
Sentinel 哨兵 [ˈsentɪnl]

总结

课堂作业

提升服务的健壮性有哪几种常见方案？各有什么特点？🎤

1.2.Sentinel

Sentinel简介和安装

Sentinel 是阿里巴巴开源的一款服务保护框架，目前已经加入 SpringCloudAlibaba 中。

官方网站：https://sentinelguard.io/zh-cn/open in new window

Sentinel 的使用可以分为两个部分:

核心库（Jar 包）：不依赖任何框架/库，能够运行于 Java 8 及以上的版本的运行时环境，同时对 Dubbo / Spring Cloud 等框架也有较好的支持。在项目中引入依赖即可实现服务限流、隔离、熔断等功能。
控制台（Dashboard）：Dashboard 主要负责管理推送规则、监控、管理机器信息等。

为了方便监控微服务，我们先把 Sentinel 的控制台搭建出来。

1）下载 jar 包

下载地址：

也可以直接使用课前资料提供的版本：

2）运行

将 jar 包放在任意非中文、不包含特殊字符的目录下，重命名为 sentinel-dashboard.jar：

然后运行如下命令启动控制台：

java -Dserver.port=8090 -Dcsp.sentinel.dashboard.server=localhost:8090 -Dproject.name=sentinel-dashboard -jar sentinel-dashboard.jar

其它启动时可配置参数可参考官方文档：https://sentinelguard.io/zh-cn/docs/dashboard.htmlopen in new window

3）访问

访问 http://localhost:8090open in new window 页面，就可以看到 sentinel 的控制台了：

需要输入账号和密码，默认都是：sentinel

登录后，即可看到控制台，默认会监控 sentinel-dashboard 服务本身：

微服务连上哨兵sentinel操作 🎯

基本步骤

我们在 cart-service 模块中整合 sentinel，连接 sentinel-dashboard 控制台，步骤如下：

引入 sentinel 依赖
在配置文件中配置哨兵地址
访问 cart-service 的任意接口，模拟用户发情求，观察哨兵客户端

1）引入 sentinel 依赖

<!--sentinel-->
<dependency>
    <groupId>com.alibaba.cloud</groupId> 
    <artifactId>spring-cloud-starter-alibaba-sentinel</artifactId>
</dependency>

2）配置控制台

修改 application.yaml 文件，添加下面内容：

spring: # 顶格写
  cloud: 
    sentinel:
      transport:
        dashboard: localhost:8090

3）访问 cart-service 的任意端点

重启 cart-service，然后访问查询购物车接口，sentinel 的客户端就会将服务访问的信息提交到 sentinel-dashboard 控制台。并展示出统计信息：

点击簇点链路菜单，会看到下面的页面：

所谓簇点链路，就是单机调用链路，是一次请求进入服务后经过的每一个被 Sentinel 监控的资源。默认情况下，Sentinel 会监控 SpringMVC 的每一个 Endpoint（接口）。

因此，我们看到 /carts 这个接口路径就是其中一个簇点，我们可以对其进行限流、熔断、隔离等保护措施。

不过，需要注意的是，我们的 SpringMVC 接口是按照 Restful 风格设计，因此购物车的查询、删除、修改等接口全部都是 /carts 路径：

默认情况下 Sentinel 会把路径作为簇点资源的名称，无法区分路径相同但请求方式不同的接口，查询、删除、修改等都被识别为一个簇点资源，这显然是不合适的。

所以我们可以选择打开 Sentinel 的请求方式前缀，把 请求方式 + 请求路径 作为簇点资源名：

1. 首先，在 cart-service 的 application.yml 中添加下面的配置：

spring:
  cloud:
    sentinel:
      transport:
        dashboard: localhost:8090
      http-method-specify: true # 开启请求方式前缀

2. 然后，重启服务，通过页面访问购物车的相关接口，可以看到 sentinel 控制台的簇点链路发生了变化：

总结

课堂作业

sentinel是什么？能解决什么问题？是哪家公司开发的？默认端口是多少？🎤
什么是簇点链路？🎤
sentinel 控制台中能看到什么信息？对于项目运营有什么指导作用？🎤

1.3.请求限流

请求限流

服务故障最重要原因，就是并发太高！解决了这个问题，就能避免大部分故障。

当然，接口的并发不是一直很高，而是突发的。因此请求限流，就是限制或控制接口访问的并发流量，避免服务因流量激增而出现故障。

请求限流往往会有一个限流器，数量高低起伏的并发请求曲线，经过限流器就变的非常平稳。这就像是水电站的大坝，起到蓄水的作用，可以通过开关控制水流出的大小，让下游水流始终维持在一个平稳的量。

Sentinel请求限流配置操作

基本验证步骤

在Sentinel中给查看购物车设置限流,QPS=6：每秒 6 个
利用Jemeter 做限流测试，我们每秒发出 10 个请求，观察Sentinel管理端中的负载曲线

在簇点链路后面点击流控按钮，即可对其做限流配置：

在弹出的菜单中这样填写：

这样就把查询购物车列表这个簇点资源的流量限制在了每秒 5 个，也就是最大 QPS 为 5 .

我们利用 Jemeter 做限流测试，我们每秒发出 10 个请求：

点击查看Jemeter启动和配置open in new window👈

模拟向http://localhost:8082/carts发送请求open in new window

最终监控结果如下：

可以看出 GET:/carts 这个接口的通过 QPS 稳定在 5-6附近，而拒绝的 QPS 在激增附近，符合我们的预期。

建议调小一点线程数，如10个，避免配置保守的电脑死机

总结

课堂作业

Sentinel请求限流主要限制什么？ QPS是什么意思？🎤

1.4.线程隔离

线程隔离

当一个业务接口响应时间长，而且并发高时，就可能耗尽服务器的线程资源，导致服务内的其它接口受到影响。所以我们必须把这种影响降低，或者缩减影响的范围。线程隔离正是解决这个问题的好办法。

线程隔离的思想来自轮船的舱壁模式：

轮船的船舱会被隔板分割为 N 个相互隔离的密闭舱，假如轮船触礁进水，只有损坏的部分密闭舱会进水，而其他舱由于相互隔离，并不会进水。这样就把进水控制在部分船体，避免了整个船舱进水而沉没。

为了避免某个接口故障或压力过大导致整个服务不可用，我们可以限定每个接口可以使用的资源范围，也就是将其隔离起来。

限流可以降低服务器压力，尽量减少因并发流量引起的服务故障的概率，但并不能完全避免服务故障。一旦某个服务出现故障，我们必须隔离对这个服务的调用，避免发生雪崩。

比如，查询购物车的时候需要查询商品，为了避免因商品服务出现故障导致购物车服务级联失败，我们可以把购物车业务中查询商品的部分隔离起来，限制可用的线程资源：

这样，即便商品服务出现故障，最多导致查询购物车业务故障，并且可用的线程资源也被限定在一定范围，不会导致整个购物车服务崩溃。

所以，我们要对查询商品的 FeignClient 接口做线程隔离。🎯

Sentinel实现线程隔离操作：

基本步骤

OpenFeign 整合 Sentinel
配置线程隔离

1.1.OpenFeign 整合 Sentinel

修改 cart-service 模块的 application.yml 文件，开启 Feign 的 sentinel 功能：

feign:
  sentinel:
    enabled: true # 开启feign对sentinel的支持

然后重启 cart-service 服务，可以看到查询商品的 FeignClient 自动变成了一个簇点资源：

接下来，给下级链路设置线程隔离 🎯

购物车接口文档：http://localhost:8082/doc.htmlopen in new window

1.2.配置线程隔离

接下来，点击查询商品的 FeignClient 对应的簇点资源后面的流控按钮：

在弹出的表单中填写下面内容：

注意，这里勾选的是并发线程数限制，也就是说这个查询功能最多使用 5 个线程，而不是 5QPS。如果查询商品的接口每秒处理 2 个请求，则 5 个线程的实际 QPS 在 10 左右，而超出的请求自然会被拒绝。

在商品服务的根据id批量查询商品方法中，模拟查询耗时500ms

我们利用 Jemeter 测试，每秒发送 100 个请求：

最终测试结果如下：

进入查询购物车的请求每秒大概在 100，而在查询商品时却只剩下每秒 10 左右，符合我们的预期。

此时如果我们通过页面访问购物车的其它接口，例如添加购物车、修改购物车商品数量，发现不受影响：

响应时间非常短，这就证明线程隔离起到了作用，尽管查询购物车这个接口并发很高，但是它能使用的线程资源被限制了，因此不会影响到其它接口。

🎉恭喜你🎉，掌握了sentinel进行线程隔离，避免发生雪崩

限流可以降低服务器压力，尽量减少因并发流量引起的服务故障的概率，但并不能完全避免服务故障。一旦某个服务出现故障，我们必须隔离对这个服务的调用，避免发生雪崩。

总结

课堂作业

什么是.线程隔离，有何作用？🎤
Sentinel实现线程隔离，需要怎么做？🎤

1.5.服务熔断

服务熔断

在上一节，我们利用线程隔离对查询购物车业务进行隔离，保护了购物车服务的其它接口。由于查询商品的功能耗时较高（我们模拟了 500 毫秒延时），再加上线程隔离限定了线程数为 5，导致接口吞吐能力有限，最终 QPS 只有 10 左右。

这就导致了几个问题：

第一，超出的 QPS 上限的请求就只能抛出异常，从而导致购物车的查询失败。但从业务角度来说，即便没有查询到最新的商品信息，购物车也应该展示给用户，用户体验更好。也就是给查询失败设置一个降级处理逻辑。

第二，由于查询商品的延迟较高（模拟的 500ms），从而导致查询购物车的响应时间也变的很长。这样不仅拖慢了购物车服务，消耗了购物车服务的更多资源，而且用户体验也很差。对于商品服务这种不太健康的接口，我们应该直接停止调用，直接走降级逻辑，避免影响到当前服务。也就是将商品查询接口熔断。

Sentinel实现熔断操作

1.编写降级逻辑

触发限流或熔断后的请求不一定要直接报错，也可以返回一些默认数据或者友好提示，用户体验会更好。

给 FeignClient 编写失败后的降级逻辑有两种方式：

方式一：FallbackClass，无法对远程调用的异常做处理
方式二：FallbackFactory，可以对远程调用的异常做处理实用

这里我们演示方式二的失败降级处理。

步骤一：在 hm-api 模块中给 ItemClient 定义降级处理类ItemClientFallback，实现 FallbackFactory接口：

代码如下：

package com.hmall.api.client.fallback;
@Slf4j
public class ItemClientFallback implements FallbackFactory<ItemClient> {
    @Override
    public ItemClient create(Throwable cause) {
        return new ItemClient() {
            @Override
            public List<ItemDTO> queryItemByIds(Collection<Long> ids) {
                log.error("远程调用ItemClient#queryItemByIds方法出现异常，参数：{}", ids, cause);
                // 查询购物车允许失败，查询失败，返回空集合
                return CollUtils.emptyList();
            }

            @Override
            public void deductStock(List<OrderDetailDTO> items) {
                // 库存扣减业务需要触发事务回滚，查询失败，抛出异常
                throw new BizIllegalException(cause);
            }
        };
    }
}

步骤二：在 hm-api 模块中的 com.hmall.api.config.DefaultFeignConfig 类中将 ItemClientFallback 注册为一个 Bean：

步骤三：在 hm-api 模块中的 ItemClient 接口中使用 ItemClientFallbackFactory：

重启后，再次测试，发现被限流的请求不再报错，走了降级逻辑，但是未被限流的请求延时依然很高：

点击查看重启步骤图解open in new window

导致最终的平局响应时间较长。

2.服务熔断

查询商品的 RT 较高（模拟的 500ms），从而导致查询购物车的 RT 也变的很长。这样不仅拖慢了购物车服务，消耗了购物车服务的更多资源，而且用户体验也很差。

对于商品服务这种不太健康的接口，我们应该停止调用，直接走降级逻辑，避免影响到当前服务。也就是将商品查询接口熔断。当商品服务接口恢复正常后，再允许调用。这其实就是断路器的工作模式了。

Sentinel 中的断路器不仅可以统计某个接口的慢请求比例，还可以统计异常请求比例。当这些比例超出阈值时，就会熔断该接口，即拦截访问该接口的一切请求，降级处理；当该接口恢复正常时，再放行对于该接口的请求。

断路器的工作状态切换有一个状态机来控制：

状态机是有限状态自动机的简称，是现实事物运行规则抽象而成的一个数学模型. 状态机的四大概念： State状态、Event事件、 Action动作、Transition变换。点击查看例子open in new window

状态机包括三个状态：

closed：关闭状态，断路器放行所有请求，并开始统计异常比例、慢请求比例。超过阈值则切换到 open 状态
open：打开状态，服务调用被熔断，访问被熔断服务的请求会被拒绝，快速失败，直接走降级逻辑。Open 状态持续一段时间后会进入 half-open 状态
half-open：半开状态，放行一次请求，根据执行结果来判断接下来的操作。
- 请求成功：则切换到 closed 状态
- 请求失败：则切换到 open 状态

我们可以在控制台通过点击簇点后的熔断按钮来配置熔断策略：

在弹出的表格中这样填写：

这种是按照慢调用比例来做熔断，上述配置的含义是：

RT 超过 200 毫秒的请求调用就是慢调用
统计最近 1000ms 内的最少 5 次请求，如果慢调用比例不低于 0.5，则触发熔断
熔断持续时长 20s

配置完成后，再次利用 Jemeter 测试，可以发现：

在一开始一段时间是允许访问的，后来触发熔断后，查询商品服务的接口通过 QPS 直接为 0，所有请求都被熔断了。而查询购物车的本身并没有受到影响。

总结

课堂作业

为什么要服务熔断，有什么好处？🎤
Sentinel实现熔断大概的思路是怎么样的？🎤
状态机是什么？🎤

2.分布式事务

分布式事务

首先我们看看项目中的下单业务整体流程：

由于订单、购物车、商品分别在三个不同的微服务，而每个微服务都有自己独立的数据库，因此下单过程中就会跨多个数据库完成业务。而每个微服务都会执行自己的本地事务：

交易服务：下单事务
购物车服务：清理购物车事务
库存服务：扣减库存事务

整个业务中，各个本地事务是有关联的。因此每个微服务的本地事务，也可以称为分支事务。多个有关联的分支事务一起就组成了全局事务。我们必须保证整个全局事务同时成功或失败。

我们知道每一个分支事务就是传统的单体事务，都可以满足 ACID 特性，但全局事务跨越多个服务、多个数据库，是否还能满足呢？

我们来做一个测试，先进入购物车页面：

目前有 4 个购物车，然结算下单，进入订单结算页面：

然后将购物车中某个商品的库存修改为 0：

然后，提交订单，最终因库存不足导致下单失败：

然后我们去查看购物车列表，发现购物车数据依然被清空了，并未回滚：

事务并未遵循 ACID 的原则，归其原因就是参与事务的多个子业务在不同的微服务，跨越了不同的数据库。虽然每个单独的业务都能在本地遵循 ACID，但是它们互相之间没有感知，不知道有人失败了，无法保证最终结果的统一，也就无法遵循 ACID 的事务特性了。

这就是分布式事务问题，出现以下情况之一就可能产生分布式事务问题：

业务跨多个服务实现
业务跨多个数据源实现

接下来这一章我们就一起来研究下如何解决分布式事务问题。🎯

如果出现下面的错误，很可能是Long精度丢失问题

解决方式：将下面的代码粘贴到项目中(可以放到公共类，但是需要加载配置报包名)

@Configuration
@ConditionalOnClass(ObjectMapper.class)
public class JsonConfig {
    @Bean
    public Jackson2ObjectMapperBuilderCustomizer jackson2ObjectMapperBuilderCustomizer() {
        return jacksonObjectMapperBuilder -> {
            // long -> string
            jacksonObjectMapperBuilder.serializerByType(Long.class, ToStringSerializer.instance);
            jacksonObjectMapperBuilder.serializerByType(BigInteger.class, ToStringSerializer.instance);
        };
    }
}

总结

课堂作业

什么是事务，有哪些特征？🎤
哪些业务场景会出现分布式事务问题？🎤

2.1.认识 Seata

Seata

Seata 是一款开源的分布式事务解决方案，致力于提供高性能和简单易用的分布式事务服务。Seata 将为用户提供了 AT、TCC、SAGA 和 XA 事务模式，为用户打造一站式的分布式解决方案。

解决分布式事务的方案有很多，但实现起来都比较复杂，因此我们一般会使用开源的框架来解决分布式事务问题。在众多的开源分布式事务框架中，功能最完善、使用最多的就是阿里巴巴在 2019 年开源的 Seata 了。

官网：https://seata.io/zh-cn/docs/overview/what-is-seata.htmlopen in new window

其实分布式事务产生的一个重要原因，就是参与事务的多个分支事务互相无感知，不知道彼此的执行状态。因此解决分布式事务的思想非常简单：

就是找一个统一的事务协调者第三者，与多个分支事务通信，检测每个分支事务的执行状态，保证全局事务下的每一个分支事务同时成功或失败即可。大多数的分布式事务框架都是基于这个理论来实现的。

在 Seata 的事务管理中有三个重要的角色：

TC(Transaction Coordinator)-事务协调者：维护全局和分支事务的状态，协调全局事务提交或回滚。
TM (Transaction Manager) -事务管理器：定义全局事务的范围、开始全局事务、提交或回滚全局事务。
RM (Resource Manager) -资源管理器：管理分支事务，与 TC 交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。

Seata 的工作架构如图所示：

其中，TM 和 RM 可以理解为 Seata 的客户端部分，引入到参与事务的微服务依赖中即可。将来 TM 和 RM 就会协助微服务，实现本地分支事务与 TC 之间交互，实现事务的提交或回滚。

而 TC 服务则是事务协调中心，是一个独立的微服务，需要单独部署。

总结

课堂作业

Seata是什么？能解决什么问题？🎤
Seata有哪几个重要的角色？分别是什么意思？🎤

2.2.部署TC服务

部署TC服务

在docker中部署Seata的TC服务 🎯

代码操作

2.2.1.准备数据库表

Seata 支持多种存储模式，但考虑到持久化的需要，我们一般选择基于数据库存储。执行课前资料提供的 《seata-tc.sql》，导入数据库表：

2.2.2.准备配置文件

课前资料准备了一个 seata 目录，其中包含了 seata 运行时所需要的配置文件：

其中包含中文注释，大家可以自行阅读。

我们将整个 seata 文件夹拷贝到虚拟机的 /root 目录：

2.2.3.Docker 部署

在虚拟机的 /root 目录执行下面的命令：

docker run --name seata \
-p 8099:8099 \
-p 7099:7099 \
-e SEATA_IP=192.168.138.135 \
-v ./seata:/seata-server/resources \
--privileged=true \
--network hmall \
-d \
seataio/seata-server:1.5.2

成功后，打开nacos配置中心，如下图：

如果镜像下载困难，也可以把课前资料提供的镜像上传到虚拟机并加载：

注意：检查nacos和mysql是否在hmall网络中

docker inspect mysql
docker inspect nacos

# 将nacos 添加到指定的网络
docker run -d \
--name nacos \
--env-file ./nacos/custom.env \
-p 8848:8848 \
-p 9848:9848 \
-p 9849:9849 \
--restart=always \
--network hmall \
nacos/nacos-server:v2.1.0-slim

mysql nacos 以及seata需要再同一个网络（如：hmall)中，这样可以使用服务名进行通讯

总结

课堂作业

TC服务是什么服务？有什么作用？🎤

2.3.微服务集成Seata

微服务集成Seata

参与分布式事务的每一个微服务都需要集成 Seata，我们以 trade-service 为例。

代码操作

2.3.1.引入依赖

为了方便各个微服务集成 seata，我们需要把 seata 配置共享到 nacos，因此 trade-service 模块不仅仅要引入 seata 依赖，还要引入 nacos 依赖: 点击刷新

<!--统一配置管理-->
  <dependency>
      <groupId>com.alibaba.cloud</groupId>
      <artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId>
  </dependency>
  <!--读取bootstrap文件-->
  <dependency>
      <groupId>org.springframework.cloud</groupId>
      <artifactId>spring-cloud-starter-bootstrap</artifactId>
  </dependency>
  <!--seata-->
  <dependency>
      <groupId>com.alibaba.cloud</groupId>
      <artifactId>spring-cloud-starter-alibaba-seata</artifactId>
  </dependency>
  <!--sentinel-->
  <dependency>
      <groupId>com.alibaba.cloud</groupId>
      <artifactId>spring-cloud-starter-alibaba-sentinel</artifactId>
  </dependency>

2.3.2.改造配置

首先在 nacos 上添加一个共享的 seata 配置，命名为 shared-seata.yaml：

内容如下：

seata:
  registry: # TC服务注册中心的配置，微服务根据这些信息去注册中心获取tc服务地址
    type: nacos # 注册中心类型 nacos
    nacos:
      server-addr: 192.168.138.135:8848 # nacos地址
      namespace: "" # namespace，默认为空
      group: DEFAULT_GROUP # 分组，默认是DEFAULT_GROUP
      application: seata-server # seata服务名称
      username: nacos
      password: nacos
  tx-service-group: hmall # 事务组名称
  service:
    vgroup-mapping: # 事务组与tc集群的映射关系
      hmall: "default"

然后，改造 trade-service 模块，添加 bootstrap.yaml：

bootstrap.yaml内容如下:

spring:
  application:
    name: trade-service # 服务名称
  profiles:
    active: dev
  cloud:
    nacos:
      server-addr: 192.168.150.101 # nacos地址
      config:
        file-extension: yaml # 文件后缀名
        shared-configs: # 共享配置
          - dataId: shared-jdbc.yaml # 共享mybatis配置
          - dataId: shared-log.yaml # 共享日志配置
          - dataId: shared-swagger.yaml # 共享日志配置
          - dataId: shared-seata.yaml # 共享seata配置

可以看到这里加载了共享的 seata 配置。

然后改造 application.yaml 文件，内容如下：

server:
  port: 8085
feign:
  okhttp:
    enabled: true # 开启OKHttp连接池支持
  sentinel:
    enabled: true # 开启Feign对Sentinel的整合
hm:
  swagger:
    title: 交易服务接口文档
    package: com.hmall.trade.controller
  db:
    database: hm-trade

参考上述办法分别改造 hm-cart 和 hm-item 两个微服务模块。

点击查看hm-cart的改造点击查看hm-item的改造

2.3.3.添加数据库表

seata 的客户端在解决分布式事务的时候需要记录一些中间数据，保存在数据库中。因此我们要先准备一个这样的表。

将课前资料的 seata-at.sql 分别文件导入 hm-trade、hm-cart、hm-item 三个数据库中：

结果：

OK，至此为止，微服务整合的工作就完成了。可以参考上述方式对 hm-item 和 hm-cart 模块完成整合改造。

2.3.4.测试

接下来就是测试的分布式事务的时候了。

我们找到 trade-service 模块下的 com.hmall.trade.service.impl.OrderServiceImpl 类中的 createOrder 方法，也就是下单业务方法。

将其上的 @Transactional 注解改为 Seata 提供的 @GlobalTransactional：

@GlobalTransactional 注解就是在标记事务的起点，将来 TM 就会基于这个方法判断全局事务范围，初始化全局事务。

我们重启 trade-service、item-service、cart-service 三个服务。再次测试，发现分布式事务的问题解决了！

那么，Seata 是如何解决分布式事务的呢？

总结

课堂作业

参考上述步骤，将分布式事务问题进行解决？🎤

2.4.XA模式

XA模式

官网链接：https://seata.io/zh-cn/docs/user/mode/atopen in new window

Seata 支持四种不同的分布式事务解决方案：

XA
TCC
AT
SAGA

这里我们以 XA 模式和 AT 模式来给大家讲解其实现原理。

XA 规范是 X/Open 组织定义的分布式事务处理（DTP，Distributed Transaction Processing）标准，XA 规范描述了全局的 TM 与局部的 RM 之间的接口，几乎所有主流的数据库都对 XA 规范提供了支持。

代码操作

2.4.1.两阶段提交

A 是规范，目前主流数据库都实现了这种规范，实现的原理都是基于两阶段提交。

正常情况：

异常情况：

一阶段：

事务协调者通知每个事务参与者执行本地事务
本地事务执行完成后报告事务执行状态给事务协调者，此时事务不提交，继续持有数据库锁

二阶段：

事务协调者基于一阶段的报告来判断下一步操作
如果一阶段都成功，则通知所有事务参与者，提交事务
如果一阶段任意一个参与者失败，则通知所有事务参与者回滚事务

2.4.2.Seata 的 XA 模型

Seata 对原始的 XA 模式做了简单的封装和改造，以适应自己的事务模型，基本架构如图：

RM 一阶段的工作：

注册分支事务到 TC
执行分支业务 sql 但不提交
报告执行状态到 TC

TC 二阶段的工作：

TC 检测各分支事务执行状态
1. 如果都成功，通知所有 RM 提交事务
2. 如果有失败，通知所有 RM 回滚事务

RM 二阶段的工作：

接收 TC 指令，提交或回滚事务

总结

优缺点

XA 模式的优点是什么？

事务的强一致性，满足 ACID 原则
常用数据库都支持，实现简单，并且没有代码侵入

XA 模式的缺点是什么？

因为一阶段需要锁定数据库资源，等待二阶段结束才释放，性能较差
依赖关系型数据库实现事务

课堂作业

XA的优缺点是什么？🎤

2.5.AT模式

AT模式

AT 模式同样是分阶段提交的事务模型，不过缺弥补了 XA 模型中资源锁定周期过长的缺陷。

Seata 的 AT 模型

基本流程图：

阶段一 RM 的工作：

注册分支事务
记录 undo-log（数据快照）
执行业务 sql 并提交
报告事务状态

阶段二提交时 RM 的工作：

删除 undo-log 即可

阶段二回滚时 RM 的工作：

根据 undo-log 恢复数据到更新前

流程梳理

我们用一个真实的业务来梳理下 AT 模式的原理。

比如，现在有一个数据库表，记录用户余额：

###### id	###### money
1	100

其中一个分支业务要执行的 SQL 为：

update tb_account set money = money - 10 where id = 1

AT 模式下，当前分支事务执行流程如下：

一阶段：

TM 发起并注册全局事务到 TC
TM 调用分支事务
分支事务准备执行业务 SQL
RM 拦截业务 SQL，根据 where 条件查询原始数据，形成快照。

{
  "id": 1, "money": 100
}

RM 执行业务 SQL，提交本地事务，释放数据库锁。此时 money = 90
RM 报告本地事务状态给 TC

二阶段：

TM 通知 TC 事务结束
TC 检查分支事务状态
1. 如果都成功，则立即删除快照
2. 如果有分支事务失败，需要回滚。读取快照数据（{"id": 1, "money": 100}），将快照恢复到数据库。此时数据库再次恢复为 100

流程图：

总结

简述 AT 模式与 XA 模式最大的区别是什么？

XA 模式一阶段不提交事务，锁定资源；AT 模式一阶段直接提交，不锁定资源。
XA 模式依赖数据库机制实现回滚；AT 模式利用数据快照实现数据回滚。
XA 模式强一致；AT 模式最终一致

可见，AT 模式使用起来更加简单，无业务侵入，性能更好。因此企业 90% 的分布式事务都可以用 AT 模式来解决。

课堂作业

XA模式的特点是什么？和AT模式有何区别？🎤

3.练习

练习

3.1 编写降级逻辑

给黑马商城中现有的 FeignClient 都编写对应的降级逻辑，并且改造项目中每一个微服务，将 OpenFeign 与 Sentinel 整合。

3.2 解决分布式事务

除了下单业务以外，用户如果选择余额支付，前端会将请求发送到 pay-service 模块。而这个模块要做三件事情：

直接从 user-service 模块调用接口，扣除余额付款
更新本地（pay-service）交易流水表状态
通知交易服务（trade-service）更新其中的业务订单状态

流程如图：

显然，这里也存在分布式事务问题。

对应的页面如下：

当我们提交订单成功后，进入支付页面，选择余额支付，输入密码后点击确认支付即可。

前端会提交支付请求，业务接口的入口在 com.hmall.pay.controller.PayController 类的 tryPayOrderByBalance 方法：

对应的 service 方法如下：

@Override
@Transactional
public void tryPayOrderByBalance(PayOrderDTO payOrderDTO) {
    // 1.查询支付单
    PayOrder po = getById(payOrderDTO.getId());
    // 2.判断状态
    if(!PayStatus.WAIT_BUYER_PAY.equalsValue(po.getStatus())){
        // 订单不是未支付，状态异常
        throw new BizIllegalException("交易已支付或关闭！");
    }
    // 3.尝试扣减余额
    userClient.deductMoney(payOrderDTO.getPw(), po.getAmount());
    // 4.修改支付单状态
    boolean success = markPayOrderSuccess(payOrderDTO.getId(), LocalDateTime.now());
    if (!success) {
        throw new BizIllegalException("交易已支付或关闭！");
    }
    // 5.修改订单状态
    tradeClient.markOrderPaySuccess(po.getBizOrderNo());
}

利用 seata 解决这里的分布式事务问题，并思考这个业务实现有没有什么值得改进的地方

day05-服务保护和分布式事务

# day05-服务保护和分布式事务

# 1.微服务保护

# 1.1.服务保护方案

# 1.1请求限流

# 1.2.线程隔离

# 1.3.服务熔断

# 1.2.Sentinel

# 1.3.请求限流

# 1.4.线程隔离

# 1.1.OpenFeign 整合 Sentinel

# 1.2.配置线程隔离

# 1.5.服务熔断

# 1.编写降级逻辑

# 2.服务熔断

# 2.分布式事务

# 2.1.认识 Seata

# 2.2.部署TC服务

# 2.2.1.准备数据库表

# 2.2.2.准备配置文件

# 2.2.3.Docker 部署

# 2.3.微服务集成Seata

# 2.3.1.引入依赖

# 2.3.2.改造配置

# 2.3.3.添加数据库表

# 2.3.4.测试

# 2.4.XA模式

# 2.4.1.两阶段提交

# 2.4.2.Seata 的 XA 模型

# 优缺点

# 2.5.AT模式

# Seata 的 AT 模型

# 流程梳理

# 3.练习

# 3.1 编写降级逻辑

# 3.2 解决分布式事务

day05-服务保护和分布式事务

1.微服务保护

1.1.服务保护方案

1.1请求限流

1.2.线程隔离

1.3.服务熔断

1.2.Sentinel

1.3.请求限流

1.4.线程隔离

1.1.OpenFeign 整合 Sentinel

1.2.配置线程隔离

1.5.服务熔断

1.编写降级逻辑

2.服务熔断

2.分布式事务

2.1.认识 Seata

2.2.部署TC服务

2.2.1.准备数据库表

2.2.2.准备配置文件

2.2.3.Docker 部署

2.3.微服务集成Seata

2.3.1.引入依赖

2.3.2.改造配置

2.3.3.添加数据库表

2.3.4.测试

2.4.XA模式

2.4.1.两阶段提交

2.4.2.Seata 的 XA 模型

优缺点

2.5.AT模式

Seata 的 AT 模型

流程梳理

3.练习

3.1 编写降级逻辑

3.2 解决分布式事务