微服务中的熔断、降级与限流

概念

降级

先说说什么是降级,熔断和限流都要配合降级,降级通俗来讲就是Plan B,即当Plan A执行失败的时候,需要如何处理.可以直接返回失败,也可以转而调用另一个服务.

熔断

系统调用某个服务失败或者某种状态达到阈值的时候,自发的一种保护行为,通过限制调用端调用来实现.例如某个服务需要调用算法服务,算法服务总是返回错误时候,就需要限制对算法端的调用,以保护其他资源不被浪费

限流

限流是指在调用某个服务的时候,出于对系统的保护,按照某个业务维度的值统计达到阈值之后,进行的降级操作.

实现思想

• 不管是Spring 微服务生态的解决方案还是K8s的(Istio)方案,核心本质是代理.
• 熔断和限流都需要有个平面来统计,就限制了不能有client本身触发,因此采用代理来实现

熔断实现

• Hystirx框架下,本质上使用代理将客户端封装,封装后,在封装的位置实现统计与降级

  Hystirx隔离策略

  • 线程池:默认使用线程隔离策略,直接在线程池中获取新的线程来执行RPC.
    缺点:增加计算开销,每个rpc都会被独立的线程执行.
    适用于依赖网络访问的请求,只依赖内存缓存的情况下(线程级缓存)

  • 信号量:在调用线程中执行,通过信号量进行隔离.适用于只依赖内存缓存且不涉及网络访问.

• 熔断器参数

  • requestVolumeThreshold滑动窗口大小,默认20
  • errorThresholdPercentage错误率, 默认50%
  • sleepWindowInMilliseconds熔断生效时间,默认5000:5s

限流实现

• 1、HyStrix中

  • 线程隔离时,线程数+排队队列大小
  • 信号量隔离时,最大并发数限流

  2、并发数量

  • QPS、并发连接数

  3、总量

  • 业务层中,限制某个资源量的总量

  限流算法:

  1、限制速率: 漏桶算法

  2、限制总数: **令牌桶算法 ** 限制某个业务资源的count值,允许短时间突发

• 异步RPC

  通过提升接口性能来提升系统并发处理能力

  前提: 异步RPC之间不存在相互依赖

  实例:

  1. 比如你的接口，内部调用了3个服务，时间分别为T1, T2, T3。
  2. 如果是顺序调用，则总时间是T1 + T2 + T3；
  3. 如果并发调用，总时间是Max(T1,T2,T3)。

  一般成熟的RPC框架，本身都提高了异步化接口，Future或者Callback形式