SpringCloud与NetflixHystrix的客户端弹性模式深入解析

### Spring Cloud与Netflix Hystrix的客户端弹性模式深入解析 在分布式系统中，客户端弹性模式对于确保系统的稳定性和可靠性至关重要。Spring Cloud与Netflix Hystrix提供了一系列强大的工具和策略来应对各种异常情况，下面将详细介绍Hystrix的配置、线程上下文管理等关键内容。 #### 1. Hystrix配置详解 Hystrix库具有极高的可配置性，能够让我们精确控制使用它定义的断路器和舱壁模式的行为。通过修改Hystrix断路器的配置，我们可以控制以下几个方面： - **远程调用超时时间**：可以设置Hystrix在远程调用超时时等待的时间。 - **断路器触发和重置行为**：控制断路器何时触发以及何时尝试重置。 此外，Hystrix还允许我们通过为每个远程服务调用定义单独的线程组，并配置与每个线程组关联的线程数量，来微调舱壁实现。这样做的好处是可以根据不同远程服务调用的流量大小进行优化。 Hystrix的配置分为三个级别： 1. **整个应用的默认配置**：应用中所有的`@HystrixCommand`注解默认会使用这些配置。 2. **类级别的默认配置**：可以通过`@DefaultProperties`注解为特定类中的所有Hystrix命令设置相同的配置。例如，如果希望特定类中的所有资源都有10秒的超时时间，可以这样设置： ```java @DefaultProperties( commandProperties = { @HystrixProperty( name = "execution.isolation.thread.timeoutInMilliseconds", value = "10000") } ) class MyService { ... } ``` 3. **类中定义的线程池级别配置**：除非在线程池级别明确覆盖，否则所有线程池将继承应用级别的默认属性或类中定义的默认属性。 在生产系统中，为了方便修改Hystrix的配置参数（如超时参数、线程池数量），建议将这些数据外部化到Spring Cloud Config中。这样，在需要更改参数值时，只需修改配置并重启服务实例，而无需重新编译和部署应用。 为了更方便地配置`@HystrixCommand`注解，下面是一个配置值的总结表格： | 属性名称 | 默认值 | 描述 | | --- | --- | --- | | fallbackMethod | None | 当远程调用超时时，将调用类中的此方法。回调方法必须与`@HystrixCommand`注解在同一个类中，并且具有相同的方法签名。如果未设置该值，Hystrix将抛出异常。 | | threadPoolKey | None | 为`@HystrixCommand`提供一个唯一的名称，并创建一个独立于默认线程池的线程池。如果未定义该值，将使用默认的Hystrix线程池。 | | threadPoolProperties | None | 用于配置线程池行为的核心Hystrix注解属性。 | | coreSize | 10 | 设置线程池的大小。 | | maxQueueSize | -1 | 设置在线程池前的最大队列大小。如果设置为 -1，则不使用队列，而是Hystrix将阻塞直到有线程可用于处理。 | | circuitBreaker.requestVolumeThreshold | 20 | 设置在Hystrix开始检查断路器是否应触发之前，滚动窗口内必须处理的最小请求数。此值只能通过`commandPoolProperties`属性设置。 | | circuitBreaker.errorThresholdPercentage | 50 | 设置在断路器触发之前，滚动窗口内必须发生的失败百分比。此值只能通过`commandPoolProperties`属性设置。 | | circuitBreaker.sleepWindowInMilliseconds | 5,000 | 设置断路器触发后，Hystrix在尝试进行服务调用之前等待的毫秒数。此值只能通过`commandPoolProperties`属性设置。 | | metricsRollingStats.timeInMilliseconds | 10,000 | 设置Hystrix在一个窗口内收集和监控服务调用统计信息的毫秒数。 | | metricsRollingStats.numBuckets | 10 | 设置Hystrix在其监控窗口内维护的指标桶数量。监控窗口内的桶越多，Hystrix监控窗口内故障的时间粒度就越低。 | #### 2. 线程上下文与Hystrix 当执行`@HystrixCommand`时，可以使用两种不同的隔离策略：`THREAD`和`SEMAPHORE`。默认情况下，Hystrix使用`THREAD`隔离策略。 - **THREAD隔离**：每个用于保护调用的Hystrix命令在一个独立的线程池中运行，与发起调用的父线程不共享上下文。这意味着Hystrix可以中断其控制下的线程执行，而不用担心会中断发起原始调用的父线程的任何其他活动。 - **SEMAPHORE隔离**：Hystrix在不启动新线程的情况下管理由`@HystrixCommand`注解保护的分布式调用。如果调用超时，将中断父线程。在同步容器服务器环境（如Tomcat）中，中断父线程会导致抛出一个开发者无法捕获的异常，这可能会给开发者带来意想不到的后果。 要控制命令池的隔离设置，可以在`@HystrixCommand`注解上设置`commandProperties`属性。例如，如果要将Hystrix命令的隔离级别设置为`SEMAPHORE`隔离，可以这样做： ```java @HystrixCommand( commandProperties = { @HystrixProperty( name="execution.isolation.strategy", value="SEMAPHORE" ) } ) ``` 默认情况下，Hystrix团队建议大多数命令使用`THREAD`隔离策略，因为它能提供更高的隔离级别。不过，`SEMAPHORE`隔离模型更轻量级，适用于服务流量大且运行在异步I/O编程模型（如使用Netty等异步I/O容器）的场景。 #### 3. ThreadLocal与Hystrix 默认情况下，Hystrix不会将父线程的上下文传播到由Hystrix命令管理的线程中。例如，在父线程中设置为`ThreadLocal`的值，默认情况下在由父线程调用并由`@HystrixCommand`对象保护的方法中是不可用的（前提是使用`THREAD`隔离级别）。 在REST环境中，我们通常希望将上下文信息（如关联ID或认证令牌）传递给服务调用，以便进行服务的操作管理。可以使用Spring Filter类来拦截每个进入REST服务的调用，从传入的HTTP请求中检索这些信息，并将其存储在自定义的`UserContext`对象中。以下是一个示例Spring Filter： ```java package com.thoughtmechanix.licenses.utils; //Some code removed for conciseness @Component public class UserContextFilter implements Filter { private static final Logger logger = LoggerFactory.getLogger(UserContextFilter.class); @Override public void doFilter( ServletRequest servletRequest, ServletResponse servletResponse, FilterChain filterChain ) throws IOException, ServletException { HttpServletRequest httpServletRequest = (HttpServletRequest) servletRequest; UserContextHolder .getContext() .setCorrelationId( httpServletRequest.getHeader(UserContext.CORRELATION_ID) ); UserContextHolder .getContext() .setUserId( httpServletRequest.getHeader(UserContext.USER_ID) ); UserContextHolder .getContext() .setAuthToken( httpServletRequest.getHeader(UserContext.AUTH_TOKEN) ); UserContextHolder .getContext() .setOrgId( httpServletRequest.getHeader(UserContext.ORG_ID) ); filterChain.doFilter(httpServletRequest, servletResponse); } } ``` `UserContextHolder`类用于将`UserContext`存储在`ThreadLocal`类中。以下是`UserContextHolder`类的代码： ```java public class UserContextHolder { private static final ThreadLocal<UserContext> userContext = new ThreadLocal<UserContext>(); public static final UserContext getContext(){ UserContext context = userContext.get(); if (context == null) { context = createEmptyContext(); userContext.set(context); } return userContext.get(); } public static final void setContext(UserContext context) { Assert.notNull(context, "Only non-null UserContext instances are permitted"); userContext.set(context); } public static final UserContext createEmptyContext(){ return new UserContext(); } } ``` 为了验证上下文信息的传递情况，可以在许可服务的以下类和方法中添加日志记录： - `com/thoughtmechanix/licenses/utils/UserContextFilter.java`的`doFilter()`方法 - `com/thoughtmechanix/licenses/controllers/LicenseServiceController.java`的`getLicenses()`方法 - `com/thoughtmechanix/licenses/services/LicenseService.java`的`getLicensesByOrg()`方法（该方法使用了`@HystrixCommand`注解） 然后，通过HTTP头传递关联ID（如`tmx-correlation-id`，值为`TEST-CORRELATION-ID`）调用服务。当调用到达`LicenseService.getLicensesByOrder()`这个由Hystrix保护的方法时，会发现关联ID的值无法输出。不过，Hystrix和Spring Cloud提供了一种机制，即`HystrixConcurrencyStrategy`，可以将父线程的上下文传播到由Hystrix线程池管理的线程中。 #### 4. HystrixConcurrencyStrategy的实现步骤 要实现自定义的`HystrixConcurrencyStrategy`，需要完成以下三个步骤： ##### 4.1 定义自定义的Hystrix并发策略类 首先，需要定义自己的`HystrixConcurrencyStrategy`类。由于Spring Cloud已经定义了一个用于处理Spring安全信息传播的并发策略，因此在实现自定义策略时，需要确保正确调用现有的Spring Cloud