微服务保护(Sentinel)

简介：java系列技术分享(持续更新中…)
初衷:一起学习、一起进步、坚持不懈
如果文章内容有误与您的想法不一致,欢迎大家在评论区指正
希望这篇文章对你有所帮助,欢迎点赞 收藏 ⭐留言

更多文章请点击

前言

雪崩问题

微服务调用链路中的某个服务故障，引起整个链路中的所有微服务都不可用，这就是雪崩。也就是级联失败

解决雪崩问题

1. 超时处理 : 设定超时时间，请求超过一定时间没有响应就返回错误信息，不会无休止地等待。
2. 舱壁模式 : 限定每个业务能使用的线程数，避免耗尽整个tomcat的资源，因此也叫线程隔离。它是通过划分tomcat的资源，划分tomcat的线程，让每个业务最多使用n个线程，进而提高tomcat的容灾能力。但是这种模式会导致一定的资源浪费
3. 熔断降级 :有断路器统计业务执行的异常比例，如果超出阈值则会熔断该业务，拦截访问该业务的一切请求。请求失败占比达到阈值后，这个时候会出现熔断，此后服务A向服务D不能发送请求，请求直接在服务A给拦截。
4. 流量控制:限制业务访问的QPS，避免服务因为流量的突增而故障。这种是从预防层面来解决雪崩问题。Sentinel可以根据服务所能接收的访问频率，向服务发送请求，避免服务出现故障，就不会出现故障转移，也就避免了雪崩问题。也就是将大量的请求一点点的发送给服务，从而预防了雪崩问题。

服务保护技术对比

因此综合考虑我们这里讲解和使用Sentinel

一、Sentinel简介

官网地址:https://sentinelguard.io/zh-cn/index.html
各种使用介绍文档:https://github.com/alibaba/Sentinel/wiki

• Sentinel是阿里开源的一套服务保护框架，它主要通过对流量的控制、熔断降级等操作来保护服务的稳定性。它以流量为切入点，从多个维度帮助开发者保障微服务的稳定性，包括流量路由、流量控制、流量整形、熔断降级、系统自适应过载保护和热点流量防护等。

• 它的主要目标是帮助开发者保护和控制分布式系统中的服务，以防止出现服务雪崩、过载、延迟和其他潜在的故障。

• 总的来说，Sentinel是一种功能强大的服务保护框架，可以帮助开发者提高微服务的稳定性和可靠性。
  
  

二、Sentinel安装

2.1 本地安装

可以前往Githubhttps://github.com/alibaba/Sentinel/releases,进入该页面
选择需要的版本进行下载
拷贝到非中文目录,运行即可

java -jar sentinel-dashboard-1.8.6.jar

默认访问 http://localhost:8080/ 账号密码都为：sentinel

如果修改Sentinel的默认端口,账户,密码....可以通过下列配置
例如:

java -jar sentinel-dashboard-1.8.1.jar -Dserver.port=8858

2.2 Docker安装

如果时云服务器,记得开放端口
拉取镜像：

docker pull bladex/sentinel-dashboard

运行镜像：

docker run --name sentinel -d -p 8858:8858 -d bladex/sentinel-dashboard

访问dashboard 地址：http://localhost:8858 账号密码都为：sentinel

三、使用步骤

3.1 引入Sentinel依赖

    
      <dependency>
          <groupId>com.alibaba.cloudgroupId>
          <artifactId>spring-cloud-starter-alibaba-sentinelartifactId>
      dependency>

3.2 yml配置

spring:
  cloud:
    sentinel:
      transport:
        dashboard: localhost:8080   #根据自己的扣扣进行配置,未改变默认8080

3.3 启动服务报错记录

可能会产生如下错误
找不到该BeanSentinelFeignClientProperties

Caused by: org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'reactiveConfigureRulesCustomizer' defined in class path resource [com/alibaba/cloud/circuitbreaker/sentinel/feign/SentinelFeignClientAutoConfiguration$ReactiveSentinelCustomizerConfiguration.class]: Unsatisfied dependency expressed through method 'reactiveConfigureRulesCustomizer' parameter 0; nested exception is org.springframework.beans.factory.NoSuchBeanDefinitionException: No qualifying bean of type 'com.alibaba.cloud.circuitbreaker.sentinel.feign.SentinelFeignClientProperties' available: expected at least 1 bean which qualifies as autowire candidate. Dependency annotations: {}
	at org.springframework.beans.factory.support.ConstructorResolver.createArgumentArray(ConstructorResolver.java:800)
	at org.springframework.beans.factory.support.ConstructorResolver.instantiateUsingFactoryMethod(ConstructorResolver.java:541)
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.instantiateUsingFactoryMethod(AbstractAutowireCapableBeanFactory.java:1352)
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:1195)
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:582)
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:542)
	at org.springframework.beans.factory.support.AbstractBeanFactory.lambda$doGetBean$0(AbstractBeanFactory.java:335)
	at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:234)
	at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:333)
	at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:208)
	at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:953)
	at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:918)
	at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:583)
	at org.springframework.boot.web.servlet.context.ServletWebServerApplicationContext.refresh(ServletWebServerApplicationContext.java:145)
	at org.springframework.boot.SpringApplication.refresh(SpringApplication.java:732)
	at org.springframework.boot.SpringApplication.refreshContext(SpringApplication.java:414)
	at org.springframework.boot.SpringApplication.run(SpringApplication.java:302)
	at org.springframework.boot.SpringApplication.run(SpringApplication.java:1303)
	at org.springframework.boot.SpringApplication.run(SpringApplication.java:1292)
	at com.ProviderApplication.main(ProviderApplication.java:22)
Caused by: org.springframework.beans.factory.NoSuchBeanDefinitionException: No qualifying bean of type 'com.alibaba.cloud.circuitbreaker.sentinel.feign.SentinelFeignClientProperties' available: expected at least 1 bean which qualifies as autowire candidate. Dependency annotations: {}
	at org.springframework.beans.factory.support.DefaultListableBeanFactory.raiseNoMatchingBeanFound(DefaultListableBeanFactory.java:1799)
	at org.springframework.beans.factory.support.DefaultListableBeanFactory.doResolveDependency(DefaultListableBeanFactory.java:1355)
	at org.springframework.beans.factory.support.DefaultListableBeanFactory.resolveDependency(DefaultListableBeanFactory.java:1309)
	at org.springframework.beans.factory.support.ConstructorResolver.resolveAutowiredArgument(ConstructorResolver.java:887)
	at org.springframework.beans.factory.support.ConstructorResolver.createArgumentArray(ConstructorResolver.java:791)
	... 19 more

3.4 解决方案

报错是因为没有找到SentinelFeignClientProperties , 因为该配置类会使SentinelFeignClientProperties注入spring容器,但是该类生效的条件是@ConditionalOnClass({ Feign.class, FeignClientFactoryBean.class })有feign的支持,所以引入如下依赖

加入Fegin的依赖后启动正常

    
    <dependency>
        <groupId>org.springframework.cloudgroupId>
        <artifactId>spring-cloud-starter-openfeignartifactId>
    dependency>

3.5 启动访问该服务任意节点,出发Sentinel监控

此时发现服务被检测到，但实时监控为空白。
查看Sentinel容器日志

docker logs -f sentinel

终端程序在运行中，并一直出现连接超时的错误级别日志

2023-09-25 07:56:56.107 ERROR 1 — [pool-2-thread-1] c.a.c.s.dashboard.metric.MetricFetcher : Failed to fetch metric from http://192.168.1.239:8719/metric?startTime=1695628477000&endTime=1695628483000&refetch=false> (ConnectionException: Connection timed out)

显然,本地可以访问sentinel,但是sentinel访问本地访问不通,导致的空白
这个192.168.1.239的ip是本地的ip，而Sentinel的服务是放在docker里，所以访问不了

解决方案如下:

1. sentinel 必须跟微服务处在同一个局域网中,也就是同时存在于本地或服务器中。

我的项目在本地,Sentinel在服务器中,找了很多方法(改了很多配置)要不就是控制台能显示,但是controller的资源显示不出来,
望各位有好的办法,评论或私信我,感谢

这里我先通过本地进行启动,处于同一个局域网

正常显示,并且资源也显示出来了

四、限流规则

4.1 簇点链路

• 项目内的调用链路，链路中被监控的每个接口就是一个 资源。默认情况下sentinel会监控SpringMVC的每一个端点（Endpoint），因此SpringMVC的每一个端点（Endpoint）就是调用链路中的一个资源。
• 流控、熔断等都是针对簇点链路中的资源来设置的。

4.2 流控模式

4.2.1 直接

统计当前资源的请求，触发阈值时对当前资源直接限流，也是默认的模式。

4.2.2 关联

统计与当前资源相关的另一个资源，触发阈值时，对当前资源限流。（满足下面条件：两个有竞争关系的资源；一个优先级较高，一个优先级较低[限流]）

场景:查询和修改操作会争抢数据库锁,产生竞争,优先更新业务,因此当修改订单业务触发阈值时,需要对查询订单业务限流
在那个进行设置呢,我们明白一点,那个资源限流在那个设置
当/consumer/update资源访问量,出发阈值时,就会对/consumer/{orderId}资源限流,避免影响更新业务

4.2.3 链路

统计从指定链路访问到本资源的请求，触发阈值时，对指定链路限流。（有查询订单和新增订单业务，两者都需要查询品牌。触发阈值时,针对从查询订单进入到查询品牌的请求设置限流）
都调用了service层的 consumerService.getBrand();查询品牌方法

    @GetMapping("query")
    public String queryOrder(){
        consumerService.getBrand();
        System.out.println("查询订单");
        return "查询成功";
    }

    @GetMapping("save")
    public String savebOrder(){
        consumerService.getBrand();
        System.out.println("新增订单");
        return "新增成功";
    }

默认controller资源被监控,service层资源没有被监控添加注解@SentinelResource

    @SentinelResource("brands")
    public String getBrand() {
        System.out.println("查询品牌");
        return "获取品牌";
    }

Sentinel默认会将Controller方法做context整合,导致链路模式的流控失效,需要配置yml,

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

这两个brands都是一个资源,因此点击那个都可以

4.3 流控效果

4.3.1 快速失败

达到阈值后，新的请求会被立即拒绝并抛出FlowException异常。是默认的处理方式。

4.3.2 warm up：预热模式

对超出阈值的请求同样是拒绝并抛出异常。但这种模式阈值会动态变化，从一个较小值逐渐增加到最大阈值,可以避免冷启动时高并发导致的服务宕机

4.3.3 排队等待

请求会进入队列,按照阈值允许的时间间隔一次执行请求,如果请求预期等待市场大于超时时间,直接拒绝

例如:Qps=5, 则1秒5个请求,那么200ms则处理一个请求,timeout=2000,意味着预期等待超过2000ms的请求会被拒绝,并抛出异常

4.4 热点参数限流

之前的限流是统计访问某个资源的所有请求，判断是否超过QPS阈值。而热点参数限流是分别统计参数值相同的请求，判断是否超过QPS阈值。

**热点参数限流对默认的SpringMVC资源无效。**添加@SentinelResource注解

    @GetMapping("{orderId}")
    @SentinelResource("hot")  //热点参数限流对默认的mvc资源无效,所以添加注解
    public Order queryOrder(@PathVariable("orderId") Long orderId) {
        // 根据id查询订单并返回
        return consumerService.queryOrderById(orderId);
    }

通过代码可以看到,接口参数只有一个, Long orderId所以堆hot这个资源的0号索引,也就是第一个参数做统计,每1秒相同参数的请求不超过5.高级配置中,配置例外的参数值阈值,

---

`

五、隔离和降级

虽然限流可以尽量避免因高并发而引起的服务故障，但服务还会因为其它原因而故障。而要将这些故障控制在一定范围，避免雪崩，就要靠线程隔离（舱壁模式）和熔断降级手段了。不管是线程隔离还是熔断降级，都是对客户端（调用方）的保护。

5.1 Feign整合Sentinel

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

1. 开启Feign的Sentinel功能

   feign:
     sentinel: 
       enabled: true   # 开启Feign的Sentinel功能

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

• FallbackClass,无法对远程调用的异常做处理
• FallbackFactory,可以对远程调用的异常做处理,我们使用这种

  @Slf4j
  @Component
  public class ProviderFallackFactory implements FallbackFactory<ProviderServeClient> {
      @Override
      public ProviderServeClient create(Throwable throwable) {
          //创建client接口实现类,实现其中方法,编写失败逻辑处理
          return new ProviderServeClient() {
              @Override
              public User queryById(Long id) {
                  log.error("查询失败:{}",throwable);
                  return new User();
              }
          };
      }
  }
  

2. 将FallbackFactory配置到FeignClient

   @FeignClient(value = "provider-server",fallbackFactory = ProviderFallackFactory.class)
   public interface ProviderServeClient {
   
       @GetMapping("/provider/{id}")
       User queryById(@PathVariable("id") Long id);
   
   }
   

测试
提供者中报错,但是进行降级,查询用户结果返回空对象,不影响服务消费者的正常执行

5.2 线程隔离

线程隔离有两种方式实现：

优点	缺点	场景
信号量隔离-Sentinel默认	轻量级，无额外开销	不支持主动超时 不支持异步调用 高频调用高扇出
线程池隔离	支持主动超时支持异步调用	线程的额外开销比较大 低扇出

• 信号量隔离的特点：基于计数器模式，简单，开销小。
• 线程池隔离的特点：基于线程池模式，有额外开销，但隔离控制更强。

• QPS: 就是每秒的请求数,
• 线程数: 是该资源能使用的tomcat线程数的最大值,也就是通过限制线程数量,实现仓壁模式

5.3 熔断和降级

熔断降级是解决雪崩问题的重要手段。其思路是由断路器统计服务调用的异常比例、慢请求比例，如果超出阈值则会熔断该服务。即拦截访问该服务的一切请求；而当服务恢复时，断路器会放行访问该服务的请求。

5.3.1 慢调用

业务的响应时长（RT)大于指定时长的请求认定为慢调用请求。在指定时间内，如果请求数量超过设定的最小数量，慢调用比例大于设定的阈值，则触发熔断。

表示:RT超过500ms的调用为慢调用,统计最近10000ms内的请求,如果请求量超过10次,并且慢调用比例不低于0.5,则处罚熔断,熔断时长为5秒.如果进入half-open状态,放行一次请求做测试.

5.3.2 异常比例或异常数

统计指定时间内的调用，如果调用次数超过指定请求数，并且出现异常的比例达到设定的比例阈值（或超过指定异常数），则触发熔断。

统计1000ms内的请求，如果请求量超过10测，并且异常比例不低于0.5，则触发熔断，熔断时长为5s，然后进入half-open状态，放行一次请求做测试