熔断机制借鉴电闸上的“保险丝”。当电压有问题时，自动跳闸。
防止应用程序不断地尝试执行可能会失败的操作，如果已经恢复，应用程序会再次尝试调用。
熔断器可以使用状态机来实现，内部模拟以下几种状态：
- 闭合（Closed）状态：
我们需要一个调用失败的计数器，如果调用失败，则使失败次数加 1。如果最近失败次数超过了在给定时间内允许失败的阈值，则切换到断开 (Open) 状态。此时开启了一个超时时钟，当该时钟超过了该时间，则切换到半断开（Half-Open）状态。该超时时间的设定是给了系统一次机会来修正导致调用失败的错误，以回到正常工作的状态。
在 Closed 状态下，错误计数器是基于时间的。在特定的时间间隔内会自动重置。这能够防止由于某次的偶然错误导致熔断器进入断开状态。也可以基于连续失败的次数。
- 断开 (Open) 状态：
在该状态下，对应用程序的请求会立即返回错误响应，而不调用后端的服务。这样也许比较粗暴，有些时候，我们可以 cache 住上次成功请求，直接返回缓存（当然，这个缓存放在本地内存就好了），如果没有缓存再返回错误（缓存的机制最好用在全站一样的数据，而不是用在不同的用户间不同的数据，因为后者需要缓存的数据有可能会很多）。
- 半开（Half-Open）状态：
允许应用程序一定数量的请求去调用服务。如果这些请求对服务的调用成功，那么可以认为之前导致调用失败的错误已经修正，此时熔断器切换到闭合状态 (并且将错误计数器重置)。
- Hystrix
https://www.cnblogs.com/jinjiyese153/p/8669702.html
- 错误的类型
请求失败的原因很多。要根据不同的错误情况来调整相应的策略。一些错误先走重试（如限流、超时），重试几次再打开熔断。一些错误是远程服务挂掉，恢复时间比较长，可以直接打开熔断
- 日志监控
熔断应该记录所有失败的请求，以及一些可能会尝试成功的请求
- 测试服务是否可用
断开状态下，熔断器定期ping下远程服务的健康状态，来判断服务是否恢复，而不是使用计时器来自动切换到半开状态
- 手动重置
管理员可以手动强制将熔断器切换到闭合状态。同样，如果服务暂时不可用，管理员也可以强制将熔断器设置为断开状态
- 并发问题
同一个熔断器可能存在大量并发请求访问，熔断器的实现不应该阻塞或者增加调用者的负担。计数器可以用atomic原子性
- 资源分区
分布式架构，资源可能分布在不同的分区上，如：数据库分库分表，某一个分区出现问题，其它分区可用。单一的熔断器会把所有的分区混为一谈。出现一会熔断一会又好了，来来回回的情况
- 重试导致的错误
对于幂等的业务，重试也会报错，所以要准确区分服务是否真的恢复，还是重试报的错误