Hystrix基础
分布式系统环境下，服务间类似依赖非常常见，一个业务调用通常依赖多个基础服务。例如当库存服务不可用时，商品服务请求线程被阻塞，当有大批量请求调用库存服务时，最终可能导致整个商品服务资源耗尽，无法继续对外提供服务。并且这种不可用可能沿请求调用链向上传递，造成整个集群服务的不可用。这种现象被称为雪崩效应。
因此，微服务架构中我们需要提供一些服务调用的保护机制，用于快速处理依赖故障。Hystrix是一个提供了服务隔离，快速失败和服务限流的组件。它的设计原则如下：
- 在复杂的分布式系统中，阻止某一个依赖服务的故障在整个系统中蔓延。比如某一个服务故障了，导致其它服务也跟着故障。
- 对依赖服务调用时的调用失败进行控制和容错保护
- 支持快速失败和快速恢复。快速失败是指当服务不可用时，服务调用能够快速返回一个默认结果（即fallback机制）。快速恢复是指当服务重新恢复可用时，Hystrix能够快速成功调用服务。
- 避免请求排队和积压，采用限流和 fail fast 来控制故障
- 支持近实时的监控、报警以及运维操作
1. 资源隔离
Hystrix提供的一项核心功能，即资源隔离。资源隔离要解决的最最核心的问题，就是将多个依赖服务的调用分别隔离到各自的资源池内。避免说对某一个依赖服务的调用，因为依赖服务的接口调用的延迟或者失败，导致服务所有的线程资源全部耗费在这个服务的接口调用上。一旦说某个服务的线程资源全部耗尽的话，就可能导致服务崩溃，甚至说这种故障会不断蔓延。
Hystrix 实现资源隔离，主要有两种技术：线程池和信号量。默认情况下，Hystrix 使用线程池模式。
下面是使用线程池模式的例子：
public class GetProductInfoCommand extends HystrixCommand<ProductInfo> {
private Long productId;
private static final HystrixCommandKey KEY = HystrixCommandKey.Factory.asKey("GetProductInfoCommand");
public GetProductInfoCommand(Long productId) {
super(Setter.withGroupKey(HystrixCommandGroupKey.Factory.asKey("ProductInfoService"))
.andCommandKey(KEY)
// 线程池相关配置信息
.andThreadPoolPropertiesDefaults(HystrixThreadPoolProperties.Setter()
// 设置线程池大小为8
.withCoreSize(8)
// 设置等待队列大小为10
.withMaxQueueSize(10)
.withQueueSizeRejectionThreshold(12))
.andCommandPropertiesDefaults(HystrixCommandProperties.Setter()
.withCircuitBreakerEnabled(true)
.withCircuitBreakerRequestVolumeThreshold(20)
.withCircuitBreakerErrorThresholdPercentage(40)
.withCircuitBreakerSleepWindowInMilliseconds(3000)
// 设置超时时间
.withExecutionTimeoutInMilliseconds(20000)
// 设置fallback最大请求并发数
.withFallbackIsolationSemaphoreMaxConcurrentRequests(30)));
this.productId = productId;
}
@Override
protected ProductInfo run() throws Exception {
System.out.println("调用接口查询商品数据，productId=" + productId);
if (productId == -1L) {
throw new Exception();
}
// 请求过来，会在这里hang住3秒钟
if (productId == -2L) {
TimeUtils.sleep(3);
}
String url = "http://localhost:8081/getProductInfo?productId=" + productId;
String response = HttpClientUtils.sendGetRequest(url);
System.out.println(response);
return JSONObject.parseObject(response, ProductInfo.class);
}
@Override
protected ProductInfo getFallback() {
ProductInfo productInfo = new ProductInfo();
productInfo.setName("降级商品");
return productInfo;
}
}
服务调用时，通过构造Command实例进行调用：
@RequestMapping("/getProductInfo")
@ResponseBody
public String getProductInfo(Long productId) {
HystrixCommand<ProductInfo> getProductInfoCommand = new GetProductInfoCommand(productId);
// 通过command执行，获取最新商品数据
ProductInfo productInfo = getProductInfoCommand.execute();
System.out.println(productInfo);
return "success";
}
我们可以看到，Hystrix的使用模式是通过构造一个Command对象，通过实现run()方法实现调用逻辑，通过实现getFallback()方法实现降级返回（即服务调用失败时的默认返回）。
而在构造函数中，通过设置线程池大小和阻塞队列大小，我们轻松的实现了资源隔离和接口限流的功能。
线程池其实最大的好处就是对于网络访问请求，如果有超时的话，可以避免调用线程阻塞住。
使用信号量隔离的例子如下：
public class GetCityNameCommand extends HystrixCommand<String> {
private Long cityId;
public GetCityNameCommand(Long cityId) {
// 设置信号量隔离策略
super(Setter.withGroupKey(HystrixCommandGroupKey.Factory.asKey("GetCityNameGroup"))
.andCommandPropertiesDefaults(HystrixCommandProperties.Setter()
.withExecutionIsolationStrategy(HystrixCommandProperties.ExecutionIsolationStrategy.SEMAPHORE)))
.withExecutionIsolationSemaphoreMaxConcurrentRequests(10);
this.cityId = cityId;
}
@Override
protected String run() {
// 需要进行信号量隔离的代码
return LocationCache.getCityName(cityId);
}
}
信号量隔离无法处理类似线程池隔离中的异步网络调用和timeout等情形。
线程池隔离和信号量隔离的对比：
- 线程池技术，适合绝大多数场景，比如说我们对依赖服务的网络请求的调用和访问、需要对调用的 timeout 进行控制（捕捉 timeout 超时异常）。
- 信号量技术，适合说你的访问不是对外部网络服务的调用，而是对内部的一些比较复杂的业务逻辑的访问。并且系统内部的代码，其实不涉及任何的网络请求，那么只要做信号量的普通限流就可以了，因为不需要去捕获 timeout 类似的问题。
2. 断路器
断路器是Hystrix中控制服务调用快速失败和恢复的组件。它的工作模式如下：
- 正常情况下，断路器关闭，服务消费者正常请求微服务
- 一段事件内，失败率达到一定阈值（比如50%失败），断路器将断开，此时不再请求服务提供者，而是只是快速失败的方法（断路方法）
- 断路器打开一段时间，自动进入“半开”状态，此时，断路器可允许一个请求方法服务提供者，如果请求调用成功，则关闭断路器，否则继续保持断路器打开状态。
下面是Hystrix一个Command的执行流程：
Hystrix调用流程.PNG
下面是断路器的配置示例：
public GetProductInfoCommand(Long productId) {
super(Setter.withGroupKey(HystrixCommandGroupKey.Factory.asKey("ProductInfoService"))
.andCommandKey(KEY)
.andCommandPropertiesDefaults(HystrixCommandProperties.Setter()
// 是否允许断路器工作
.withCircuitBreakerEnabled(true)
// 滑动窗口中，最少有多少个请求，才可能触发断路
.withCircuitBreakerRequestVolumeThreshold(20)
// 异常比例达到多少，才触发断路，默认50%
.withCircuitBreakerErrorThresholdPercentage(40)
// 断路后多少时间内直接reject请求，之后进入half-open状态，默认5000ms
.withCircuitBreakerSleepWindowInMilliseconds(3000)));
this.productId = productId;
}
3. Request Cache
首先，有一个概念，叫做 Request Context 请求上下文，一般来说，在一个 web 应用中，如果我们用到了 Hystrix，我们会在一个 filter 里面，对每一个请求都施加一个请求上下文。就是说，每一次请求，就是一次请求上下文。然后在这次请求上下文中，我们会去执行 N 多代码，调用 N 多依赖服务，有的依赖服务可能还会调用好几次。
在一次请求上下文中，如果有多个 command，参数都是一样的，调用的接口也是一样的，而结果可以认为也是一样的。那么这个时候，我们可以让第一个 command 执行返回的结果缓存在内存中，然后这个请求上下文后续的其它对这个依赖的调用全部从内存中取出缓存结果就可以了。
这样的话，好处在于不用在一次请求上下文中反复多次执行一样的 command，避免重复执行网络请求，提升整个请求的性能。
举个栗子。比如说我们在一次请求上下文中，请求获取 productId 为 1 的数据，第一次缓存中没有，那么会从商品服务中获取数据，返回最新数据结果，同时将数据缓存在内存中。后续同一次请求上下文中，如果还有获取 productId 为 1 的数据的请求，直接从缓存中取就好了。
注意，Request Cache的使用是针对同一个请求上下文而言的。
4. 降级
Hystrix 出现以下四种情况，都会去调用 fallback 降级机制：
- 断路器处于打开的状态。
- 资源池已满（线程池+队列 / 信号量）。
- Hystrix 调用各种接口，或者访问外部依赖，比如 MySQL、Redis、Zookeeper、Kafka 等等，出现了任何异常的情况。
- 访问外部依赖的时候，访问时间过长，报了 TimeoutException 异常。
两种最经典的降级机制
-
纯内存数据
在降级逻辑中，你可以在内存中维护一个 ehcache，作为一个纯内存的基于 LRU 自动清理的缓存，让数据放在缓存内。如果说外部依赖有异常，fallback 这里直接尝试从 ehcache 中获取数据。 -
返回默认值
fallback 降级逻辑中，也可以直接返回一个默认值。
