川山甲

追求内心的非常平静!瞬间清空所有的杂念,达到物我两忘!

  博客园  :: 首页  ::  :: 联系 :: 订阅 订阅  :: 管理
 
背景
    
  

 

 

  
  熔断机制这个词对你来说肯定不陌生,它的灵感来源于我们电闸上的 " 保险丝 ",当电压有 问题时(比如短路),自动跳闸,此时电路就会断开,我们的电器就会受到保护。不然,会 导致电器被烧坏,如果人没在家或是人在熟睡中,还会导致火灾。所以,在电路世界通常都 会有这样的自我保护装置。 同样,在我们的分布式系统设计中,也应该有这样的方式。前面说过重试机制,如果错误太 多,或是在短时间内得不到修复,那么我们重试也没有意义了,此时应该开启我们的熔断操 作,尤其是后端太忙的时候,使用熔断设计可以保护后端不会过载。 
 
熔断设计
   熔断器模式可以防止应用程序不断地尝试执行可能会失败的操作,使得应用程序继续执行而 不用等待修正错误,或者浪费 CPU 时间去等待长时间的超时产生。熔断器模式也可以使应 用程序能够诊断错误是否已经修正。如果已经修正,应用程序会再次尝试调用操作。 换句话来说,我觉得熔断器模式就像是那些容易导致错误的操作的一种代理。这种代理能够 记录最近调用发生错误的次数,然后决定允许操作继续,或者立即返回错误。

 

 

熔断器可以使用状态机来实现,内部模拟以下几种状态。
闭合(Closed)状态:我们需要一个调用失败的计数器,如果调用失败,则使失败次数 加 1。如果最近失败次数超过了在给定时间内允许失败的阈值,则切换到断开 (Open) 状 态。此时开启了一个超时时钟,当该时钟超过了该时间,则切换到半断开(HalfOpen)状态。该超时时间的设定是给了系统一次机会来修正导致调用失败的错误,以回 到正常工作的状态。在 Closed 状态下,错误计数器是基于时间的。在特定的时间间隔内 会自动重置。这能够防止由于某次的偶然错误导致熔断器进入断开状态。也可以基于连续 失败的次数。
断开 (Open) 状态:在该状态下,对应用程序的请求会立即返回错误响应,而不调用后 端的服务。这样也许比较粗暴,有些时候,我们可以 cache 住上次成功请求,直接返回 缓存(当然,这个缓存放在本地内存就好了),如果没有缓存再返回错误(缓存的机制最 好用在全站一样的数据,而不是用在不同的用户间不同的数据,因为后者需要缓存的数据 有可能会很多)。
半开(Half-Open)状态:允许应用程序一定数量的请求去调用服务。如果这些请求对 服务的调用成功,那么可以认为之前导致调用失败的错误已经修正,此时熔断器切换到闭 合状态,同时将错误计数器重置。 如果这一定数量的请求有调用失败的情况,则认为导致之前调用失败的问题仍然存在,熔 断器切回到断开状态,然后重置计时器来给系统一定的时间来修正错误。半断开状态能够 有效防止正在恢复中的服务被突然而来的大量请求再次拖垮。
 

 

 

      实现熔断器模式使得系统更加稳定和有弹性,在系统从错误中恢复的时候提供稳定性,并且 减少了错误对系统性能的影响。它快速地拒绝那些有可能导致错误的服务调用,而不会去等 待操作超时或者永远不返回结果来提高系统的响应时间。 如果熔断器设计模式在每次状态切换的时候会发出一个事件,这种信息可以用来监控服务的 运行状态,能够通知管理员在熔断器切换到断开状态时进行处理。 下图是 Netflix 的开源项目Hystrix中的熔断的实现逻辑。
 

 

 
从这个流程图中,可以看到

 1. 有请求来了,首先 allowRequest() 函数判断是否在熔断中,如果不是则放行,如果是的 话,还要看有没有到达一个熔断时间片,如果熔断时间片到了,也放行,否则直接返回 出错。

2. 每次调用都有两个函数 markSuccess(duration) 和 markFailure(duration) 来统计一下 在一定的 duration 内有多少调用是成功还是失败的。

3. 判断是否熔断的条件 isOpen(),是计算一下 failure/(success+failure) 当前的错误率, 如果高于一个阈值,那么打开熔断,否则关闭。

4. Hystrix 会在内存中维护一个数组,其中记录着每一个周期的请求结果的统计。超过时长 长度的元素会被删除掉。

 

熔断设计的重点
 
 在实现熔断器模式的时候,以下这些因素需可能需要考虑。
 
 错误的类型:
  需要注意的是请求失败的原因会有很多种。你需要根据不同的错误情况来调 整相应的策略。所以,熔断和重试一样,需要对返回的错误进行识别。一些错误先走重试 的策略(比如限流,或是超时),重试几次后再打开熔断。一些错误是远程服务挂掉,恢 复时间比较长;这种错误不必走重试,就可以直接打开熔断策略。
 
日志监控:
  熔断器应该能够记录所有失败的请求,以及一些可能会尝试成功的请求,使得 管理员能够监控使用熔断器保护服务的执行情况。
 
测试服务是否可用:
  在断开状态下,熔断器可以采用定期地 ping 一下远程服务的健康检 查接口,来判断服务是否恢复,而不是使用计时器来自动切换到半开状态。这样做的一个 好处是,在服务恢复的情况下,不需要真实的用户流量就可以把状态从半开状态切回关闭 状态。否则在半开状态下,即便服务已恢复了,也需要用户真实的请求来恢复,这会影响 用户的真实请求。
 
手动重置:
  在系统中对于失败操作的恢复时间是很难确定的,提供一个手动重置功能能够 使得管理员可以手动地强制将熔断器切换到闭合状态。同样的,如果受熔断器保护的服务 暂时不可用的话,管理员能够强制将熔断器设置为断开状态。
 
并发问题:
  相同的熔断器有可能被大量并发请求同时访问。熔断器的实现不应该阻塞并发 的请求或者增加每次请求调用的负担。尤其是其中对调用结果的统计,一般来说会成为一 个共享的数据结构,它会导致有锁的情况。在这种情况下,最好使用一些无锁的数据结 构,或是 atomic 的原子操作。这样会带来更好的性能。
 
资源分区:
  有时候,我们会把资源分布在不同的分区上。比如,数据库的分库分表,某个 分区可能出现问题,而其它分区还可用。在这种情况下,单一的熔断器会把所有的分区访 问给混为一谈,从而,一旦开始熔断,那么所有的分区都会受到熔断影响。或是出现一会 儿熔断一会儿又好,来来回回的情况。所以,熔断器需要考虑这样的问题,只对有问题的 分区进行熔断,而不是整体。
 
重试错误的请求:
  有时候,错误和请求的数据和参数有关系,所以,记录下出错的请求, 在半开状态下重试能够准确地知道服务是否真的恢复。当然,这需要被调用端支持幂等调 用,否则会出现一个操作被执行多次的副作用。
 
推荐
喜欢编程
posted on 2020-04-20 13:50  川山甲  阅读(681)  评论(0编辑  收藏  举报