更多SpringCloud组件学习

Hystrix Github

它是什么？

   Hystrix 是一个库，通过隔离服务之间的访问点，停止级联失败和提供回退选项等来提高微服务系统的高可用性。

   通俗的讲，Hystrix 是用来解决相互依赖调用的服务之间，不会因某一环节出现问题，而浪费相关的资源，进而导致整个系统无法响应的问题。

可以做什么？

服务降级的触发，有运行时异常、超时、线程池等饱和情况，一般放在消费方配置比较合理

消费方配合 @FeignClient ，使用在接口上，解耦降级方法

熔断流程：降级方法执行 --》 熔断拒绝访问 --》 感知恢复服务

开启断路器后的执行流程：

  开启断路器后，在一个滑动窗口期内，requestVolumeThreshold 次请求，请求失败率达到errorThreshold 时，进入长为 sleepWindow 的睡眠窗口期（该时间段内所有请求都会直接走对应的降级方法），睡眠窗口期结束后尝试请求，决定是否关闭断路器

Hystrix 配置参数解析

所有配置参数均在类 HystrixCommandProperties 中配置了默认值。

hystrix 执行流程图：

官方文档

是什么？

   它是分布式系统的流量防卫兵，以流量为切入点，从流量控制、熔断降级、系统负载保护等多个维度保护多个服务的稳定性。

相比与 Hystrix 的优势：

   Hystrix 中对流量控制、熔断降级等服务需要去代码中配置，Web 监控界面无法管理。Sentinel 的管理界面完善了这些问题，让使用、管理更加方便。

Sentinel 分为两个部分:

控制台 流量控制 名称解释：

资源名：唯一名称，请求路径

流控应用：可以对调用者进行限流，填写微服务名，默认default（即不区分来源）

阈值类型/单机阈值： QPS：每秒请求数量，当超过该值时进行限流 线程数：当调用该 api 的线程数到达该阈值时，进行限流。（当所有线程都在工作，没有空闲线程时，线程数才会增加）

流控模式： 直接：api 达到限流条件时，直接限流 关联：当关联的 API 资源 A 达到限流值时，就限流自己 R，不会限流 A。（如支付接口达到限流条件时，限流下单接口） 链路：只记录配置的入口资源，到流控；其他入口不计入流控规则中。(暂时没实验成功？？？？？？？？？)

流控效果： 快速失败：达到限流规则后，直接抛出 FlowException。适用于对系统处理能力确切已知的情况下。 Warm up：让通过的流量缓慢增加，在一定时间内逐渐增加到阈值上限，给冷系统一个预热的时间。默认 coldFactor 为 3，即请求 QPS 从 threshold / 3 开始，经预热时长逐渐升至设定的 QPS 阈值 匀速排队：严格控制请求通过的间隔时间，即让请求按设置的 QPS 值，以均匀的速度通过。

  除了流量控制以外，对调用链路中不稳定的资源进行熔断降级也是保障高可用的重要措施之一。

降级策略：

RT 平均响应时长：当 1s 内持续进入 N 个请求，其平均响应时间超过阈值，触发熔断，在接下来的时间窗口中执行降级方法。

异常比例：当资源的每秒请求量 >= N（可配置），并且每秒异常总数与通过量的比值超过阈值之后，触发熔断。

异常数：当资源近 1 分钟的异常数目超过阈值之后会进行熔断。注意由于统计时间窗口是分钟级别的，若 timeWindow 小于 60s，则结束熔断状态后仍可能再进入熔断状态(即时间窗口的配置需要大于 60 s)。

解释：

该图表示在时间窗口2s内，对该资源的指定 参数索引 访问量超过 阈值 后，触发该资源对应的熔断，但当该参数值为2时，其对应的阈值为200。

热点参数限流会对设置的参数索引或包含该索引的请求进行限流。

参数例外项是为了实现 当参数是某个特殊值时，它的限流值和普通限流阈值不一样。

  系统自适应限流是从整体维度对应用入口流量进行控制，追求的目标是 在系统不被拖垮的情况下，提高系统的吞吐率，而不是 load 一定要到低于某个阈值，因为阈值的设置，会有延迟的特性，无法取得很好的效果。

  从图中可以知道， blockHandler 对应处理 BlockException 类型的异常，即 sentinel 控制台配置规则的违规情况；fallback 处理抛出异常的时候提供 fallback 处理逻辑，即业务代码运行时的异常情况。

该种限流方法，业务代码和阻塞逻辑在同一个类种，带来的问题有：

为了解决该问题，可以选用如下的方式指定 blockHandler 的处理。

结论：   超过 dashboard 的流控规则后，同一时间窗口的请求会进入到 blockHandler 指定的方法中

  业务异常降级方法的指定，编码和上面的一致，只是 blockHandler 修改为 fallback 。

结论：   超过 dashboard 的降级规则后，触发异常的请求进入到 fallback 指定的方法中；正常的访问请求，也会进入到 fallback 指定的方法中

结论：   dashboard 中不指定流控规则，只指定降级规则情况下，当超过流控规则后，所有的请求都会进入到 blockHandler 指定的方法中

  用于指定哪些异常被排除掉，不会计入异常统计中，也不会进入 fallback 逻辑中，而是会原样抛出。

为什么需要？

  Dashboard 的推送规则方式是通过 API 将规则推送至，客户端并直接更新到内存中，所以应用重启，对应的规则就会消失。

选用什么方式完成持久化？

  为实现规则更新后，能够被客户端及时感知到，采用规则中心统一推送，客户端通过注册监听器的方式时刻监听变化。   规则中心可以使用 Nacos、Zookeeper 、自研等数据源。