当在短时间内多次发生指定类型的错误，断路器会开启。开启的断路器可以拒绝接下来更多的请求 – 就像防止真实的电子流动一样。断路器通常在一定时间后关闭，以便为底层服务提供足够的空间来恢复。
请记住，并不是所有的错误都应该触发断路器。例如，你可能希望忽略客户端问题，比如4xx响应代码的请求，但要包括5xx服务器端故障。一些断路器还可以有半开关状态。在这种状态下，服务发送第一个请求以检查系统的可用性，同时让其他请求失败。如果这个第一个请求成功，则将断路器恢复到关闭状态并继续接受流量。否则，保持打开状态。
断路器
故障测试（Testing for Failures）
你应该持续地测试系统的常见问题，以确保你的服务可各类故障环境下运行。你应经常测试故障，以让你的团队对可能发生的事故有所准备。
关于测试，你可以使用外部服务来识别服务实例组，并随机终止运行组中的一个实例。通过使用这个方法，可以针对单个实例故障进行测试，你甚至可以关闭整个服务组来模拟云提供商层面的故障中断。
最流行的测试解决方案之一是Netflix的ChaosMonkey工具。
总结
实施和运维可靠的服务并不容易。这需要你付出很多努力，还要花费公司更多的成本。
可靠性有很多层次和方面，因此针对你的团队找出合适的解决方案是相当重要的。你应该将可靠性成为业务决策流程中的一个因素，并为此分配足够的预算和时间。
要点
1.动态环境和分布式系统-如微服务将导致更高的故障机会。
2.服务应单独失效，实现优雅的服务降级以提升用户体验。
3.70％的问题是由变更引起的，恢复可用代码并不总是坏事。
4.快速，单独地失败。团队无法控制其服务依赖关系。
5.架构模式和技术，如缓存、隔离技术、断路器和限流器有助于构建可靠的微服务。
作者简介：
Péter Márton，是RisingStack的CTO , 擅长使用nodejs来构建微服务。他的twitter帐号为
https://twitter.com/slashdotpeter。