Day3 微服务微服务保护（请求限流、线程隔离、服务熔断）、Sentinel微服务保护框架、分布式事务（XA模式、AT模式）、Seata分布式事务框架-优快云博客

本文链接：https://blog.youkuaiyun.com/2301_77358195/article/details/144834231

目录

1.微服务保护

1.1.服务保护方案

1.1.1 请求限流

1.1.2 线程隔离

1.1.3 服务熔断

1.2 Sentinel

1.2.1.介绍和安装

1.2.2 微服务整合

1.2.2.1 引入sentinel依赖

1.2.2.2 配置控制台

1.2.2.3 访问cart-service的任意端点

1.3 请求限流

1.4 线程隔离

1.4.1 OpenFeign整合Sentinel

1.4.2 配置线程隔离

1.5.服务熔断

1.5.1 编写降级逻辑（fallback）

1.5.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.4.3 优缺点

2.4.4 实现步骤

2.5 AT模式

2.5.1 Seata的AT模型

2.5.2 流程梳理

2.5.3 AT与XA的区别

思维导图：

1.微服务保护

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

1.1.服务保护方案

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

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

这些方案或多或少都会导致服务的体验上略有下降，比如请求限流，降低了并发上限；线程隔离，降低了可用资源数量；服务熔断，降低了服务的完整度，部分服务变的不可用或弱可用。因此这些方案都属于服务降级的方案。但通过这些方案，服务的健壮性得到了提升，

1.1.1 请求限流

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

请求限流往往会有一个限流器，数量高低起伏的并发请求曲线，经过限流器就变的非常平稳。

1.1.2 线程隔离

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

线程隔离：为了避免服务器的线程资源被某个接口全部占用，导致其他接口拿不到线程资源，而引起的访问异常。

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

1.1.3 服务熔断

线程隔离虽然避免了雪崩问题，但故障服务（商品服务）依然会拖慢购物车服务（服务调用方）的接口响应速度。

服务熔断：对异常或者慢接口进行统计，超过阈值就熔断接口，此时在熔断的时间内，会拒绝该接口的所有请求。

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

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

熔断了就进入fallback了， fangback 返回了空集合所以前端显示null。

1.2 Sentinel

1.2.1.介绍和安装

Sentinel是一款服务保护框架，目前已经加入SpringCloudAlibaba中。

官方网站：https://sentinelguard.io/zh-cn/

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

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

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

1）下载jar包

下载地址：https://github.com/alibaba/Sentinel/releases

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

2）运行

将jar包放在任意非中文、不包含特殊字符的目录下，然后运行如下命令启动控制台：

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

其它启动时可配置参数可参考官方文档：https://github.com/alibaba/Sentinel/wiki/%E5%90%AF%E5%8A%A8%E9%85%8D%E7%BD%AE%E9%A1%B9

3）访问

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

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

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

1.2.2 微服务整合

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

1.2.2.1 引入sentinel依赖

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

1.2.2.2 配置控制台

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

spring:
  cloud: 
    sentinel:
      transport:
        dashboard: localhost:8090

1.2.2.3 访问`cart-service`的任意端点

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

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

簇点链路就是单机调用链路，是一次请求进入服务后经过的每一个被Sentinel监控的资源。

默认情况下，Sentinel会监控SpringMVC的每一个Endpoint（接口）。

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

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

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

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

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

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

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

1.3 请求限流

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

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

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

定义：

QPS（Queries Per Second）：每秒查询率，是对服务器在规定时间内所处理流量多少的衡量标准。

并发线程数：指的是在同一时刻系统中正在运行的线程数量。在服务器环境下，线程是处理请求的基本执行单元，并发线程数体现了系统同时处理多个任务的能力。

计算方式：

QPS 计算方式：通常通过统计一段时间内（如 1 秒）成功处理的请求数量来计算。例如，在 10 秒内服务器成功处理了 100 个请求，那么平均 QPS 就是 100/10 = 10。它更关注系统的处理能力和吞吐量，重点在于单位时间内系统能够完成的任务数量。5个并发线程，如果单线程的QPS为2，则5个线程的QPS则为10。

并发线程数计算方式：通过统计系统中同时处于运行状态的线程数量来确定。它更关注系统资源的分配和利用情况，例如 CPU、内存等资源在多个线程之间的分配。如果系统中有 10 个线程同时在运行，那么并发线程数就是 10。