什么是微服务的熔断机制
在2017年2月1日，GitLab公司的运维人员就出现过这样的事故。当时运维人员在进行数据库维护时，通过执行rm -rf命令，删除了约300GB生产环境数据。由于数据备份失效，导致整个网站宕机数十个小时。
自2017年5月12日起，全球范围内爆发基于Windows网络共享协议进行攻击传播的蠕虫恶意代码，这是不法分子通过改造之前泄露的NSA黑客武器库中“永恒之蓝”攻击程序发起的网络攻击事件，用户只要开机上网就可被攻击。短短几个小时内，包括英国、俄罗斯、整个欧洲及国内多个高校校内网、大型企业内网和政府机构专网遭到了攻击，被勒索支付高额赎金才能解密恢复文件，对重要数据造成严重的损失。
可见信息系统的安全是一个无法忽视的问题。无论是个人还是组织，即便是最简单的系统，都需要考虑安全防护的措施。服务的熔断机制就是一种对网站进行防护的措施。
服务熔断的定义
对于“熔断”一词，大家应该都不会陌生，在中国股市，就曾经在2016年1月1日至2016年1月8日期间，实施过两次熔断机制。在微服务架构中,服务熔断本质上与股市的熔断机制并无差异，其出发点都是为了更好地控制风险。
服务熔断也称服务隔离或过载保护。在微服务应用中，服务存在一定的依赖关系，形成一定的依赖链，如果某个目标服务调用慢或者有大量超时，造成服务不可用，间接导致其他的依赖服务不可用，最严重的可能会阻塞整条依赖链，最终导致业务系统崩溃(又称雪崩效应)。此时，对该服务的调用执行熔断，对于后续请求，不再继续调用该目标服务，而是直接返回，从而可以快速释放资源。等到目标服务情况好转后，则可恢复其调用。
断路器
断路器(Circuit Breaker)本身是一个电子硬件产品，是电器中一个重要组成部分。断路器可用来分配电能，不用频繁地启动异步电动机，对电源线路及电动机等实行保护，当它们发生严重的过载或者短路及欠压等故障时能自动切断电路，其功能相当于熔断器式开关与过欠热继电器等的组合。
在微服务架构中，也存在所谓断路器或者实现断路器模式的软件构件。将受保护的服务封装在一个可以监控故障的断路器对象中，当故障达到一定门限时，断路器将跳闸，所有后继调用将不会发往受保护的服务而由断路器对象之间返回错误。对于需要更长时间解决的故障问题，由于不断重试没有太大意义了，所以就可以使用断路器模式。
路器模式
Michael Nygard在他编著的书Release lt!中推广了断路器模式。断路器模式致力于防止应用程序反复尝试执行可能失败的操作。允许它继续而不用等待故障被修复，或者在确定故障持续的时候浪费CPU周期。断路器模式还使应用程序能够检测故障是否已解决。如果问题似乎已经解决，应用程序可以尝试调用该操作。
断路器模式的目的不同于重试模式。重试模式使应用程序可以在预期成功的情况下重试操作。
断路器模式阻止应用程序执行可能失败的操作。应用程序可以通过使用重试模式及断路器模式来进行组合。然而，如果断路器指示故障不是瞬态的，则重试逻辑应该对断路器返回异常，并放弃重试尝试。
断路器充当可能失败的操作的代理。代理应监视最近发生的故障的数量，并使用此信息来决定是允许操作继续，还是立即返回异常。
代理可以作为一个状态机来实现，其状态模拟一个电气断路器的功能。
- 关闭(Closed):来自应用程序的请求被路由到操作。代理维护最近失败次数的计数，如果对操作的调用不成功，代理将增加此计数。如果在给定的时间段内最近的失败次数超过了指定的阈值，则代理被置于打开状态。此时代理启动一个超时定时器，当这个定时器超时时，代理被置于半开状态。超时定时器的目的是让系统有时间来解决导致失败的问题，然后再允许应用程序尝试再次执行操作。
- 打开(Open):来自应用程序的请求立即失败，并将异常返回给应用程序。
- 半打开 Half-Open 来自应用程序的有限数量的请求被允许通过并调用操作。如果这些请求成功，则认为先前引起故障的故障已被修复，断路器切换到关闭状态(故障计数器被重置)。如果有任何请求失败，断路器会认为故障仍然存在，因此它将恢复到打开状态，并重新启动超时定时器，以使系统有一段时间从故障中恢复。半开状态有助于防止恢复服务突然被请求淹没。当服务恢复时，它可能能够支持有限的请求量，直到恢复完成，但在进行恢复时，大量工作可能导致服务超时或再次失败。
图15-1展示的是 Microsoft Azure关于断路器状态的设计图。在该图中，关闭状态使用的故障计数器是基于时间的。它会定期自动重置。如果遇到偶尔的故障，这有助于防止断路器进入打开状态。只有在指定的时间间隔内发生指定次数的故障时，才会使断路器跳闸到断路状态的故障阈值。
半打开状态使用的计数器记录调用操作的成功尝试次数。在指定次数的连续操作调用成功后，断路器恢复到关闭状态。如果调用失败，断路器将立即进入打开状态，下一次进入半打开状态时，成功计数器将被重置。
系统恢复的方式可以通过恢复或重新启动故障组件或者修复网络连接来进行外部处理。
Spring Cloud Hystrix可以用来处理依赖隔离，实现熔断机制。其主要的类有HystrixCommand和HystrixObservableCommand等。
熔断的意义
在软件系统中，不可能百分之百保证不存在故障。为了保障整体系统的可用性和容错性，需要将服务实例部署在云或分布式系统环境中。
所以，我们必须承认服务一定是会出现故障的，只有清醒地认识到服务系统的本质，才能更好地去设计系统，来不断提高服务的可用性和容错性。
微服务的故障不可避免，这些故障可能是瞬时的，如慢的网络连接、超时，资源过度使用而暂时不可用;也可能是不容易预见的突发事件的情况下需要更长时间来纠正的故障。针对分布式服务的容错，通常的做法有两种。
- 重试机制，对于预期的短暂故障问题，通过重试模式是可以解决的。
- 断路器模式。
断路器模式所带来的好处
断路器模式提供了稳定性，同时系统从故障中恢复并最大限度地减少对性能的影响。通过快速拒绝可能失败的操作的请求，而不是等待操作超时或永不返回，可以帮助维持系统的响应时间。如果断路器每次改变状态都会产生一个事件，这个信息可以用来监测断路器所保护的系统部分的健康状况，或者在断路器跳到断路状态时提醒管理员。
断路器模式通常是可定制的，可以根据可能的故障类型进行调整。例如，可以自定义定时器的超时。您可以先将断路器置于“打开”状态几秒，然后如果故障仍未解决，则将超时增加到几分钟。
断路器模式的功能
一般来说，断路器具备如下功能。
1.异常处理
通过断路器调用操作的应用程序必须能够处理在操作不可用时可能被抛出的异常，该类异常的处理方式都是应用程序特有的。例如，应用程序会暂时降级其功能，调用备选操作尝试相同的任务或获取相同的数据，或者将异常通知给用户让其稍后重试。
一个请求可能由于各种原因失败，其中有一些可能表明故障严重类型高于其他故障。例如，一个请求可能由于需要几分钟才能恢复的远程服务崩溃而失败，也可能由于服务暂时超载造成的超时而失败。断路器有可能可以检查发生的异常类型，并根据这些异常类型来调整策略。例如，促使切换到打开状态的服务超时异常个数要远多于服务完全不可用导致的故障个数。
2.日志记录
一个断路器应记录所有失败的请求(如果可能的话记录所有请求)，以使管理员能够监视它封装下受保护操作的运行状态。
3.可恢复
应该把断路器配置成与受保护操作最匹配的恢复模式。例如，如果设定断路器为打开状态的时间需要很长，即使底层操作故障已经解决，它还会返回错误。如果打开状态切换到半打开态过快，底层操作故障还没解决，它就会再次调用受保护操作。
4.测试失败的操作
在打开状态下，断路器可能不用计时器来确定何时切换到半打开状态，而是通过周期性地查验远程服务或资源以确定它是否已经再次可用。这个检查可能采用上次失败的操作的形式，也可以使用由远程服务提供的专门用于测试服务健康状况的特殊操作。
5.手动复位
在一个系统中，如果一个失败的操作的恢复时间差异很大，则提供一个手动复位选项，以使管理员能够强行关闭断路器及重置故障计数器。同样，如果受保护操作暂时不可用，管理员可以强制断路器进入打开状态并重新启动超时定时器。
6.并发
同—断路器可以被应用程序的大量并发实例访问。断路器实现不应阻塞并发请求或对每一请求增加额外开销。
7.加速断路
有时失败响应对于断路器实现来说包含足够的信息用于判定是否应当立即跳闸，并保持最小时间量的跳闸状态。例如，从过载共享资源的错误响应中可能指示了“不推荐立即重试”，那么应用程序应当隔几分钟之后再进行重试，而不应该立即重试。
如果一个请求的服务对于特定Web服务器不可用，可以返回HTTP协议定义的“HTTP 503Service Unavailable”响应。该响应可以包含额外的信息，如预期延迟持续时间。
8.重试失败请求
在打开状态下，断路器可以不仅仅是快速地简单返回失败，而是可以将每个请求的详细信息记录日志，并在远程资源或服务重新可用时安排重试。
