你好，我是陈皓，网名左耳朵耗子。

熔断机制这个词对你来说肯定不陌生，它的灵感来源于我们电闸上的“保险丝”，当电压有问题时（比如短路），自动跳闸，此时电路就会断开，我们的电器就会受到保护。不然，会导致电器被烧坏，如果人没在家或是人在熟睡中，还会导致火灾。所以，在电路世界通常都会有这样的自我保护装置。

同样，在我们的分布式系统设计中，也应该有这样的方式。前面说过重试机制，如果错误太多，或是在短时间内得不到修复，那么我们重试也没有意义了，此时应该开启我们的熔断操作，尤其是后端太忙的时候，使用熔断设计可以保护后端不会过载。

熔断设计

熔断器模式可以防止应用程序不断地尝试执行可能会失败的操作，使得应用程序继续执行而不用等待修正错误，或者浪费CPU时间去等待长时间的超时产生。熔断器模式也可以使应用程序能够诊断错误是否已经修正。如果已经修正，应用程序会再次尝试调用操作。

换句话来说，我觉得熔断器模式就像是那些容易导致错误的操作的一种代理。这种代理能够记录最近调用发生错误的次数，然后决定是继续操作，还是立即返回错误。

（本图来自 Martin Fowler 的 Circuit Breaker）

熔断器可以使用状态机来实现，内部模拟以下几种状态。

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

如果这一定数量的请求有调用失败的情况，则认为导致之前调用失败的问题仍然存在，熔断器切回到断开状态，然后重置计时器来给系统一定的时间来修正错误。半断开状态能够有效防止正在恢复中的服务被突然而来的大量请求再次拖垮。

（本图来自 Martin Fowler 的 Circuit Breaker）

实现熔断器模式使得系统更加稳定和有弹性，在系统从错误中恢复的时候提供稳定性，并且减少了错误对系统性能的影响。它快速地拒绝那些有可能导致错误的服务调用，而不会去等待操作超时或者永远不返回结果来提高系统的响应时间。

如果熔断器设计模式在每次状态切换的时候会发出一个事件，这种信息可以用来监控服务的运行状态，能够通知管理员在熔断器切换到断开状态时进行处理。

下图是Netflix的开源项目Hystrix中的熔断的实现逻辑（其出处在这里）。

从这个流程图中，可以看到：

有请求来了，首先allowRequest()函数判断是否在熔断中，如果不是则放行，如果是的话，还要看有没有到达一个熔断时间片，如果熔断时间片到了，也放行，否则直接返回出错。
每次调用都有两个函数markSuccess(duration)和markFailure(duration) 来统计一下在一定的duration内有多少调用是成功还是失败的。
判断是否熔断的条件 isOpen()，是计算一下 failure/(success+failure) 当前的错误率，如果高于一个阈值，那么打开熔断，否则关闭。
Hystrix会在内存中维护一个数组，其中记录着每一个周期的请求结果的统计。超过时长长度的元素会被删除掉。

熔断设计的重点

在实现熔断器模式的时候，以下这些因素可能需要考虑。

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

小结

好了，我们来总结一下今天分享的主要内容。首先，熔断设计是受了电路设计中保险丝的启发，其需要实现三个状态：闭合、断开和半开，分别对应于正常、故障和故障后检测故障是否已被修复的场景，并介绍了Netflix的Hystrix对熔断的实现。最后，我总结了熔断设计的几个重点。下节课，我们讲述限流设计。希望对你有帮助。

也欢迎你分享一下你实现过的熔断使用了怎样的算法？实现的过程中遇到过什么坑？

文末给出了《分布式系统设计模式》系列文章的目录，希望你能在这个列表里找到自己感兴趣的内容。

精选留言（15）

曾凡伟 👍（13） 💬（1）
请问熔断的最小粒度，是针对每个单一请求，还是针对整个应用来实施呢
2018-03-16

程序员Artist 👍（34） 💬（11）
看到第一个留言问熔断粒度的，您回复的是服务粒度，这个错了吧，应该是接口粒度的吧。另外，相关方面你文中说在半断开后通过ping来探活，这个也不行吧，探活是成功的，不代表被熔断的那个接口是活的。说白了，还是觉得您对熔断粒度理解有点偏差，不是服务粒度的。因为一个服务会暴露多个接口，每个接口有不同的计算逻辑和依赖不同的依赖，一个接口挂不代表别的接口也挂。
2019-06-26

Geek_Heiko 👍（7） 💬（0）
#day 14#弹力设计之"熔断设计" 什么是熔断设计？类比于家用电器的中的过载保护装置(如保险丝)，我个人的理解是，熔断设计是赋能系统中的服务自我保护的一种机制，表现为: 让在运行着的系统中的出现”问题“的服务，脱离其所在的系统环境一段时间，这样一来，一方面可以使得该服务避免"带病工作"，全力进行自我恢复，从而更好地适应当时的环境继续正常地提供服务；另一方面，系统也可以很清楚地知道该服务现在还无法提供正常的服务，在一段时间内或不会再向其发送服务请求，进一步地谨慎处理相关请求，避免相关获取到不正确的数据或状态在系统中流动、蔓延。从一定程度上说，熔断是服务为了保护好自己，从而最终也很好地保护了其所在的系统。更为具体地，我们将熔断设计看作是一个熔断器的设计。一般而言，熔断器就断开和闭合两种状态，对应的是服务脱离或连接着系统，但我们想做得更好一些，于是就有了一种"半闭合"，顾名思义，这是一种闭合到断开的过渡状态，其在触发熔断机制时，仍"藕断丝连"，允许一定数量的请求去调用该服务，如果是调用成功的，则可认为之前导致该问题的已经得到修正，继续切换回闭合状态，反之，则完全断开切换到断开状态。当然，实际具体到实际的系统中引入熔断机制，从其触发到其状态的管理，切换并不是一件简单的事情，熔断触发的条件往往多方面一定时间内的积累的结果，个人觉得一个熔断器的考量指标应该是包含其对于熔断触发的"敏感程度"的。其主要考虑一下几个方面: 1. 熔断的准备。各式各样的"错误"是熔断机制触发的必要条件，但是，有些错误我们是可以通过重试机制就能解决的，而有些错误只能通过触发熔断机制才能是错误能够得到解决的可能。所以，在熔断器的前端需要有日志监控功能和配套的错误类型识别，以便在合适的实际触发熔断机制，也在一定程度上便于调试熔断器的"敏感度"。 2. 熔断的时机。服务脱离系统前会有一段时间的半熔断过渡期，即半熔断状态，在这个时期，我们仍然有可能通过继续一定数量的测试服务是否可用，来使熔断器从半熔断切换到闭合状态的,即并不真正触发熔断状态。 3. 熔断的粒度。对于某一块业务，系统中的服务往往是通过数据库或消息队列等进行相互依赖的，某个服务的脱离，必然会对整体业务造成影响，为避免尽可能减少其负面影响。往往需要通过资源分区来限定熔断的粒度，然后只对出现问题的分区进行熔断，而不是整体。 4. 后熔断时期。
2020-01-13

老烟斗 👍（5） 💬（0）
@Adrian 极客好像非作者不能回复，专门留言回复你。。首先下游服务可以分为第三方服务跟微服务，第三方服务没见过谁直接调用某个服务节点的，都是通过网关去负载均衡，所以服务不可用即代表了网关服务不可用，对上游服务来说，跟集群不可用没有区别，而微服务的话，调用的时候单节点不可用会自动给你负载到可用服务节点，除非服务提供者全部挂了（网络波动导致连不通也算），否则不会触发这个断路器，设置了超时时间的断路另说
2018-09-06

slark 👍（5） 💬（0）
弹性设计相关，看一看 spring微服务实战很有帮助。或者把spring cloud的组件，背景了解一下，对于微服务为什么要这样做就有谱了。大型互联网公司里在没有通用组件前都会有自研的类似组件，比如负载均衡，通用网关，鉴权，流水日志等。有一定经历，再来看微服务的设计会觉得他们其实非常相似。java在这方面有成熟组件，实在是非常有利于开发
2018-08-01

edisonhuang 👍（3） 💬（0）
熔断设计受保险丝设计的启发，可以保证系统在出问题是客户端及时停止调用而非一直失败重试。熔断的设计会涉及三种状态，闭合状态，半开状态和打卡状态，三种状态可以由一个状态机来转换。熔断设计还需要考虑的几个重要问题包括错误类型的区分，日志监控，允许手动恢复的设置，并发问题等
2019-07-10

多米 👍（3） 💬（0）
可惜更新有点慢～
2018-03-17

Sunshine 👍（2） 💬（1）
陈老师，基于滑动时间窗口进行调用(success & fail)的统计，底层的数据结构有什么好的推荐吗？目前在使用逻辑环形数组
2019-05-22

亚 👍（1） 💬（0）
全面的对熔断机制加深了理解，尽管项目中没有用到过熔断技术，但是这个是成为好的后端程序员以及架构师的必备技术。
2020-04-28

亚 👍（1） 💬（0）
熔断的三种状态很受启发这三种状态可以留给系统缓冲时间以及避免错误熔断和循环熔断。希望对以后的工作有所帮助目前还没用到这种功能
2020-04-26

escray 👍（0） 💬（0）
使用熔断设计保护后端不会过载。在 Closed 状态下，错误计数器基于时间，在特定时间间隔内自动重置，以防止偶然错误导致的熔断，这个设计比较巧妙。半断开状态 Half-Open 防止正在恢复中的服务被突然的大量请求冲垮，这个也挺厉害。去看了 Martin Fowler 的那篇 CircuitBreaker，看到 Ruby 的代码感觉很亲切。然后去看 Hystrix 的说明文档，被劝退，虽然图示很漂亮。
2023-03-20

新时代IT民工 👍（0） 💬（0）
通过ping来探活是没有问题的。和k8s的healthz探测一样，最了解服务状态的是开发。服务是否正常状态开发再了解不过了，所以这个健康探测接口有开发去实现，定时去ping就可以了
2022-01-21

方勇(gopher) 👍（0） 💬（0）
在golang实战工作池，我们实战了熔断限流
2021-11-02

惘闻 👍（0） 💬（0）
我没有看懂这句话里面的因果关系，导致出错的数据和参数跟半开状态的探测服务恢复有什么必然关系吗？重试错误的请求。有时候，错误和请求的数据和参数有关系，所以，记录下出错的请求，在半开状态下重试能够准确地知道服务是否真的恢复。当然，这需要被调用端支持幂等调用，否则会出现一个操作被执行多次的副作用。
2021-05-27

你为啥那么牛 👍（0） 💬（0）
越看越明白了，现在大众层面所谈的熔断机制，说的神乎其神。说到底，基本原理就是这些，跟自己所想基本一致，就看如何设计，如何应用了。包括上一篇文章，所谈的重试机制。
2020-10-28