Question

代码清单 5-7 配置断路器的行为

@HystrixCommand(
→  fallbackMethod = "buildFallbackLicenseList",
→  threadPoolKey = "licenseByOrgThreadPool", 
→  threadPoolProperties = {
        @HystrixProperty(name = "coreSize",value="30"),
        @HystrixProperty(name="maxQueueSize"value="10"),
    },
→  commandPoolProperties = {
        @HystrixProperty(name="circuitBreaker.requestVolumeThreshold", value="10"),
        @HystrixProperty(name="circuitBreaker.errorThresholdPercentage", value="75"),
        @HystrixProperty(name="circuitBreaker.sleepWindowInMilliseconds", 
        →  value="7000"),
        @HystrixProperty(name="metrics.rollingStats.timeInMilliseconds", 
        →  value="15000"),
        @HystrixProperty(name="metrics.rollingStats.numBuckets", value="5")}
)
public List<License> getLicensesByOrg(String organizationId){
    logger.debug("getLicensesByOrg Correlation id: {}",
        UserContextHolder
            .getContext()
            .getCorrelationId()); 
    randomlyRunLong();

    return licenseRepository.findByOrganizationId(organizationId);
}

第一个属性 circuitBreaker.requestVolumeThreshold 用于控制 Hystrix 考虑将该断路器跳闸之前，在 10 s 之内必须发生的连续调用数量。第二个属性 circuitBreaker.error-ThresholdPercentage 是在超过 circuitBreaker.requestVolumeThreshold 值之后在断路器跳闸之前必须达到的调用失败（由于超时、抛出异常或返回 HTTP 500）百分比。上述代码示例中的最后一个属性 circuitBreaker.sleepWindowInMilliseconds 是在断路器跳闸之后，Hystrix 允许另一个调用通过以便查看服务是否恢复健康之前 Hystrix 的休眠时间。

最后两个 Hystrix 属性 metrics.rollingStats.timeInMilliseconds 和 metrics.rollingStats.numBuckets 的命名与前面的属性有所不同，但它们仍然是控制断路器的行为的。第一个属性 metrics.rollingStats.timeInMilliseconds 用于控制 Hystrix 用来监视服务调用问题的窗口大小，其默认值为 10 000 ms（即 10 s）。

第二个属性 metrics.rollingStats.numBuckets 控制在定义的滚动窗口中收集统计信息的次数。在这个窗口中，Hystrix 在桶（bucket）中收集度量数据，并检查这些桶中的统计信息，以确定远程资源调用是否失败。给 metrics.rollingStats.timeInMilliseconds 设置的值必须能被定义的桶的数量值整除。例如，在代码清单 5-7 所示的自定义设置中，Hystrix 将使用 15 s 的窗口，并将统计数据收集到长度为 3 s 的 5 个桶中。

注意

检查的统计窗口越小且在窗口中保留的桶的数量越多，就越会加剧高请求服务的 CPU 利用率和内存利用率。要意识到这一点，避免将度量收集窗口和桶设置为太细的粒度，除非你需要这种可见性级别。

重新审视 Hystrix 配置

Hystrix 库是高度可配置的，可以让开发人员严格控制使用它定义的断路器模式和舱壁模式的行为。开发人员可以通过修改 Hystrix 断路器的配置，控制 Hystrix 在超时远程调用之前需要等待的时间。开发人员还可以控制 Hystrix 断路器何时跳闸以及 Hystrix 何时尝试重置断路器。

使用 Hystrix，开发人员还可以通过为每个远程服务调用定义单独的线程组，然后为每个线程组配置相应的线程数来微调舱壁实现。这允许开发人员对远程服务调用进行微调，因为某些远程资源调用具有较高的请求量。

在配置 Hystrix 环境时，需要记住的关键点是，开发人员可以使用 Hystrix 的 3 个配置级别：

（1）整个应用程序级别的默认值；

（2）类级别的默认值；

（3）在类中定义的线程池级别。

每个 Hystrix 属性都有默认设置的值，这些值将被应用程序中的每个 @HystrixCommand 注解所使用，除非这些属性值在 Java 类级别被设置，或者被类中单个 Hystrix 线程池级别的值覆盖。

Hystrix 确实允许开发人员在类级别设置默认参数，以便特定类中的所有 Hystrix 命令共享相同的配置。类级属性是通过一个名为 @DefaultProperties 的类级注解设置的。例如，如果希望特定类中的所有资源的超时时间均为 10 s，则可以按以下方式设置 @DefaultProperties ：

@DefaultProperties(
    commandProperties = {
        @HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds",
        → value = "10000")}
class MyService { ... }

除非在线程池级别上显式地覆盖，否则所有线程池都将继承应用程序级别的默认属性或类中定义的默认属性。Hystrix 的 threadPoolProperties 和 commandProperties 也绑定到已定义的命令键。

注意

我在本章编码示例的应用程序代码中硬编码了所有的 Hystrix 值。在生产环境中，最有可能需要调整的 Hystrix 数据（超时参数、线程池计数）将被外部化到 Spring Cloud Config。通过这种方式，如果需要更改参数值，就可以在更改完参数值之后重新启动服务实例，而无需重新编译和重新部署应用程序。

对于单个 Hystrix 池，本书将保持配置尽可能接近代码并将线程池配置置于 @HystrixCommand 注解中。表 5-1 总结了用于创建和配置 @HystrixCommand 注解的所有配置值。

表 5-1 @HystrixCommand 注解的配置值

属 性 名 称	默认值	描 述
fallbackMethod	None	标识类中的方法，如果远程调用超时，将调用该方法。回调方法必须与 @HystrixCommand 注解在同一个类中，并且必须具有与调用类相同的方法签名。如果值不存在，Hystrix 会抛出异常
threadPoolKey	None	给予 @HystrixCommand 一个唯一的名称，并创建一个独立于默认线程池的线程池。如果没有定义任何值，则将使用默认的 Hystrix 线程池
threadPoolProperties	None	核心的 Hystrix 注解属性，用于配置线程池的行为
coreSize	1 0	设置线程池的大小
maxQueueSize	− 1	设置线程池前面的最大队列大小。如果设置为−1，则不使用队列，Hystrix 将阻塞请求，直到有一个线程可用来处理
circuitBreaker. requestVolumeThreshold	20	设置 Hystrix 开始检查断路器是否跳闸之前滚动窗口中必须处理的最小请求数 注意：此值只能使用 commandPoolProperties 属性设置
circuitBreaker. errorThresholdPercentage	50	在断路器跳闸之前，滚动窗口内必须达到的故障百分比 注意：此值只能使用 commandPoolProperties 属性设置
circuitBreaker. sleepWindowInMilliseconds	5000	在断路器跳闸之后，Hystrix 尝试进行服务调用之前将要等待的时间（以毫秒为单位） 注意：此值只能使用 commandPoolProperties 属性设置
metricsRollingStats. timeInMilliseconds	10000	Hystrix 收集和监控服务调用的统计信息的滚动窗口（以毫秒为单位）
metricsRollingStats. numBuckets	10	Hystrix 在一个监控窗口中维护的度量桶的数量。监视窗口内的桶数越多，Hystrix 在窗口内监控故障的时间越低