hystrix使用背景和场景
所有的系统，特别是分布式系统，都会遇到故障，如何构建系统应对这种故障呢？当服务崩溃了，很容易检查这个服务不在了，应用程序很容易绕过他。但一个服务运行很慢，检查到这个服务性能不佳并绕过他非常的困难。性能不佳的服务很容易造成成资源的耗尽（线程池或者数据库的连接），从而影响连锁反应，就是传说中的雪崩现象。因此如果没有一个有效的保护措施，一个性能不佳的服务很容易拖垮整个应用程序。
在远程服务性能不佳时候，客户端的表现直接影响到问题向上游的传播，在hystrix，一共有四种模式
- 客户端负载均衡（client load balance）模式
- 熔断器（circuit breaker）模式
- 后备（fallback）模式
- 舱壁（bulkhead）模式
- 客户端负载均衡已经在eureka中讲到，这里就先不提了
- 熔断器模式
当远程服务被调用时，熔断器会监视这个调用，如果调用时间太长，熔断器将会介入并终止调用；如果某一个远程调用的失败次数足够多，那么熔断器也会快速失败。 - 后备模式
后备模式是指当远程调用失败时，服务消费者将执行替代方法，而不是生成一个异常。 - 舱壁模式
舱壁模式是建立在造船的概念基础之上的，每个远程资源的调用都是隔离的并分配给线程池，如果一个远程服务的响应时间很长，那么这种服务的线程池就会饱和并停止接受请求，然后对其他的远程服务调用不会影响，因为他们被分在不同的线程池中的。这就是舱壁模式。
这些在实际开发中都是非常重要的，也是在生成环境中很容易碰到的问题，也是很多故障直接原因。因此这几个模式是经验之谈。
简单的使用hystrix
- 这里首先搭建一套服务注册和发现，具体可参考上篇文章。
- 添加maven依赖
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-hystrix</artifactId>
</dependency>
- 在spring boot启动类上添加
@EnableCircuitBreaker，表示使用hystrix组件
/**
* 使用hystrix
* 使用注解@EnableCircuitBreaker表示将使用hystrix
*
* @author hui.wang
* @since 15 November 2018
*/
@SpringBootApplication
@EnableDiscoveryClient
@EnableCircuitBreaker
public class ConsumerApplication {
@LoadBalanced
@Bean RestTemplate restTemplate() {
return new RestTemplate();
}
public static void main(String[] args) {
SpringApplication.run(ConsumerApplication.class, args);
}
}
- 简单的使用hystrix
这里我在provider提供的接口模拟了业务超时
@RestController
public class ProviderController {
private final Logger LOGGER = Logger.getLogger(ProviderController.class);
/**
* 这里模拟业务操作
* 随机生成一个数字，如果是偶数，sleep 11s
*/
@RequestMapping(value = "/provider", method = RequestMethod.GET)
public String provider(@RequestParam String request) {
Random random = new Random();
int randomInt = random.nextInt();
if (randomInt % 2 == 0) {
sleep();
}
LOGGER.info("========================================");
LOGGER.info("provider service 被调用");
LOGGER.info("========================================");
return "provider, " + request;
}
private void sleep() {
try {
Thread.sleep(11000);
} catch (InterruptedException e) {
LOGGER.error(e);
}
}
}
接下来，我们再consumer端简单使用hystrix的熔断器模式，后壁模式，舱壁模式
/**
* 对hystrix简单的使用
*
* @author hui.wang
* @since 15 November 2018
*/
@RestController
public class Controller {
private final Logger LOGGER = Logger.getLogger(Controller.class);
@Autowired
private RestTemplate restTemplate;
/**
* 简单使用hystrix的熔断器模式
* 使用注解@HystrixCommand，默认超时时间为1000ms，超时将快速失败
*/
@HystrixCommand
@RequestMapping("/consumer/v1")
public String consumerV1() {
return restTemplate.getForEntity("http://provider-server/provider?request={1}", String.class, "test").getBody();
}
/**
* 定制熔断器的超时时间
* 通过commandProperties属性定制熔断器的行为
* 这里将熔断器超时时间设为12000ms
*/
@HystrixCommand(
commandProperties = {
@HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds", value = "120000")
}
)
@RequestMapping("/consumer/v2")
public String consumerV2() {
return restTemplate.getForEntity("http://provider-server/provider?request={1}", String.class, "test").getBody();
}
/**
* 简单使用hystrix的后备模式
* 在@HystrixCommand指定fallbackMethod值，就可以在调用失败后，调用fallbackMethod指定的方法了
*/
@HystrixCommand(fallbackMethod = "fallback")
@RequestMapping("/consumer/v3")
public String consumerV3() {
return restTemplate.getForEntity("http://provider-server/provider?request={1}", String.class, "test").getBody();
}
private String fallback() {
return "invoke error";
}
/**
* 简单使用hystrix的舱壁模式
* Hystrix使用threadPoolKey属性值搭建一个线程池，
* 并使用threadPoolProperties中的属性值对线程池配置
*/
@HystrixCommand(fallbackMethod = "fallback",
threadPoolKey = "consumer-v4",
threadPoolProperties = {
@HystrixProperty(name = "coreSize", value = "30"),
@HystrixProperty(name = "maxQueueSize", value = "10")
}
)
@RequestMapping("/consumer/v4")
public String consumerV4() {
return restTemplate.getForEntity("http://provider-server/provider?request={1}", String.class, "test").getBody();
}
}
上面对这几种模式进行了简单的使用，这里就不在说明
Hystrix的配置
-
execution.isolation.strategy表示隔离策略，隔离策略有两种，一种为线程隔离一种为信号量隔离 -
execution.isolation.thread.timeoutInMilliseconds表示请求线程总超时时间 -
execution.timeout.enabled这个超时开关表示，当超时后是否触发fallback方法 -
execution.isolation.semaphore.maxConcurrentRequests当隔离策略使用SEMAPHORE时，最大的并发请求量，如果请求超过这个最大值将拒绝后续的请求，默认值为10. -
fallbackMethod表示当触发隔离条件的时候会调用fallback设置的降级方法，这里需要注意的是降级方法的入参和返回值需要和原方法一致，否则在编译的时候会报错。 -
circuitBreaker.requestVolumeThreshold熔断器在整个统计时间内是否开启的阀值，每个熔断器默认维护10个bucket,每秒一个bucket,每个bucket记录成功,失败,超时,拒绝的状态，该阈值默认20次。也就是一个统计窗口时间内（10秒钟）至少请求20次，熔断器才启动。 -
circuitBreaker.sleepWindowInMilliseconds熔断器默认工作时间,默认值为5秒.熔断器中断请求5秒后会进入半打开状态,放部分流量过去重试，如果重试成功则会恢复正常请求。 -
circuitBreaker.errorThresholdPercentage熔断器错误阈值，默认为50%。当在一个时间窗口内出错率超过50%后熔断器自动启动。 -
circuitBreaker.forceOpen熔断器强制开关，如果设置为true则表示强制打开熔断器，所有请求都会拒绝，默认为false。
ThreadPool Properties
-
coreSize线程池核心线程数，默认值为10，这里的含义和jdk的线程池一个意思。 -
maxQueueSize该参数表示配置线程值等待队列长度,默认值:-1，建议值:-1表示不等待直接拒绝,测试表明线程池使用直接决绝策略+ 合适大小的非回缩线程池效率最高.所以不建议修改此值。 当使用非回缩线程池时，queueSizeRejectionThreshold,keepAliveTimeMinutes 参数无效。 -
queueSizeRejectionThreshold表示等待队列超过阈值后开始拒绝线程请求，默认值为5，如果maxQueueSize为1，则该属性失效。
