Hystrix：自定义断路器和恢复逻辑

Question

我刚刚阅读了Hystrix 指南，并试图了解默认断路器和恢复期如何运作，以及如何自定义它们的行为。

显然，如果电路跳闸，Hystrix 会自动调用命令的getFallBack() 方法；这我明白了。但是首先使电路跳闸的标准是什么？理想情况下，在我们认为服务脱机/不健康并触发断路器之前，我想尝试多次访问支持服务（例如，最多 3 次尝试）。 我该如何实施？在哪里实施？

但我想如果我覆盖默认断路器，我还必须覆盖处理默认恢复期的任何机制。如果支持服务出现故障，可能是由于以下几种原因之一：

• 客户端和服务器之间出现网络中断
• 服务部署时存在一个错误，导致无法向客户端返回有效响应
• 客户端部署了一个错误，导致它无法向服务器发送有效请求
• 一些奇怪的、短暂的服务中断（可能服务正在执行主要的垃圾收集等）
• 等

在大多数情况下，仅仅等待 N 秒然后重试的恢复期是不够的。如果服务中存在错误，或者有人在数据中心拔了一些网络电缆，我们将总是从该服务中遇到故障。只有在少数情况下，客户端服务会在没有任何人工交互的情况下自动修复自己。

所以我猜我的下一个问题部分是“如何自定义默认恢复期策略？”，但我猜主要是：“如何使用 Hystrix 通知 devops服务何时关闭并需要人工干预？“

Answer 1

基本上Hystrix调用fallback方法的原因有四个：异常、超时、并行请求太多、或者之前调用的异常太多。

如果您从服务收到的返回码或异常表明重试有意义，您可能希望在 run() 方法中进行重试。

在命令的后备方法中，您可能会在超时时重试 - 当并行请求过多或异常过多时，再次调用相同的服务通常没有意义。

还问如何通知 devops：您应该将监控系统连接到 Hystrix，以轮询断路器的状态以及成功和不成功调用的比率。您可以使用 metrics publishers 提供的 JMX，或使用 Hystrix 的 API 编写自己的适配器。我在tutorial I prepared 中为 Riemann 和 Zabbix 编写了两个适配器；您将为此编写非常少的代码。

本教程还有一个示例应用程序和一个负载驱动程序来尝试一些场景。

兄弟， 亚历山大。