请问熔断的最小粒度，是针对每个单一请求，还是针对整个应用来实施呢

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

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

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

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

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

可惜更新有点慢～

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

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

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