Hystrix：定制电路断路器和恢复逻辑

Question

我刚刚阅读Hystrix指南，并试图围绕默认断路器和恢复期如何操作，然后如何定制其行为。显然，如果电路跳闸，Hystrix将自动调用命令的getFallBack()方法;这我了解。但是首先要考虑的是什么标准？理想情况下，我想尝试多次提供支持服务（例如，最多3次尝试），然后再考虑服务处于离线/不健康状态并断开断路器。 我怎么能实现这一点，并在哪里？

但我想如果我重写默认断路器，我还必须重写任何机制处理默认恢复期。如果某后备服务下山的时候，可能有以下几个原因之一：

• 有
• 这项服务是部署错误客户端和服务器之间的网络中断，使得它不能返回有效的回应客户
• 客户端部署与这使得它无法发送有效的请求到服务器
• 有些怪异，瞬时服务打嗝的（也许是服务做了重大的垃圾回收等）
错误
• 等

在大多数情况下，恢复期仅等待N秒，然后再次尝试是不够的。如果该服务存在缺陷，或者有人在数据中心中拉出了一些网络电缆，我们将总是从该服务中失败。只有在少数情况下，客户服务机构才会自动自我修复，而无需人为干预。

所以我想我的下一个问题是局部的，但我想这主要是“如何自定义默认的恢复周期策略？”：“如何使用猬当服务已关闭通知DEVOPS和需要人工干预“

Answer 1

基本上有四大原因猬调用备用方法：异常，超时太多并行请求，或在前面的呼叫过于许多例外。

如果返回代码或从服务接收到的异常表明重试有意义，您可能需要在run（）方法中重试。

在您的回退方法中，您可能会在发生超时时重试 - 当发生太多并行请求或太多异常时，再次调用同一服务通常没有意义。

还问如何通知devops：您应该连接监测系统Hystrix，调查断路器的状态和成功和失败的呼叫比率。您可以使用提供的metrics publishers，JMX或使用Hystrix的API编写您自己的适配器。我已经为Riemann和Zabbix在tutorial I prepared中编写了两个适配器;你会为此添加几行代码。

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

Br， Alexander。