Question

我们目前已经研究了使用 Hystrix 创建断路器模式和舱壁模式的基本概念。现在我们来看看如何真正定制 Hystrix 断路器的行为。记住，Hystrix 不仅能超时长时间运行的调用，它还会监控调用失败的次数，如果调用失败的次数足够多，那么 Hystrix 会在请求发送到远程资源之前，通过使调用失败来自动阻止未来的调用到达服务。

这样做有两个原因。首先，如果远程资源有性能问题，那么快速失败将防止应用程序等待调用超时。这显著降低了调用应用程序或服务所导致的资源耗尽问题和崩溃的风险。其次，快速失败和阻止来自服务客户端的调用有助于苦苦挣扎的服务保持其负载，而不会彻底崩溃。快速失败给了性能下降的系统一些时间去进行恢复。

要了解如何在 Hystrix 中配置断路器，需要先了解 Hystrix 如何确定何时跳闸断路器的流程。图 5-9 展示了 Hystrix 在远程资源调用失败时使用的决策过程。

图 5-9 Hystrix 经过一系列检查来确定是否跳闸

每当 Hystrix 命令遇到服务错误时，它将开始一个 10 s 的计时器，用于检查服务调用失败的频率。这个 10 s 窗口是可配置的。Hystrix 做的第一件事就是查看在 10 s 内发生的调用数量。如果调用次数少于在这个窗口内需要发生的最小调用次数，那么即使有几个调用失败，Hystrix 也不会采取行动。例如，在 Hystrix 考虑采取行动之前，需要在 10 s 之内进行调用的次数的默认值为 20。如果这些调用之中有 15 个在 10 s 内发生调用失败，只要在 10 s 之内调用次数达不到 20 次，那么即使 15 个调用都失败，这些调用的数量也不足以让断路器发生跳闸。Hystrix 将继续让调用通过，到达远程服务。

在 10 s 窗口内达到最少的远程资源调用次数时，Hystrix 将开始查看整体故障的百分比。如果故障的总体百分比超过阈值，Hystrix 将触发断路器，使将来几乎所有的调用都失败。正如稍后即将讨论的那样，Hystrix 将会让部分调用通过来进行“测试”，以查看服务是否恢复。错误阈值的默认值为 50%。

如果超过错误阈值的百分比，Hystrix 将“跳闸”断路器，防止更多的调用访问远程资源。如果远程调用失败的百分比未达到要求的阈值，并且 10 s 窗口已过去，Hystrix 将重置断路器的统计信息。

当 Hystrix 在一个远程调用上“跳闸”断路器时，它将尝试启动一个新的活动窗口。每隔 5 s（这个值是可配置的），Hystrix 会让一个调用到达这个苦苦挣扎的服务。如果调用成功，Hystrix 将重置断路器并重新开始让调用通过。如果调用失败，Hystrix 将保持断路器断开，并在另一个 5 s 里再次尝试上述步骤。

基于此，开发人员可以使用 5 个属性来定制断路器的行为。 @HystrixCommand 注解通过 commandPoolProperties 属性公开了这 5 个属性。其中， threadPoolProperties 属性用于设置 Hystrix 命令中使用的底层线程池的行为，而 commandPoolProperties 属性用于定制与 Hystrix 命令关联的断路器的行为。代码清单 5-7 展示了这些属性的名称以及如何在每个属性中设置值。