保险丝 类比恰到好处，生动形象，容易理解。
熔断主要有三个状态 close half-open open
close时 会有错误计数器，假设超过一定得阈值就切换至open状态（直接返回错误），那也不能一直是open状态，open状态跟不能用一样一样的，得从open切换至half-open状态，检测下是否OK了，若OK了，就切换至close状态，继续提供服务。

需要考虑啥
从业务出发会有很多的错误码，注意错误的类型。
并发，这个防止熔断是性能的瓶颈。
探活，就是ping下是否OK了
日志的监控 能更详细的看是否有问题
提供人工操作的入口，人工可操作是否熔断

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

2. 熔断的时机。
    服务脱离系统前会有一段时间的半熔断过渡期，即半熔断状态，在这个时期，我们仍然有可能通过继续一定数量的测试服务是否可用，来使熔断器从半熔断切换到闭合状态的,即并不真正触发熔断状态。

3. 熔断的粒度。
    对于某一块业务，系统中的服务往往是通过数据库或消息队列等进行相互依赖的，某个服务的脱离，必然会对整体业务造成影响，为避免尽可能减少其负面影响。往往需要通过资源分区来限定熔断的粒度，然后只对出现问题的分区进行熔断，而不是整体。
4. 后熔断时期。