了解服务熔断服务熔断又称服务隔离，来自含蓄溪流Ny gard 《Release It》中的CircuitBreaker应用模型，Martin Fowler在博文CircuitBreaker中详细描述了该设计
本文认为服务熔断是一种服务降级措施。 服务熔断为服务提供代理，防止服务不可行时发生级联故障(cascading failure )导致雪崩效应。 服务熔断一般由某个服务(下游服务)的故障引起，服务的降级一般从整体负荷考虑；
如Martin文中的图所示：
服务熔断和服务降级感兴趣的目标也不同。 每个微服务都需要熔断，是一个框架级的处理。 另一方面，服务降级一般关注业务，思考业务，抓住业务水平，决定从哪个层面处理。 例如，决定是在IO层、业务逻辑层还是周边进行处理。
马丁设计了一个状态机来表示服务的各种状态。
在状态机上实现，内部模拟以下状态。
关闭状态：对APP应用程序的请求可以直接触发方法的调用。 代理类保持最近的调用失败的次数，如果某个调用失败，则将失败次数加1。 如果最近的失败次数在指定时间内超过允许失败的阈值，代理类将切换为Open状态。 此时，代理打开超时时钟，如果该时钟超过此时间，则切换为半中断。 半开状态。 此超时时间设置为系统提供了纠正调用失败错误的机会。 禁用(Open )状态)在此状态下，对APP应用程序的请求将立即返回错误响应。 图：
说明：半关闭(Half-Open )状态允许对服务的一定数量的请求调用服务，可以有效防止正在恢复的服务由于突然的大量请求而再次被拖后腿。 也称为限流模式、预防模式。 如果这些请求成功调用服务，则可能已修复以前调用失败的错误，并且保险丝已切换到关闭状态。 此外，重置错误计数器。 如果这一定数量的请求调用失败，则以前的调用失败的问题可能仍然存在，保险丝将恢复断开方式，重置计时器并给系统一定的时间开始修复错误。
博主cqdrs认为，在针对服务熔断的设计中应考虑包含这些设计：
异常处理：调用受保险丝保护的服务时，必须处理服务不可用时的异常。 这些异常处理通常取决于具体的业务情况。 例如，如果APP应用程序只是临时降级，则可能需要切换到另一个可更换服务来执行相同的任务，获取相同的数据，或者要求用户报告错误并稍后重试。 异常的类型：请求失败的原因可能有多种。 一些原因可能比其他原因更严重。 例如，请求失败可能是因为远程服务崩溃。 恢复这个可能需要几分钟。 服务器上的临时负载可能太大，导致超时。 保险丝应该可以检查错误类型，并根据具体错误情况调整策略。 例如，您可能需要多次超时异常才能确定需要切换到断开状态，但需要几次错误消息才能确定服务不可用并快速切换到断开状态。 日志：保险丝必须能够记录所有失败的请求和可能试图成功的请求。 这样，的管理员可以监视受保险丝保护的服务的执行情况。 测试服务是否可用：在断开状态下，保险丝可以定期ping远程服务或资源以确定服务是否恢复，而不是使用计时器自动切换到半断开状态。 此ping操作可以模拟以前失败的请求，也可以使用调用远程服务以检查提供的服务是否可用的方法来确定。 手动重置：系统很难确定失败操作的恢复时间。 提供手动复位功能，管理员可以手动强制将保险丝切换到关闭状态。 同样，如果受保险丝保护的服务暂时不可用，管理员可以强制将保险丝设置为断开状态。 并发问题：同一保险丝可能被大量并发访问请求同时访问。 熔丝实现不应阻止并发请求，也不应增加每次请求调用的负担。 资源差异：使用单个保险丝时，如果单个资源分布在多个位置，则需要小心。 例如，一个数据存储在多个磁盘分区上，一个分区可以成功访问，另一个数据可能存在临时问题。 在这种情况下，如果混淆了不同的错误响应，则APP应用程序访问的这些有问题的分区很可能失败，可能会阻止被认为正常的分区。 如果保险丝加快熔断操作，则服务返回的错误消息足以使保险丝立即执行熔断操作并保留一段时间。 例如，如果从分布式资源返回的响应提示过载，则需要等待几分钟，然后重试。 (HTTP协议定义了http 503服务不可用，表示请求的服务当前不可用。 可以包含其他信息，如超时。 )可以重复失败的要求。 当保险丝断开时，保险丝不仅可以返回失败信息，还可以记录每个请求的详细信息。 这样，当远程服务重新启动时，可以再次请求失败的请求。 注意：服务熔断恢复重试问题：如果服务为幂等性，则恢复重试没有问题； 如果服务不是幂，重试会导致数据出现问题。
网络公司Netflix (其Hystrix )作为Netflix开源框架中最喜欢的组件之一，可以用于处理依赖隔离和实现熔断机制。
在Hystrix中，最重要的class是HystrixCommand和HystrixObservableCommand。
以下是Netflix维客：
You can support
graceful degradation in a Hystrix command by adding a fallback method that Hystrix will call to obtain a default value or values in case the main command fails. You will want to implement a fallback for most Hystrix commands that might conceivably fail, with a couple of exceptions: a command that performs a write operationIf your Hystrix command is designed to do a write operation rather than to return a value (such a command might normally return a void in the case of a HystrixCommand or an empty Observable in the case of a HystrixObservableCommand), there isn’t much point in implementing a fallback. If the write fails, you probably want the failure to propagate back to the caller.batch systems/offline compute
If your Hystrix command is filling up a cache, or generating a report, or doing any sort of offline computation, it’s usually more appropriate to propagate the error back to the caller who can then retry the command later, rather than to send the caller a silently-degraded response.
Whether or not your command has a fallback, all of the usual Hystrix state and circuit-breaker state/metrics are updated to indicate the command failure.
In an ordinary HystrixCommand you implement a fallback by means of a getFallback() implementation. Hystrix will execute this fallback for all types of failure such as run() failure, timeout, thread pool or semaphore rejection, and circuit-breaker short-circuiting. The following example includes such a fallback:
public class CommandHelloFailure extends HystrixCommand<String> { private final String name; public CommandHelloFailure(String name) { super(HystrixCommandGroupKey.Factory.asKey("ExampleGroup")); this.name = name; } @Override protected String run() { throw new RuntimeException("this command always fails"); } @Override protected String getFallback() { return "Hello Failure " + name + "!"; }}