微服务雪崩问题、Sentinel（请求限流、线程隔离、服务熔断）、Seata分布式事务

最新推荐文章于 2024-06-13 16:49:54 发布

爱吃鱼的cc

最新推荐文章于 2024-06-13 16:49:54 发布

阅读量941

点赞数 17

分类专栏： Spring Cloud 文章标签：微服务 sentinel 分布式

本文链接：https://blog.csdn.net/qq_51076441/article/details/139050527

版权

Spring Cloud 专栏收录该内容

3 篇文章 0 订阅

订阅专栏

文章目录

前言
一、微服务保护
二、Sentinel
三、分布式事务

前言

微服务之间为什么会雪崩？怎么解决雪崩问题？
如何采用Sentiel整合微服务实现请求限流、线程隔离以及服务熔断问题。
怎么集成Seata解决微服务之间引发的分布式事务问题？

一、微服务保护

在这里插入图片描述

1、请求限流
限制访问微服务的请求的并发量，避免服务因流量激增出现故障。

2、线程隔离
舱壁模式，模拟船舱隔板的防水原理。通过限定每个业务能使用的线程数量而将故障业务隔离，避免故障扩散。
例如：查询购物车的时候需要查询商品，为了避免因商品服务出现故障导致购物车服务级联失败，我们可以把购物车业务中查询商品的部分隔离起来，限制可用的线程资源，即便商品服务出现故障，最多导致查询购物车业务故障，并且可用的线程资源也被限定在一定范围，不会导致整个购物车服务崩溃。
在这里插入图片描述

3、服务熔断
由断路器统计请求的异常比例或慢调用比例，如果超出阈值则会熔断该业务，则拦截该接口的请求。
熔断期间，所有请求快速失败，全都走fallback逻辑。
在这里插入图片描述

4、失败处理
给业务编写一个调用失败时的处理的逻辑，称为fallback。当调用出现故障（比如无线程可用）时，按照失败处理逻辑执行业务并返回，而不是直接抛出异常。
在这里插入图片描述

二、Sentinel

Sentinel是阿里巴巴开源的一款服务保护框架。
在这里插入图片描述

2.1 微服务整合

1、引入sentinel依赖

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

2、配置控制台。

spring:
  cloud: 
    sentinel:
      transport:
        dashboard: localhost:8090  #访问地址

3、访问微服务块的任意断点，如访问查询购物车接口，sentinel的客户端就会将服务访问的信息提交到sentinel-dashboard控制台

2.2 簇点链路

单机调用链路。是一次请求进入服务后经过的每一个被Sentinel监控的资源链。默认Sentinel会监控SpringMVC的每一个Endpoint（http接口）。限流、熔断等都是针对簇点链路中的资源设置的。而资源名默认就是接口的请求路径。
打开Sentinel的请求方式前缀，把请求方式 + 请求路径作为簇点资源名。
在这里插入图片描述

2.3 请求限流

在簇点链路后面点击流控按钮，即可对其做限流配置。
簇点资源的流量限制在了每秒6个，也就是最大QPS为6. 在这里插入图片描述

2.4 线程隔离

解决服务故障
实现步骤
1、OpenFeign整合Sentinel，为了开启远程调用feignclient作为簇点，可以被流量监控。

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

2、配置线程隔离
在这里插入图片描述

2.5 服务熔断

请求失败不应该抛异常，为了让用户体验更好，可以返回一些默认数据或者友好提示，查询失败设置一个降级处理逻辑。
对于这种不太健康的接口，应该直接停止调用，避免影响到当前服务。也就是将接口熔断。
实现步骤
1、编写降级逻辑
给FeignClient编写失败后的降级逻辑两种方式：

方式一：FallbackClass，无法对远程调用的异常做处理
方式二：FallbackFactory，可以对远程调用的异常做处理，我们一般选择这种方式。
步骤1：定义一个降级处理类ItemClientFallback，实现FallbackFactory。

@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);
            }
        };
    }
}

步骤2：编写一个配置类，在配置类中将ItemClientFallback注册为一个Bean。

public class DefaultFeignConfig {
    @Bean
    public Logger.Level feginLogLevel(){
        return Logger.Level.FULL;
    }
    @Bean
    public ItemClientFallbackFactory itemClientFallbackFactory(){
        return new ItemClientFallbackFactory();
    }
}

步骤3：在ItemClient接口中使用ItemClientFallbackFactory

@FeignClient(value = "item-service",
        fallbackFactory = ItemClientFallbackFactory.class)
public interface ItemClient {...}

2、服务熔断
由断路器统计服务调用的异常比例、慢请求比例，如果超出阈值则会熔断该服务。即拦截访问该服务的一切请求；而当服务恢复时，断路器会放行访问该服务的请求。
断路器的工作状态切换有一个状态机来控制
在这里插入图片描述

closed：关闭状态，断路器放行所有请求，并开始统计异常比例、慢请求比例。超过阈值则切换到open状态
open：打开状态，服务调用被熔断，访问被熔断服务的请求会被拒绝，快速失败，直接走降级逻辑。Open状态持续一段时间后会进入half-open状态
half-open：半开状态，放行一次请求，根据执行结果来判断接下来的操作。
- 请求成功：则切换到closed状态
- 请求失败：则切换到open状态
  点击控制台中簇点资源后的熔断按钮，即可配置熔断策略
RT超过200毫秒的请求调用就是慢调用
统计最近1000ms内的最少5次请求，如果慢调用比例不低于0.5，则触发熔断
熔断持续时长20s

三、分布式事务

如果一个业务需要多个服务合作完成，而且每一个服务都有事务，多个事务必须同时成功或失败，这样的事务就是分布式事务。其中的每个服务的事务就是一个分支事务。整个业务称为全局事务。
在这里插入图片描述

3.1 Seata

参与事务的多个分支事务互相无感知，不知道彼此的执行状态。找一个统一的事务协调者，与多个分支事务通信，检测每个分支事务的执行状态，保证全局事务下的每一个分支事务同时成功或失败即可。
在这里插入图片描述

3.1.1 Seata架构

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

3.1.2 部署TC服务

TC服务是事务协调中心，是一个独立的微服务，需要单独部署。
基于数据库持久化存储，采用docker部署seata
具体部署不做说明。

3.1.3 微服务集成Seata

参与分布式事务的每一个微服务都需要集成Seata
实现步骤
1、引入依赖
为了方便各个微服务集成seata，需要把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>

2、在nacos中配置seata
在这里插入图片描述
3、在微服务中添加bootstrap.yaml文件，定义nacos配置信息。
4、添加数据库表。seata的客户端在解决分布式事务的时候需要记录一些中间数据，保存在数据库中。要讲数据库表分别导入不同的微服务当中。
5、测试分布式事务
在订单业务方法上的@Transactional注解改为Seata提供的**@GlobalTransactional**
@GlobalTransactional注解就是在标记事务的起点，将来TM就会基于这个方法判断全局事务范围，初始化全局事务。

3.2 XA模式

Seata支持四种不同的分布式事务解决方案: XA、TCC、 AT、SAGA
XA 规范描述了全局的TM与局部的RM之间的接口，几乎所有主流的数据库都对 XA 规范提供了支持。
A是规范，目前主流数据库都实现了这种规范，实现的原理都是基于两阶段提交。
在这里插入图片描述优点

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

缺点：

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

seata中实现XA
1、Nacos中的共享shared-seata.yaml配置文件中设置

seata:
  data-source-proxy-mode: XA

2、@GlobalTransactional标记分布式事务的入口方法

3.3 AT模式

Seata主推的是AT模式，AT模式同样是分阶段提交的事务模型，不过缺弥补了XA模型中资源锁定周期过长的缺陷。
在这里插入图片描述
流程图
AT模式与XA模式最大的区别是什么？
XA模式一阶段不提交事务，锁定资源；AT模式一阶段直接提交，不锁定资源。
XA模式依赖数据库机制实现回滚；AT模式利用数据快照实现数据回滚。
XA模式强一致；AT模式最终一致

爱吃鱼的cc

关注

17
点赞
踩
17

收藏

觉得还不错? 一键收藏
0
评论
微服务雪崩问题、Sentinel（请求限流、线程隔离、服务熔断）、Seata分布式事务

微服务之间为什么会雪崩？怎么解决雪崩问题？如何采用Sentiel整合微服务实现请求限流、线程隔离以及服务熔断问题。怎么集成Seata解决微服务之间引发的分布式事务问题？
复制链接

扫一扫