上一章，我讲解Hystrix命令执行流程时，一直提到Hystrix的fallback降级机制，我们先来回顾一下，在哪些情况下会触发降级：
- 断路器处于打开状态，直接走降级流程；
- 线程池/队列/semaphore满了，请求被reject；
- 执行了请求，但是Command的run()或construct()方法抛出异常；
上述三种情况，都属于异常情况，Hystrix会发送异常事件到断路器中去进行统计，如果断路器发现异常事件的占比达到了一定的比例，会直接开启断路，如下图：
接下来，我们通过一个示例来看看如何使用Hystrix的降级机制。
一、降级示例
Fallback降级的逻辑一般写在Command内，一般有两种最经典的降级方法： 纯内存数据 和 默认值 。
举个例子，假如我们现在新增一个品牌服务：当通过商品服务获取到商品信息后，会再根据商品信息中的品牌brandId，调用品牌服务获取品牌信息。如果品牌服务挂掉了，那么我们可以尝试从本地内存中获取一份以前保留的品牌数据，如果内存中没有，可以返回一些默认值，比如Nike++、Nike、Ecco之类的。
降级的逻辑通过HystrixCommand.getFallback或HystrixObservableCommand.resumeWithFallback方法实现：
public class GetBrandCommand extends HystrixCommand<String> {
// 品牌id
private final Long brandId;
public CommandHelloFailure(Long brandId) {
super(HystrixCommandGroupKey.Factory.asKey("BrandInfoService"));
this.brandId = brandId;
}
/**
* 这里总是报错，这样每次请求都会走降级逻辑
*/
@Override
protected String run() {
// 正式场景，这里调用品牌服务的接口
throw new RuntimeException("this command always fails");
}
/**
* 降级逻辑，从本地缓存中查找一个品牌名称
*/
@Override
protected String getFallback() {
return BrandCache.getBrandName(brandId);
}
}
再来改写下整合服务：
@Controller
public class CacheController {
@RequestMapping("/change/product")
@ResponseBody
public String changeProduct(Long productId) {
// 获取商品信息
HystrixCommand<ProductInfo> command = new GetProductInfoCommand(productId);
ProductInfo product = command.execute();
// 获取品牌信息
GetBrandCommand bcmd = new GetBrandCommand(product.getBrandId());
String brandName = bcmd.execute();
product.setBrandName(brandName);
System.out.println(product);
return "success";
}
}
二、总结
Fallback降级机制，本身也使用了资源隔离，我们可以通过fallback.isolation.semaphore.maxConcurrentRequests这个参数设置HystrixCommand.getFallback()的最大允许并发请求数，默认值是10，如果超出了这个最大值，那么直接被reject。
HystrixCommandProperties.Setter()
.withFallbackIsolationSemaphoreMaxConcurrentRequests(int value)
