目录

微服务Sentinel组件服务保护详解

微服务Sentinel组件:服务保护详解


服务保护简介

微服务保护是为了保障系统整体的稳定性和可靠性,保证服务运行的健壮性,避免级联失败导致的雪崩问题。这个是针对于 服务之间的调用 所呈现的方案。

服务保护方案

请求限流: 通过限制到达服务的请求数量来保护后端服务不被过多请求压垮。

线程隔离: 将不同服务或任务分配到不同的线程池中执行,以避免某一个服务出现问题时影响其他服务的正常运行。

服务熔断: 当某个服务出现故障或者响应时间过长时,自动切断该服务的调用,防止因为等待该服务而导致整个系统的阻塞。

安装与介绍Sentinel

下载jar包

https://github.com/alibaba/Sentinel/releases

https://i-blog.csdnimg.cn/direct/d8271996ee8e431b9cbe1253783aede7.png

然后运行如下命令启动控制台:(打开cmd窗口)

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

访问 页面,就可以看到sentinel的控制台了:

https://i-blog.csdnimg.cn/direct/641172f5e50d4d0d8e8cc69fd37bc721.png

输入用户和密码,都是sentinel,即可登录成功。

Sentinel整合微服务

在微服务模块,引入sentinel依赖

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

修改application.yaml文件,添加下面内容:

spring:
  cloud:
    sentinel:
      transport:
        dashboard: localhost:8090 # sentinel
      http-method-specify: true # 是否设置请求方式作为资源名称

随意测试CRUD的接口,观察控制台如下:即整合成功

https://i-blog.csdnimg.cn/direct/8dcf3238f927401ca9dfab999f984694.png


服务保护实现

请求限流

问题描述:在流量出现突发增长时,由于并发请求过高,在面对突如其来的流量高峰时容易发生过载,进而引发服务故障。

解决方案:通过实施请求限流措施来限制或控制接口访问的并发流量,可以在很大程度上避免因流量激增而导致的服务故障,从而保障服务的正常运行。

实现过程:

打开Sentinel控制台,点击簇点链路,看到查询接口的流控按钮

https://i-blog.csdnimg.cn/direct/603874c65f6f4b4ea34326a0689bbe93.png

点击,设置QPS为5即可

https://i-blog.csdnimg.cn/direct/dda704c830ad4540b08c7eed02c3d3b9.png

使用Jemeter做限流测试

https://i-blog.csdnimg.cn/direct/2ef2e5cd1a3d4400acb0f9eb5a1697b3.png

经过测试对比,明显可以观察到流量削峰。


线程隔离

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

解决方案:通过实施线程隔离,我们可以将不同接口的执行分配给独立的线程池,从而防止因单一接口耗尽资源而拖垮整个服务的情况发生。这样做的目的是限制故障范围。

OpenFeign整合Sentinel

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

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

需要配置一下cart-service模块的application.yml文件,修改tomcat连接:

server:
  port: 8082
  tomcat:
    threads:
      max: 50 # 允许的最大线程数
    accept-count: 50 # 最大排队等待数量
    max-connections: 100 # 允许的最大连接

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

配置线程隔离

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

https://i-blog.csdnimg.cn/direct/ff37056bc6b049b690cf860f93b64a3d.png

将并发线程数设置为5(如果QPS为5,那么接口一秒只能接收25条请求)

https://i-blog.csdnimg.cn/direct/3896e3024c8949b6a4dc007a111b468c.png

我们利用Jemeter测试,每秒发送100个请求:

https://i-blog.csdnimg.cn/direct/89696792e5794cffb5a83822a6a47507.png

观察结果可知:我们去访问其他接口,不会被拖慢速度,实现线程隔离


服务熔断

问题描述:当服务中某个组件或接口出现故障或者响应时间过长时,会导致整个系统性能下降甚至完全不可用。特别是在高并发场景下,如果某个业务接口出现问题,大量的请求会堆积等待,导致线程资源被迅速耗尽,进而影响到整个服务的正常运行。

解决方案:服务熔断正是为此设计的一种保护措施,它能够在检测到指定服务或接口出现问题时,主动切断对该部分的调用,使其进入快速失败模式,从而保护系统的其余部分不受影响,并为故障恢复争取时间。

编写降级逻辑

在公共模块中给 ItemClient 定义降级处理类,实现 FallbackFactory

@Slf4j
public class ItemClientFallbackFactory implements FallbackFactory<ItemClient> {
    @Override
    public ItemClient create(Throwable cause) {
        return new ItemClient() {
            @Override
            public List<ItemDTO> queryItemByIds(Set<Long> ids) {
                log.error("查询商品失败", cause);
                return CollUtils.emptyList();
            }

            @Override
            public List<OrderDetailDTO> deductStock(List<OrderDetailDTO> items) {
                log.error("扣减库存失败", cause);
                throw new RuntimeException(cause);
            }
  

在配置类中注册为bean:

 @Bean
    public ItemClientFallbackFactory imageClientFallbackFactory() {
        return new ItemClientFallbackFactory();
    }

在OpenFegin配置的远程调用类上使用:

https://i-blog.csdnimg.cn/direct/e613bca337cb49b0a56e09ec0088a6f4.png

实现服务熔断

服务熔断流程图:

https://i-blog.csdnimg.cn/direct/9d8755981aa6432aae25566b3d64001e.png

在Sentinel控制台通过点击簇点后的 熔断 按钮来配置熔断策略:

https://i-blog.csdnimg.cn/direct/e21eff4746fe47e7a678219d602828b9.png

如下图所示填写对应数据:

https://i-blog.csdnimg.cn/direct/0a02b676366e41d6a1c82734820fdb0a.png

我们利用Jemeter测试,每秒发送100个请求,观察结果:

https://i-blog.csdnimg.cn/direct/24c463122bbf402c93559f1d8599349e.png

在一开始一段时间是允许访问的,后来触发熔断后,查询商品服务的接口通过QPS直接为0,所有请求都被熔断了。 所以成功实现服务熔断。

服务保护总结

在之前,我们为了实现服务之间的远程调用,采用OpenFegin大大简化了客户端代码,轻松实现服务之间的访问。但是,服务之间的访问保护却没有实现。所以,我们引入了Sentinel。

为了防止某个服务因为过载而导致整个系统的响应时间变慢或者崩溃,配置Sentinel的流量控制规则,可以限制对特定微服务的请求频率。 ( 请求限流

为了防止一旦某个服务出现故障,因而拖慢了其他服务,导致发生雪崩,可以配置Sentinel限制对特定微服务的请求线程数,限制隔离范围。 ( 线程隔离

为了能够在检测到指定服务或接口出现问题时,主动切断对该部分的调用,可以让Sentinel会自动触发熔断机制,阻止对该服务的进一步请求,并快速失败,避免雪崩效应的发生。 ( 服务熔断