【开发】微服务整合Sentinel

SueWakeup

已于 2024-03-16 18:24:58 修改

阅读量959

点赞数 19

分类专栏：学习Java框架为祖国的科技进步添砖Java 文章标签：微服务 sentinel java

于 2024-03-13 18:05:52 首次发布

本文链接：https://blog.csdn.net/LikewaterwithLi/article/details/136684210

版权

为祖国的科技进步添砖Java 同时被 2 个专栏收录

36 篇文章 1 订阅

订阅专栏

学习Java框架

9 篇文章 0 订阅

订阅专栏

前言

在整合Sentinel前，我们需要了解一下微服务中的雪崩问题：

雪崩问题：在微服务中，如果服务提供者发生了故障，当前应用的部分业务因为依赖于该服务，因此也会被阻塞。请求一直阻塞，会导致服务器资源耗尽，从而导致其他服务都不可用，形成级联失败，从而形成雪崩问题。

1W：什么是`Sentinel`？

Sentinel是阿里巴巴开源的一款微服务流量控制组件。

Sentinel官网https://sentinelguard.io/zh-cn/index.html

2W：为什么使用Sentinel？

丰富的应用场景：Sentinel承接了阿里巴巴近10年来的双十一大促流量的核心场景，例如秒杀（突发流量控制在系统容量的可承受范围内）、消息削峰填谷、集群流量控制、实时熔断下游不可用应用等。
完备的实时监控：Sentinel提供实时监控功能。可以在控制台中看到接入到应用的单台机器秒级数据，甚至500台以下规模的集群的汇总运行情况。
广泛的开源生态：Sentinel提供开箱即用的与其他开源框架/库的整合模块，例如与Spring Cloud、Dubbo、gRPC的整合。我们只需要引入相关的依赖并进行简单的配置即可快速地接入Sentinel。
完善的SPI扩展点：Sentinel提供简单易用、完善的SPI扩展接口。我们可以通过实现扩展接口来快速地定制逻辑。例如：定制规则管理、适配动态数据源等。

3W：如何使用Sentinel？

1. 在pom.xml中导入Sentinel依赖坐标

<!-- https://mvnrepository.com/artifact/com.alibaba.cloud/spring-cloud-starter-alibaba-sentinel -->
<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-sentinel</artifactId>
    <version>2021.1</version>
</dependency>

2. 配置控制台

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

spring:
  cloud:
    sentinel:
      transport:
        dashboard: localhost:[端口号]

3. 访问API接口的任意端点

打开浏览器，访问http://localhost:端口号/API接口，触发sentinel的监控。

然后访问sentinel控制台

默认路径为：http://localhost:8080页面

默认登录账号：sentinel

默认登录密码：sentinel

流量控制

限流是避免服务因突发的流量而发生故障。

1. 簇点链路

当请求进入微服务时，会首先访问DispatcherServlet，然后进入Controller、Service、Mapper，这样的一个调用链叫做簇点链路。

簇点链路中被监控的每一个接口都是一个资源。

默认情况下sentinel会监控SpringMVC的每一个端点（Endpoint，也就是controller层中的方法），因此SpringMVC的每一个端点（Endpoint）就是调用链路中的一个资源。

流控、熔断等都是针对簇点链路中的资源来设置，因此我们可以点击对应资源后面的按钮来设置规则：

流控：流量控制
降级：降级熔断
热点：热点参数限流，限流的一种方式
授权：请求的权限控制

2. 快速入门

点击资源/order/prod/{pid}后面的流控按钮，弹出表单。

QPS：线程数（用户数量）/用户访问时间 =请求数/秒，即每秒的响应请求数，也就是最大吞吐量。

在sentinel控制台添加限流规则，QPS的单机阈值为五，然后测试。
利用jmeter测试；

20个用户，2秒内运行完，QPS是10，超过了5

选中流控入门，QPS<5 右击运行：

结果：成功的请求每次只有5个

流控模式

在添加限流规则时，点击高级选项，可以选择三种流控模式：

直接：统计当前资源的请求，触发阈值时对当前资源直接限流，也是默认模式；
关联：统计与当前资源相关的另一个资源，触发阈值时，对当前资源限流；
链路：统计从指定链路访问到本资源的请求时，触发阈值时，对指定链路限流；

1. 直接模式

快速入门测试就是直接模式。

2. 关联模式

关联模式：统计与当前资源相关的另一个资源，触发阈值时，对当前资源限流；

配置规则：

语法说明：当/write资源访问量触发阈值时，就会对/read资源限流，避免影响/write资源

使用场景：比如用户支付时需要修改订单状态，同时用户要查询订单。查询和修改操作会争抢数据库锁，产生竞争。业务需求是优先支付和更新订单的业务，因此当修改订单业务触发阈值时，需要对查询订单业务限流。

需求说明：

添加两个新的端点：/order/query和/order/update

@GetMapping("/order/query")
public String queryOrder(){
    return "查询订单成功";
}

@GetMapping("/order/update")
public String updateOrder(){
    return "更新订单成功";
}

配置流控规则，当/order/update资源被访问的QPS超过5时，对/order/query请求限流

可以看到1000个用户，100秒，QPS为10，超过了设置的阈值：5

请求的目标是/order/update，这样这个端点就会触发阈值

但限流的目标是/order/query，我们在浏览器访问，发现：确实被限流了

3. 链路模式

链路模式：统计从指定链路访问到本资源的请求时，触发阈值时，对指定链路限流；

配置示例：

例如有两条请求链路：

/test1 --> /common
/test2 --> /common
如果只希望统计从/test2进入到/common的请求，可以这样配置：

需求说明：

1.在OrderService中添加一个queryGoods方法，不用实现业务；

public void queryGoods(){
    System.err.println("查询商品");
}

2.在OrderController中，改造/order/query端点，调用OrderService中的queryGoods方法；

@GetMapping("/order/query")
public String queryOrder(){
    //查询商品
    orderService.queryGoods();
    //查询订单
    System.out.println("查询订单");
    return "查询订单成功";
}

3.在OrderController中添加一个/order/save的端点，调用OrderService的queryGoods方法

@GetMapping("/order/save")
public String saveOrder(){
    //查询商品
    orderService.queryGoods();
    //查询订单
    System.out.println("新增订单");
    return "新增订单成功";
    
}

4.给queryGoods配置限流规则，从/order/query进入queryGoods的方法限制QPS必须小于2

@SentinelResource("goods")
public void queryGoods(){
    System.err.println("查询商品");
}

链路模式中，是对不同来源的两个链路做监控。但是sentinel默认会给进入Spring MVC的所有请求设置同一个root资源，导致链路模式失效。

我们需要关闭这种对Spring MVC的资源聚合，修改order-service服务的application.yml文件：

spring:
  cloud:
    sentinel:
      web-context-unify: false #关闭context整合

重启服务，访问/order/query和/order/save，可以查看sentinel的簇点链路规则中，出现了新的资源：

添加流控规则

点击goods资源后面的流控按钮，在弹出的表单中填写下面信息：

只统计从/order/query进入/goods的资源，QPS的阈值为2，超出则被限流。

可以看到这里200个用户，50秒内发完，QPS为4，超过了我们设定的阈值2

一个http请求是访问/order/save：运行的结果：完全不受影响

4. 总结

流控模式有哪些？

直接：对当前资源限流；
关联：高优先级资源触发阈值，对低优先级资源限流；
链路：阈值统计时，只统计从指定资源进入当前资源的请求，是对请求来源的限流；

流控效果

流控效果是指请求达到流控阈值时应该采取的措施：

快速失败：达到阈值后，新的请求会被立即拒绝并抛出FlowException异常。是默认的处理方式；
warm up：预热模式，对超出阈值的请求同样是拒绝并抛出异常。但这种模式阈值会动态变化，从一个较小值逐渐增加到最大阈值；
排队等待：让所有的请求按照先后次序排队执行，两个请求的间隔不能小于指定时长；

1. warm up

warm up也叫预热模式，是应对服务冷启动的一种方案。请求阈值初始值是maxThreshold / coldFactor，持续指定时长后，逐渐提高到maxThreshold值。而coldFactor的默认值是3；

需求说明：

给/order/prod/{pid}这个资源设置限流，最大QPS为10，利用warm up效果，预热时长为5秒

刚刚启动时，大部分请求失败，成功的只有3个，说明QPS被限定在3：随着时间推移，成功比例越来越高；

2. 排队等待

当请求超过QPS阈值时，快速失败和warm up会拒绝新的请求并抛出异常。

排队等待是让所有请求进入一个队列中，然后按照阈值允许的时间间隔依次执行。后面的请求必须等待前面执行完成，如果请求预期的等待时间超出最大时长，则会被拒绝。

需求说明：

给/order/prod/{pid}这个资源设置限流，最大QPS为10，利用排队的流控效果，超时时长设置为5s

QPS为15，已经超过了我们设定的10

如果是之前的快速失败、warmup模式，超出的请求应该会直接报错

全部通过

QPS非常平滑，一致保持在10，但超出的请求没有被拒绝，而是放入队列。

3. 总结

流控效果：

快速失败：QPS超出阈值时，拒绝新的请求；
warm up：QPS超出阈值时，拒绝新的请求；QPS阈值是逐渐提升，可以避免冷启动时高并发导致服务器宕机；
排队等待：请求会进入队列，按照阈值允许的时间间隔依次执行请求；如果请求预期等待时长大于超时时间，直接拒绝；

热点数据限流

分别统计参数值相同的请求，判断是否超过QPS阈值。

案例需求：给/order/prod/{pid}这个资源加热点参数限流，规则如下：

默认的热点参数规则是每1秒请求量不超过2；
给1这个参数设置例外：每1秒请求量不超过4；
给19这个参数设置例外：每1秒请求量不超过10；

注：热点参数限流对默认的Spring MVC资源无效，需要利用@SentinelResouce注解标记资源

1. 标记资源

给shop-order中的OrderController中的/order/prod/{pid}资源添加注解：

@SentinelResouce("hot")

访问该接口，可以看到我们标记的hot资源出现了：这里不要点击hot后面的按钮，页面有bug

点击左侧菜单中热点规则菜单：

Jmeter测试

这里发起请求的QPS为5，包含3个http请求：

普通参数，QPS阈值为2

运行结果：每次成功2个请求

例外项，QPS阈值为4

运行结果：每次成功4个请求

例外项，QPS阈值为10

运行结果：每次成功所有请求

隔离和降级

线程隔离：调用者在调用服务提供者时，给每个调用的请求分配独立线程池，出现故障时，最多消耗这个线程池内资源，避免把调用者的所有资源耗尽

熔断降级：调用方这边加入断路器，统计对服务提供者的调用，如果调用的失败比例过高，则熔断该业务，不允许访问该服务的提供者

不管是线程隔离还是熔断降级都是对客户端的保护

`FeignClient`整合`Sentinel`

在SpringCloud中，微服务调用都是通过Feign来实现的，因此做客户端保护必须整合Feign和Sentinel

1.修改配置，开启sentinel功能

修改shop-Order的application.yml文件，开启Feign的Sentinel

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

2. 编写失败降级逻辑

业务失败后，不能直接报错，而应该返回用户一个友好提示或者默认结果，这个就是失败降级逻辑

给FeignClient编写失败后的降级逻辑

方式一：FallbackClass,无法对远程调用的异常做处理

方法二：FallbackFactory，可以对远程调用的异常做处理

方式①

步骤一：配置yml文件开启支持

feign:
  sentinel:
    enabled: true

步骤二：创建ProductServiceFallBack类实现降级方案编辑

@Component
public class ProductServiceFallBack implements IProductService{

       @Override
       public Product findByPid(Integer pid){
           Product product = new Product();
           product.setPid(-1);
           product.setPname("暂无商品");
           return product;
       }

}

步骤三：配置属性

@FeignClent(value="service-product",fallbackFactory = ProductServiceFallBack.class)

方法②

步骤一：配置yml文件开启支持

feign:
    sentinel:
        enabled: true

步骤二：创建ProductServiceFallBack类实现降级方案编辑

@Component
public class ProductServiceFallBack implements FallBackFactory<ProductService>{
    @Override
    public ProductService create(Throwable throwable){
        return new ProductService(){
        @Override
            public Product findByPid(Integer pid){
                System.out.println("异常信息:"+throwable);
                Product product = new Product();
                product.setPid(-1);
                product.setPname("暂无商品");
                return product;        
            }
        };
    }
}

步骤三：配置属性

@FeignClient(value="service-product",fallbackFactory = ProductServiceFallBack.class)

3.线程隔离（舱壁模式）

线程池隔离：给每个服务调用业务分配一个线程池，利用线程池本身实现隔离效果
信号量隔离（Sentinel默认采用）：不创建线程池，而是计数器模式，记录业务使用的线程数量，达到信号量上限时，禁止新的请求

案例需求：给order-service服务中的UserClient的查询用户接口设置流控规则，线程数不能超过2然后利用Jmeter测试。

一次发送10个请求，有较大概率并发线程数超过2，而超出的请求会走之前定义的失败降级逻辑。

发现虽然结果是通过了，不过部分请求得到的响应是降级返回的null信息。

总结

线程隔离的两种手段是

信号量隔离
线程池隔离

信号量隔离的特点：

基于计数器模式，简单，开销小

线程池隔离的特点：

基于线程池模式，有额外开销，但隔离控制更强

SueWakeup

关注

19
点赞
踩
13

收藏

觉得还不错? 一键收藏
0
评论
【开发】微服务整合Sentinel

流量控制：簇链链路；流控模式：直接模式、关联模式、链路模式；流控效果：warm up、排队等待；热点数据限流：标记资源；隔离和降级：FeignClient整合Sentinel；
复制链接

扫一扫

专栏目录

【开发】微服务整合Sentinel

目录

前言

1W：什么是Sentinel？

2W：为什么使用Sentinel？

3W：如何使用Sentinel？

1. 在pom.xml中导入Sentinel依赖坐标

2. 配置控制台

3. 访问API接口的任意端点

流量控制

1. 簇点链路

2. 快速入门

流控模式

1. 直接模式

2. 关联模式

3. 链路模式

4. 总结

流控效果

1. warm up

2. 排队等待

3. 总结

热点数据限流

1. 标记资源

隔离和降级

FeignClient整合Sentinel

1.修改配置，开启sentinel功能

2. 编写失败降级逻辑

方式①

方法②

3.线程隔离（舱壁模式）

总结

“相关推荐”对你有帮助么？

1W：什么是`Sentinel`？

`FeignClient`整合`Sentinel`