SpringCloud微服务项目实战 - 限流、熔断、降级处理

我们知道,在分布式微服务项目体系中,一个系统是由若干个子服务模块组成,这若干个子服务相互调用协同工作,对外输出服务使得整个系统运作。

由于服务之间的相互协作调用,所以要保证整个系统完整运行,就得保证每个服务模块运行良好。但在实际庞大的分布式体系中,我们难免遇到某个服务阻塞或挂起等情况。假设客户在下单时,需要调用订单服务的接口,而订单服务有依赖了客户服务、商品服务、库存服务等,在下单时如果依赖的某个服务发生异常(请求超时),所有的请求就阻塞在这个依赖服务上,则会造成整个下单接口调用失败。就会导致整个系统下单不可用甚至雪崩,那这种问题如何解决呢?这将是我们文章里今天要讨论的话题。

在SpringCloud分布式项目中,为了保证服务的高可用,Netflix的组件Hystrix可以将这些请求隔离,针对服务限流,当某个服务不可用时能够熔断并降级,防止级联故障。

什么是Hystrix?

Hystrix中文翻译 豪猪,由于其背上长满了棘刺,从而拥有自我保护的能力。Hystrix作为Netflix开源的一款容错框架,同样具有自我保护能力。

它是一个用于处理分布式系统的延迟和容错的开源库, 在分布式系统中,许多不可避免的服务调用失败, 如超时/异常等。Hystrix 能够保证在一个依赖出现问题的情况下,不会导致整体系统服务的失败、避免级联故障、提高系统的弹性。

"断路器" 本身是一种开关装置,当有服务发生故障后,通过断路器的故障监控(类似保险熔断),向调用方返回一个符合预期的、可处理的备选响应(FallBack) ,而不是等待/超时或抛出异常,这样就保证了服务调用方的线程不会长时间,不必要地占用,从而避免了故障在分布式系统无线的蔓延,防止了雪崩效应的发生。

为了实现容错和自我保护,我们先看一下Hystrix的设计和实现。

Hystrix设计目标:

  • 对来自依赖的延迟和故障进行防护和控制——这些依赖通常都是通过网络访问的

  • 阻止故障的连锁反应

  • 快速失败并迅速恢复

  • 回退并优雅降级

  • 提供近实时的监控与告警

Hystrix遵循的设计原则:

  • 防止任何单独的依赖耗尽资源(线程)

  • 过载立即切断并快速失败,防止排队

  • 尽可能提供回退以保护用户免受故障

  • 使用隔离技术(例如隔板,泳道和断路器模式)来限制任何一个依赖的影响

  • 通过近实时的指标,监控和告警,确保故障被及时发现

  • 通过动态修改配置属性,确保故障及时恢复

  • 防止整个依赖客户端执行失败,而不仅仅是网络通信

Hystrix实现限流熔断降级

1,通过Command实现

首先添加Hystrix的pom依赖:

配置Hystrix属性(yml文件):

# Hystrix 默认加载的配置文件 - 限流、 熔断
hystrix:
  # 线程池大小
  threadpool:
    default:
      coreSize: 1
      maxQueueSize: 200
      queueSizeRejectionThreshold: 2


    # 限流策略
    #如果没有定义HystrixThreadPoolKey,HystrixThreadPoolKey会默认定义为HystrixCommandGroupKey的值
    userGroup:
      coreSize: 1
      maxQueueSize: -1
      queueSizeRejectionThreshold:  800


    userThreadPool:
      coreSize: 1
      maxQueueSize: -1
      queueSizeRejectionThreshold:  800


# 执行策略
# 资源隔离模式,默认thread。还有一种叫信号量
  command:
    default:
      execution:
        isolation:
          strategy: THREAD
        # 是否打开超时
        timeout:
          enabled:  true
        # 超时时间,默认1000毫秒
        isolation:
          thread:
            timeoutInMilliseconds:  15000
            # 超时时中断线程
            interruptOnTimeout: true
            # 取消时候中断线程
            interruptOnFutureCancel: false
            # 信号量模式下,最大并发量
          semaphore:
            maxConcurrentRequests:  2
      # 降级策略
      # 是否开启服务降级
      fallback:
        enabled:  true
        # fallback执行并发量
        isolation:
          semaphore:
            maxConcurrentRequests:  100
      # 熔断策略
      # 启用/禁用熔断机制
      circuitBreaker:
        enabled:  true
        # 强制开启熔断
        forceOpen:  false
        # 强制关闭熔断
        forceClosed:  false
        # 前提条件,一定时间内发起一定数量的请求。也就是5秒钟内(这个5秒对应下面的滚动窗口长度)至少请求4次,熔断器才发挥起作用。默认20
        requestVolumeThreshold: 4
        # 错误百分比。达到或超过这个百分比,熔断器打开。比如:5秒内有4个请求,2个请求超时或者失败,就会自动开启熔断
        errorThresholdPercentage: 50
        # 10秒后,进入半打开状态(熔断开启,间隔一段时间后,会让一部分的命令去请求服务提供者,如果结果依旧是失败,则又会进入熔断状态,如果成功,就关闭熔断)。默认5秒
        sleepWindowInMilliseconds:  10000


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


      # 设置是否缓存请求,request-scope内缓存
      requestCache:
        enabled:  false
      # 设置HystrixCommand执行和事件是否打印到HystrixRequestLog中
      equestLog:
          enabled:  false
          
  userCommandKey:
    execution:
      isolation:
        thread:
          timeoutInMilliseconds: 5000

编写Command类:

在服务提供者中写调用的接口:

在当前服务中添加接口:

这里HystrixCommand的每次都必须使用新的对象(保证每次请求都是一个新的线程)调用其execute方法,而不能使用单例。否则会提示

Thisinstance can only be executed once.Please instantiate a new instance.

服务降级

请求order-service的/order/exception接口,因为customer-service的/customer/exception会随机抛出运行时异常。当服务异常时,将返回“服务已降级,暂不可用”,而服务正常时将返回ok。这说明我们的服务因为异常降级。

请求/order/timeout接口时,“服务已降级,暂不可用”。如果修改hystrix.command.userCommandKey.execution.isolation.thread.timeoutInMilliseconds=10000,Hstrix限制的超时时间大于接口的返回时长,就能成功返回ok。这个例子说明服务因为请求超时降级了。

服务限流

在分布式环境中,每个服务模块的请求承载量是有限的,因此为保证服务正常,我们会限制来自客户端请求的并发数。可以通过semaphore.maxConcurrentRequests.coreSize.maxQueueSize和queueSizeRejectionThreshold设置信号量模式下的最大并发量、线程池大小、缓冲区大小和缓冲区降级阈值。在示例中我们作如下设置

  • #不设置缓冲区,当请求数超过coreSize时直接降级

  • hystrix.threadpool.userThreadPool.maxQueueSize=-1

  • #超时时间大于我们的timeout接口返回时间

  • hystrix.command.userCommandKey.execution.isolation.thread.timeoutInMilliseconds=10000

这个时候当连续多次请求/order/timeout接口,在第一个请求还没有成功返回时,查看输出日志可以发现只有第一个请求正常的进入到order-service的接口中,其它请求会直接返回降级信息。这样我们就实现了对服务请求的限流。

服务熔断

在yml配置中开启熔断,并且以5秒为度量周期,当5秒内请求超过4个错误超过50%时,就会开启熔断器,所有的请求都会直接降级,如果5秒内的请求不够4个,就算有三个请求且全部失败也不会开启熔断器。10秒后熔断器进入半打开状态会让一部分请求向服务端发起调用,如果成功关闭熔断器,否则再次进入熔断状态。

我们对order-serivce的/order/exception连续发起请求(5秒内至少4次),当我们的请求异常超过50%时,服务会直接返回降级信息。
实际上当服务异常、超时、宕机并满足熔断条件时,都会开启熔断。

2,通过FeignClient集成实现

前面通过Command要对每个接口写command类,很是麻烦,但使用Hystrix和Feign的集成就十分方便了。需要在启动类中添加注解@EnableCircuitBreaker启用熔断机制。

添加Feign客户端和降级类

降级类:

再在Controller添加接口:

今天要说的就讲到这里,我们下一篇继续讲SpringCloud微服务项目实战。代码我也讲上传到github,请注意后续动态。

推荐阅读:

SpringCloud微服务项目实战 -  API网关Gateway详解实现

SpringCloud微服务项目实战 - 网关zuul详解及搭建

SpringCloud微服务项目实战 - 微服务调用详解(附面试题)

SpringCloud微服务项目实战,服务注册与发现(附面试题)

Spring Cloud微服务项目实战--Eureka服务搭建



扫码关注公众号,发送关键词获取相关资料:发“Springboot”领取电商项目实战源码;发“SpringCloud”领取学习实战资料;

©️2020 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页