一般对于服务依赖的保护主要有3种解决方案:
(1)熔断模式
(2)隔离模式
(3)限流模式
熔断模式和隔离模式都属于出错后的容错处理机制,而限流模式则可以称为预防模式。限流模式主要是提前对各个类型的请求设置最高的QPS阈值,若高于设置的阈值则对该请求直接返回,不再调用后续资源。这种模式不能解决服务依赖的问题,只能解决系统整体资源分配问题,因为没有被限流的请求依然有可能造成雪崩效应。

熔断(Circuit Breaker)模式:会处理一些需要一定时间来重连远程服务和远端资源的错误。该模式可以提高一个应用的稳定性和弹性。熔断模式可以防止应用重复的尝试调用容易失败的操作,当熔断模式判断错误会持续的时候,它会令操作不再持续等待,以免继续浪费CPU资源。当然,熔断模式也令应用本身可以发现错误有没有被修复。如果发生的问题已经被修复了,应用可以重新尝试去调用服务。
熔断模式可以按照:关闭、打开、半开,三个状态来模仿一个断路器的实现,如下图所示,熔断器模式定义了熔断器开关相互转换的逻辑:
1111.jpg
熔断器开关由关闭到打开的状态转换是通过当前服务健康状况和设定阈值比较决定的(PS:服务的健康状况 = 请求失败数 / 请求总数)。
关闭:应用的请求已经路由到了这个操作。代理应该维护最近一段时间的错误信息,如果调用操作失败,那么大力增加这个错误信息的数量。如果这个错误数量超过给定时间的阈值,代理进入到打开状态。这个时候,代理启动一个超时的Timer,当Timer过期了,代理则进入半开状态。超时Timer的目的是为了给系统一段时间来自我修复之前碰到的问题。
打开:令可能失败的外部调用操作立刻失败,所有的外部调用直接抛异常给应用。
半开:只有一定数量的应用请求可以进行操作的调用。如果这些请求成功了,那么就假定之前发成的错误已经被系统自动修复了,而Circuit-Breaker转换成关闭状态(同时重置错误计数器)。如果任何请求失败了,那么Circuit-Breaker会假定错误仍然在存在,Circuit-Breaker会重新转换成打开状态,并重启超时Timer给系统更多的时间来自我修复错误。

何时使用熔断(Circuit-Breaker)模式:当需要阻止应用不断尝试调用远端服务或者访问共享资源,并且这些请求很容易失败的时候使用Circuit-Breaker模式很合适。

什么场景不适合使用该模式:

当用来处理访问本地资源,比如内存中的数据结构的时候,不适合使用。在这种场景下,Circuit-Breaker只会给应用带来额外的负担。
将Circuit-Breaker作为处理应用中的业务逻辑中的异常处理的一部分也是不合适的。
参考文章:
大话分布式架构(五)- 熔断隔离
大话分布式架构(一)
架构必经之路2 - 熔断机制

标签: none

添加新评论