微服务-Sentinel

目录

 

     背景

     Sentinel使用

      Sentinel控制台

      Sentinel控制规则

     Sentinel整合OpenFeign

---

  

     背景

        在微服务项目架构中，存在多个服务相互调用场景，在某些情况下某个微服务不可用时，上游调用者若一直等待，会产生资源的消耗，极端情况下会影响整个应用，如下图：

        在高并发的场景下，由于A服务不可用，导致B调用A一直等待，迟迟不能释放资源，进而导致B服务不可用，进而导致CD服务不可用，最终整个项目服务不可用，产生了服务崩塌。Sentinel可以解决上述问题，它在服务流量控制、熔断等方面有很好的解决方案。

        Sentinel常用的使用场景如下：
        1、秒杀场景：限流防止瞬时流量冲击。

        2、服务熔断与降级：当服务不可用时，快速失败，避免级联故障。

        3、系统保护：预防由于高负载引发的系统崩溃。

     Sentinel使用

      Sentinel控制台

        Sentinel 控制台是一个独立应用，用于可视化的监控和管理，它可以直接运行可执行的jar，项目使用的jar版本是：sentinel-dashboard-1.8.8，直接运行:java -jar sentinel-dashboard-1.8.8.jar

运行后访问：http://localhost:8080/#/login   sentinel/sentinel登录

      Sentinel控制规则

        Sentinel控制规则很多，包括：流控规则、熔断规则、热点规则、系统规则、授权规则，本文重点介绍流控规则、熔断规则。项目配置步骤如下：

        1、项目添加对Sentinel的依赖

        2、项目配置Sentinel

        3、服务接口编写及简单测试

        简单写了一个后台数据库查询接口，查询id=1的用户信息

        4、Sentinel控制台配置流控规则

        对上述服务接口，配置了每秒请求数不能超过1的流控规则，超过后，直接返回调用失败，浏览器快速请求后，会出现如下效果（流控规则已生效）：

        流控规则配置说明如下：

        资源名：资源名是需要限流的唯一标识，可以是方法名、API请求路径等。通过资源名，Sentinel能够对流量进行管理与控制。

        针对来源：针对特定的调用方进行限流。例如，服务A调用服务B时，可以针对服务A的调用进行限流。默认为 default，表示不区分调用来源。

        QPS（每秒请求数）：如果某个资源的每秒请求数超过设定的阈值，则会触发限流。

        线程数：当访问该资源的并发线程数达到设定的阈值时，触发限流。

        是否集群：如果不需要集群模式限流，默认选择“不需要集群”。否则，可以开启集群限流。

        流控模式-直接限流：一旦达到阈值，直接限流当前的请求。

        流控模式-关联限流：当关联的其他资源达到限流条件时，限流当前的资源。比如/resourceA达到阈值时，/resourceB也被限流。

        流控模式-链路限流：对入口资源进行链路限流，限制从指定入口进入的资源访问。当链路上的访问量达到阈值时，限制链路上的流量，常用于链路保护。

        流控效果-快速失败：当达到限流条件时，直接抛出异常，返回失败结果。

        流控效果-Warm Up（预热）：在一段时间内，逐步增加允许通过的流量，直至达到设定的 QPS 阈值。适合应用在高峰期流量突增的场景。

        流控效果-排队等待：请求不会立即失败，而是进入排队状态，匀速通过。适用于平滑处理请求的场景，类似于“漏斗效应”。阈值类型必须为 QPS，否则无效。

        如果需要手工处理限流或者降级的逻辑，不直接演示生硬的【Blocked by Sentinel (flow limiting)】信息，可以通过@SentinelResource 解决，参考代码如下：

        blockHandler：处理限流或降级时的逻辑，方法名必须是 public，返回类型与原方法一致，且参数类型需要与原方法匹配，方法最后要加上 BlockException 参数。可以处理流控、熔断等情况触发的 BlockException。

        5、Sentinel控制台配置熔断规则

        Sentinel 的熔断规则主要分为三种策略，慢调用比例、异常比例和异常数，这些策略用于保护服务免于过载或连续的失败。

        慢调用比例 ：该策略会根据请求响应的时间来判断是否进行熔断，适合用于防止因某些请求响应过慢而拖垮整个系统。

        最大RT（Response Time）：表示系统中允许的最大响应时间，如果一个请求的响应时间超过这个设定值，就会被判定为慢调用。

        最小请求数目：在统计周期内，只有请求数超过设定的最小请求数，才会触发熔断逻辑。

        熔断条件：当单位时间内内的慢调用比例超过设定的阈值时，触发熔断，进入熔断状态。

        恢复机制：在熔断时长过后，进入半开状态，如果后续请求正常则关闭熔断器，如果再发生慢调用则继续熔断。
        
        异常比例：该策略会根据异常的比例来判断是否进行熔断，适合用于当请求的失败率突然增加时，自动进行保护。

        最小请求数目：同样需要单位时间内的请求数达到设定的最小值，才会计算异常比例。

        熔断条件：当单位时间内内的异常比例大于设定的阈值时，触发熔断，进入熔断状态。

        恢复机制：在熔断时长过后，进入半开状态，如果后续请求成功，则关闭熔断器，否则继续熔断。
        异常数：该策略根据单位时间内的异常数量来判断是否熔断，适合用于系统中发生大量异常时的保护机制。

        下方以异常数熔断规则举例：

        后台模拟异常

        异常数熔断规则配置：

        在10秒时间内，最小请求大于5，接口出现10次异常后，接口服务熔断不可用

        jemter多线程请求测试：

        启动jemter任务，然后在浏览器请求：http://localhost:8088/blogUser/simulateException 显示接口服务已熔断。

        当关闭jemter测试任务后，再次请求  http://localhost:8088/blogUser/simulateException 后，服务接口恢复。

     Sentinel整合OpenFeign

        Sentinel整合OpenFeign步骤如下：

        1、增加配置信息

        2、对feign接口增加服务降级的逻辑

        3、测试调用

        在blog-content服务正常可用时，调用http://localhost:8088/blogUser/simulate 时，系统返回后台数据信息；当关闭blog-content服务时，控制台显示【BlogContent 服务降级】