SpringCloud微服务之实现Hystrix熔断、降级

SpringCloud微服务之实现Hystrix熔断、降级

从2020年就开始在公司做微服务的项目了，还没写过这方面的一些博客。今天就将一些技术点搞到这里吧。此博客主要是通过配置进行进行展开。话不多说，上菜。。。

# Hystrix 默认加载的配置文件 - 限流、 熔断示例
hystrix:
  threadpool:  # 线程池
    userGroup:  # 限流策略
      coreSize: 1  #如果没有定义HystrixThreadPoolKey，HystrixThreadPoolKey会默认定义为HystrixCommandGroupKey的值
      maxQueueSize: -1
      queueSizeRejectionThreshold: 800
    userThreadPool:
      coreSize: 1
      maxQueueSize: -1   #不设置缓冲区，当请求数超过coreSize时直接降级
      queueSizeRejectionThreshold: 800
    default:
      coreSize: 1  # 线程池大小
      maxQueueSize: 200  # 缓冲区大小， 如果为-1，则不缓冲，直接进行降级 fallback
      queueSizeRejectionThreshold: 2  # 缓冲区大小超限的阈值，超限就直接降级
  command:
    userCommandKey:
      execution:
        isolation:
          thread:
            timeoutInMilliseconds: 5000 #超时时间大于我们的timeout接口返回时间
    default:
      execution:  # 执行策略
        isolation:
          strategy: THREAD  # 资源隔离模式，默认thread。还有一种叫信号量
          thread:
            timeoutInMilliseconds: 15000  # 超时时间，默认1000毫秒
            interruptOnTimeout: true   # 超时时中断线程
            interruptOnFutureCancel: false    # 取消时候中断线程
          semaphore:
            maxConcurrentRequests: 2   # 信号量模式下，最大并发量
        timeout:
          enabled: true  # 是否打开超时

      fallback: # 降级策略
        enabled: true   # 是否开启服务降级
        isolation:
          semaphore:
            maxConcurrentRequests: 100  # fallback执行并发量

      circuitBreaker: # 熔断策略
        enabled: true  # 启用/禁用熔断机制
        forceOpen: false # 强制开启熔断
        forceClosed: false  # 强制关闭熔断
        requestVolumeThreshold: 4  # 前提条件，一定时间内发起一定数量的请求。  也就是5秒钟内(这个5秒对应下面的滚动窗口长度)至少请求4次，熔断器才发挥起作用。  默认20
        errorThresholdPercentage: 50   # 错误百分比。达到或超过这个百分比，熔断器打开。  比如：5秒内有4个请求，2个请求超时或者失败，就会自动开启熔断
        sleepWindowInMilliseconds: 10000   # 10秒后，进入半打开状态（熔断开启，间隔一段时间后，会让一部分的命令去请求服务提供者，如果结果依旧是失败，则又会进入熔断状态，如果成功，就关闭熔断）。 默认5秒

      metrics:  # 度量策略
        rollingStats:
          timeInMilliseconds: 5000  # 5秒为一次统计周期，术语描述：滚动窗口的长度为5秒
          numBuckets: 10  # 统计周期内 度量桶的数量，必须被timeInMilliseconds整除。作用：
        rollingPercentile:
          enabled: true  # 是否收集执行时间，并计算各个时间段的百分比
          timeInMilliseconds: 60000  # 设置执行时间统计周期为多久，用来计算百分比
          numBuckets: 6  # 执行时间统计周期内，度量桶的数量
          bucketSize: 100  # 执行时间统计周期内，每个度量桶最多统计多少条记录。设置为50，有100次请求，则只会统计最近的10次
        healthSnapshot:
          intervalInMilliseconds: 500  # 数据取样时间间隔

      requestCache:
        enabled: false  # 设置是否缓存请求，request-scope内缓存
      requestLog:
        enabled: false  # 设置HystrixCommand执行和事件是否打印到HystrixRequestLog中

配置搞好了。那么，问题来了，熔断机制是怎么产生的呢？
如果是涉及到RPC调用的接口，我们无法保证被调用方不出错或者不超时，此时是可以使用熔断机制的。但是在我们日常开发中，很多接口的逻辑是服务自身完成的，这部分我们是可以自己做保证的，此时就不需要我们去做熔断机制了。而且，也并非所有的RPC都需要做熔断，可以对调用比较密集的服务做熔断，这样一是降低对服务方的压力，二是提高调用方的响应速度。