微服务10-Sentinel中的隔离和降级

回顾

我们的限流——>目的：在并发请求的情况下服务出现故障，避免因为服务故障的出现而导致级联失败；所以说限流也就是对服务故障的一种预防措施

降级和隔离

回顾雪崩：

比如说服务之间的依赖，当服务C出问题而导致服务A调用不了时，如果大量请求涌入A服务调用C服务，此时会导致服务A中的资源被大量占用——>导致服务A宕机；

解决——>我们采用线程隔离（舱壁模式），将服务A中的业务进行隔离，每一个业务分配线程池，比如说我请求A需要用到C服务，那么就只能占用服务A里其中C的线程池，在这个线程池里使用里面的线程，如果请求数>x里面能够使用的线程数，就会拒绝服务，防止服务A因为服务C的故障而导致宕机，但是还是资源损耗了一部分；

熔断降级：当失败服务到达一定百分比就开始拒绝；

都是对服务的调用者进行保护——>而服务的调用用到了Feign，所以我们需要整合Feign与Sentinel来实现服务调用者的保护

1.Feign整合Sentinel来完成降级

FeignClient服务调用失败后，我们可以利用FallbackClass或者FallbackFactory完成对远程服务的异常处理（降级处理）；

流程：

1.首先yaml编写配置，打开Sentinel为true

2.然后编写一个FallbackFactory的实现类，对远程调用出现异常进行降级处理

@Slf4j
//实现FallbackFactory：定义服务（userclient）调用失败后的降级措施
public class UserClientFallbackFactory implements FallbackFactory<UserClient> {
    @Override
    public UserClient create(Throwable throwable) {
       return new UserClient() {
           @Override
           public User findById(Long id) {
               //定义降级措施
               log.error("查询用户异常",throwable);
               return new User();
           }
       };
    }
}

3.将FallbackFactory实现类注入容器中
在config中加入

 @Bean
    public UserClientFallbackFactory userClientFallbackFactory(){
       return new UserClientFallbackFactory(); 
    } 

Feign的请求路径，由order服务调用

1.2总结

2.线程隔离两种实现方式的区别

线程池隔离：

支持主动超时，和异步调用，因为我们的服务调用每个请求用的都是独立的线程（因为隔离了嘛），所以不同服务调用之间是异步的，有利于增加效率

与此同时，因为线程池大量开销——>因为线程之间的上下文切换会导致消耗资源较大；

场景：低扇出，服务调用大量其他服务

信号量隔离：

轻量级，用的是一个类似于Semaphore的计数器，当计数器为0，就拒绝请求，没有额外的线程开销；

但是他不支持主动超时与异步调用，因为没有独立服务的独立线程嘛；

场景：高扇出，网关进行转发，Sentinel

3.线程隔离中的舱壁模式

QPS：限流，每s的请求数

线程数：tomcat给该资源分配最大的线程值 （直接选择资源的线程数就行，我猜测是默认给你资源写了一个线程池，然后指定里面线程数即可）

1.瞬间发送十个请求

2.这里结果为null是因为之前降级策略

像这种，是喊流量的控制，对于请求的控制——>流控模式：对于客户端请求过来的的一个限流

流控效果：强调的是请求上来了，我们服务器回应的一个效果

3.2总结

4.熔断降级

这里我们需要注意几个点：

1.熔断降级三种状态——closed（可以进行访问）、open（失败，进行熔断）、Half-open（尝试打开）

2.closed——open，当达到阈值才会变，达到open之后，会有一个熔断时间（也就是拒绝时间），当这个时间一个过，就会尝试放行一次，也就是Half-Open（这里会再次判断，根据新来的请求是不是失败的）——>判断是进Open还是closed

配置的完整含义：​​​​​​

当前资源请求100s内来10次，响应时间（最大RT）如果>5s，并且有一半以上请求都是这样，就会进入5s的熔断；

案例：

5.熔断策略（根据异常比例或者异常数）

新增一个异常比例的降级策略