面试题:1和2都要回答sentinel
1.微服务中,如何应对高并发?

2.在众多微服务中,feign接口远程调用,如果失败了怎么办?如果A服务调用B服务失败了怎么办?
我们微服务当中用了保护微服务的手段,使用了sentinel。如果A服务调用了B服务失败了,可以走服务降级的方法。服务降级的方法是什么呢,我们可以给远程调用的这个方法,准备一个备用的方法。除了这个备用的方法之外,我们还可以设置线程隔离,如果服务A调用服务B出现问题了,阻塞的时间比较长怎么办呢?可以设定让A只准备两个线程,当好多请求过来的时候,只有两个请求去访问B,其余线程的请求,就直接去走服务降级的方法(即备用的方法),把备用方法的结果返回给用户。

降级:当服务A调用服务B失败了,就会调用之前设置好的降级的方法(即调用备用的方法)
线程隔离:当服务A调用服务B时,如果一次有10个请求,但是服务A设置了只能开启两个线程,那其 余8个线程就会去调用降级的方法。
熔断:当服务A调用服务B时,失败到一定次数时或者请求时间过长(慢调用比例到一定数量)或者异常数量到一定比例,会开启熔断,在熔断开启的时候,每一次的请求将直接调用降级的方法。在过一段时间后,熔断会变为半开状态(半开状态下会放开一个请求),如果此时A服务调用B服务(即放开的一个请求)正常,则一直正常下去(熔断状态变为关闭),如果还是不正常,失败或者请求时间过长,就会再次开启熔断状态。

3.sentinel的所有规则都是内存存储,重启后所有规则都会丢失。在生产环境下,我们必须确保这些规则的持久化,避免丢失
push模式:控制台将配置规则推送到远程配置中心,例如Nacos。Sentinel客户端监听Nacos,获取配置变更的推送消息,完成本地配置更新。(就是在nacos中把配置规则设置好,每次重启后都会自动会加载nacos中的配置,不需要再重新增加配置规则,实现配置规则持久化)

1.初识Sentinel

1.1.雪崩问题及解决方案

1.1.1.雪崩问题

什么是雪崩问题?

  • 微服务之间相互调用,因为调用链中的一个服务故障,引起整个链路都无法访问的情况。

微服务中,服务间调用关系错综复杂,一个微服务往往依赖于多个其它微服务。
如图,如果服务提供者I发生了故障,当前的应用的部分业务因为依赖于服务I,因此也会被阻塞。此时,其它不依赖于服务I的业务似乎不受影响。
但是,依赖服务I的业务请求被阻塞,用户不会得到响应,则tomcat的这个线程不会释放,于是越来越多的用户请求到来,越来越多的线程会阻塞:
服务器支持的线程和并发数有限,请求一直阻塞,会导致服务器资源耗尽,从而导致所有其它服务都不可用,那么当前服务也就不可用了。
那么,依赖于当前服务的其它服务随着时间的推移,最终也都会变的不可用,形成级联失败,雪崩就发生了。

解决雪崩问题的常见方式有四种:

1.1.2.超时处理

•超时处理:设定超时时间,请求超过一定时间没有响应就返回错误信息,不会无休止等待

1.1.3.仓壁模式(线程隔离)

我们可以限定每个业务能使用的线程数,避免耗尽整个tomcat的资源,因此也叫线程隔离

1.1.4.断路器

断路器模式:由断路器统计业务执行的异常比例,如果超出阈值则会熔断该业务,拦截访问该业务的一切请求。
断路器会统计访问某个服务的请求数量,异常比例。

1.1.5.限流

流量控制:限制业务访问的QPS,避免服务因流量的突增而故障。

1.1.6.总结

什么是雪崩问题?

  • 微服务之间相互调用,因为调用链中的一个服务故障,引起整个链路都无法访问的情况。

可以认为:
限流是对服务的保护,避免因瞬间高并发流量而导致服务故障,进而避免雪崩。是一种预防措施。
超时处理、线程隔离、降级熔断是在部分服务故障时,将故障控制在一定范围,避免雪崩。是一种补救措施。

1.2.服务保护技术对比

在SpringCloud当中支持多种服务保护技术:

  • Netfix Hystrix
  • Sentinel
  • Resilience4J
  • 早期比较流行的是Hystrix框架,但目前国内实用最广泛的还是阿里巴巴的Sentinel框架,这里我们做下对比:
Sentinel Hystrix
隔离策略 信号量隔离 线程池隔离/信号量隔离
熔断降级策略 基于慢调用比例或异常比例 基于失败比率
实时指标实现 滑动窗口 滑动窗口(基于 RxJava)
规则配置 支持多种数据源 支持多种数据源
扩展性 多个扩展点 插件的形式
基于注解的支持 支持 支持
限流 基于 QPS,支持基于调用关系的限流 有限的支持
流量整形 支持慢启动、匀速排队模式 不支持
系统自适应保护 支持 不支持
控制台 开箱即用,可配置规则、查看秒级监控、机器发现等 不完善
常见框架的适配 Servlet、Spring Cloud、Dubbo、gRPC 等 Servlet、Spring Cloud Netflix

2.流量控制

2.1.簇点链路

当请求进入微服务时,首先会访问DispatcherServlet,然后进入Controller、Service、Mapper,这样的一个调用链就叫做簇点链路。簇点链路中被监控的每一个接口就是一个资源
默认情况下sentinel会监控SpringMVC的每一个端点(Endpoint,也就是controller中的方法),因此SpringMVC的每一个端点(Endpoint)就是调用链路中的一个资源。
流控、熔断等都是针对簇点链路中的资源来设置的,因此我们可以点击对应资源后面的按钮来设置规则:

  • 流控:流量控制
  • 降级:降级熔断
  • 热点:热点参数限流,是限流的一种
  • 授权:请求的权限控制

    2.2.流控模式(三种)

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

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

  • 关联:统计与当前资源相关的另一个资源,触发阈值时,对当前资源限流
  • 链路:统计从指定链路访问到本资源的请求,触发阈值时,对指定链路限流

image.png
关联模式:语法说明:当/write资源访问量触发阈值时,就会对/read资源限流,避免影响/write资源。
链路模式:只针对从指定链路访问到本资源的请求做统计,判断是否超过阈值。
image.pngimage.png

2.2.3.总结

流控模式有哪些?
•直接:对当前资源限流
•关联:高优先级资源触发阈值,对低优先级资源限流。
•链路:阈值统计时,只统计从指定资源进入当前资源的请求,是对请求来源的限流

2.3.流控效果(三种)

在流控的高级选项中,还有一个流控效果选项:image.png流控效果是指请求达到流控阈值时应该采取的措施,包括三种:

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

image.pngimage.png

2.3.3.总结

流控效果有哪些?

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

    2.4.热点参数限流

    sentinel不仅可以针对路径资源进行限流,也可以针对路径上的参数进行限流。
    单独把热门商品的线程访问量增加,比如把冷门商品(比如id=2)设置为每秒100的访问量,把热门商品(id=1)设置为每秒1000的访问量。
    之前的限流是统计访问某个资源的所有请求,判断是否超过QPS阈值。而热点参数限流是分别统计参数值相同的请求,判断是否超过QPS阈值。
    注意事项:热点参数限流对默认的SpringMVC资源无效,需要利用@SentinelResource注解标记资源
    在实际开发中,可能部分商品是热点商品,例如秒杀商品,我们希望这部分商品的QPS限制与其它商品不一样,高一些。那就需要配置热点参数限流的高级选项了:

image.png

3.隔离和降级

限流是一种预防措施,虽然限流可以尽量避免因高并发而引起的服务故障,但服务还会因为其它原因而故障。
而要将这些故障控制在一定范围,避免雪崩,就要靠线程隔离(舱壁模式)和熔断降级手段了。
线程隔离之前讲到过:调用者在调用服务提供者时,给每个调用的请求分配独立线程池,出现故障时,最多消耗这个线程池内资源,避免把调用者的所有资源耗尽。
熔断降级:是在调用方这边加入断路器,统计对服务提供者的调用,如果调用的失败比例过高,则熔断该业务,不允许访问该服务的提供者了。

可以看到,不管是线程隔离还是熔断降级,都是对客户端(调用方)的保护。需要在调用方 发起远程调用时做线程隔离、或者服务熔断。
而我们的微服务远程调用都是基于Feign来完成的,因此我们需要将Feign与Sentinel整合,在Feign里面实现线程隔离和服务熔断。

3.1.3.总结

Sentinel支持的雪崩解决方案:

  • 线程隔离(仓壁模式)
  • 降级熔断

Feign整合Sentinel的步骤:

  • 在application.yml中配置:feign.sentienl.enable=true
  • 给FeignClient编写FallbackFactory并注册为Bean
  • 将FallbackFactory配置到FeignClient

    3.2.线程隔离(舱壁模式)

    3.2.1.线程隔离的实现方式

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

  • 线程池隔离

  • 信号量隔离(Sentinel默认采用)

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

3.2.2.sentinel的线程隔离

用法说明
在添加限流规则时,可以选择两种阈值类型:image.png

  • QPS:就是每秒的请求数,在快速入门中已经演示过
  • 线程数:是该资源能使用用的tomcat线程数的最大值。也就是通过限制线程数量,实现线程隔离(舱壁模式)。

    3.2.3.总结

    线程隔离的两种手段是?

  • 信号量隔离

  • 线程池隔离

信号量隔离的特点是?

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

线程池隔离的特点是?

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

    3.3.熔断降级

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

  • closed:关闭状态,断路器放行所有请求,并开始统计异常比例、慢请求比例。超过阈值则切换到open状态

  • open:打开状态,服务调用被熔断,访问被熔断服务的请求会被拒绝,快速失败,直接走降级逻辑。Open状态5秒后会进入half-open状态
  • half-open:半开状态,放行一次请求,根据执行结果来判断接下来的操作。
    • 请求成功:则切换到closed状态
    • 请求失败:则切换到open状态

断路器熔断策略有三种:慢调用、异常比例、异常数
image.png
慢调用:业务的响应时长(RT)大于指定时长的请求认定为慢调用请求。在指定时间内,如果请求数量超过设定的最小数量,慢调用比例大于设定的阈值,则触发熔断
异常比例或异常数:统计指定时间内的调用,如果调用次数超过指定请求数,并且出现异常的比例达到设定的比例阈值(或超过指定异常数),则触发熔断。

4.授权规则

授权规则可以对请求方来源做判断和控制。

4.1.授权规则

4.1.1.基本规则

授权规则可以对调用方的来源做控制,有白名单和黑名单两种方式。

  • 白名单:来源(origin)在白名单内的调用者允许访问
  • 黑名单:来源(origin)在黑名单内的调用者不允许访问

    4.2.自定义异常结果

    默认情况下,发生限流、降级、授权拦截时,都会抛出异常到调用方。异常结果都是flow limmiting(限流)。这样不够友好,无法得知是限流还是降级还是授权拦截。

image.png

5.规则持久化

sentinel的所有规则都是内存存储,重启后所有规则都会丢失。在生产环境下,我们必须确保这些规则的持久化,避免丢失。

push模式:控制台将配置规则推送到远程配置中心,例如Nacos。Sentinel客户端监听Nacos,获取配置变更的推送消息,完成本地配置更新。(就是在nacos中把配置规则设置好,每次重启后都会自动会加载nacos中的配置,不需要再重新增加配置规则,实现配置规则持久化)