欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页

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

程序员文章站 2024-03-20 22:18:58
...

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都需要做熔断,可以对调用比较密集的服务做熔断,这样一是降低对服务方的压力,二是提高调用方的响应速度。