Spring Cloud Hystrix服务容错

|   Visit count

在微服务的架构中，服务间通常会形成相互依赖的关系，比如现在有三个微服务节点：A，B和C，B为A的消费者，C为B的消费者。假如由于网络波动或者A服务自身故障，导致B调用A服务的线程被挂起进入长时间的等待。在高并发的情况下可能导致B的资源被耗竭随之崩溃，从而导致C服务也不可用。这种连环式的雪崩效应在微服务中较为常见，为了解决这个问题，服务熔断技术应运而出。熔断一词来自电路学，指的是电路在出现短路状况时，“断路器”能够及时地切断故障电路，避免电路过载发热引发火灾。

类似的，微服务架构中的断路器能够及时地发现故障服务，并向服务调用方返回错误响应，而不是长时间的等待。Spring Cloud Hystrix在Hystrix（又是一款由Netflix开发的开源软件，Github地址https://github.com/Netflix/Hystrix）的基础上进行了封装，提供了服务熔断，服务降级，线程隔离等功能，通过这些功能可以提供服务的容错率。

使用Hystrix

这里将在上一节Spring Cloud Ribbon客户端负载均衡源码的基础上配置Hystrix。

我们先看下在没有配置Hystrix之前，关闭Eureka-Client是什么效果。

分别使用peer1和peer2配置启动Eureka-Server集群，然后启动两个Eureka-Client实例，端口分别为8082和8083，最后启动Ribbon-Consumer。准备完毕后，我们关闭端口为8082的Eureka-Client，然后发送GET请求http://localhost:9000/user/1，返回结果如下：

QQ截图20180710151846.png

下面开始使用使用Spring Cloud Hystrix，在项目Ribbon-Consumer中引入Spring Cloud Hystrix依赖：

1
2
3
4
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-hystrix</artifactId>
</dependency>

在入口类上加入@EnableHystrix或者@EnableCircuitBreaker注解。这两个注解是等价的，查看@EnableHystrix注解源码就可以证实这一点：

1
2
3
4
5
6
7
@Target({ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Inherited
@EnableCircuitBreaker
public @interface EnableHystrix {
}

在引入@EnableHystrix或者@EnableCircuitBreaker注解后，我们的入口类代码如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
@EnableCircuitBreaker
@EnableDiscoveryClient
@SpringBootApplication
public class DemoApplication {
    @Bean
    @LoadBalanced
    RestTemplate restTemplate() {
        return new RestTemplate();
    }
    public static void main(String[] args) {
        SpringApplication.run(DemoApplication.class, args);
    }
}

入口类上总共包含了三个注解@EnableCircuitBreaker、@EnableDiscoveryClient和@SpringBootApplication，这三个注解的组合可以使用@SpringCloudApplication来代替，@SpringCloudApplication源码如下：

1
2
3
4
5
6
7
8
9
@Target({ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Inherited
@SpringBootApplication
@EnableDiscoveryClient
@EnableCircuitBreaker
public @interface SpringCloudApplication {
}

接着将UserController中的方法提取出来，创建一个UserService（为了简单起见，不再创建Service接口）：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
@Service("userService")
public class UserService {
    private Logger log = LoggerFactory.getLogger(this.getClass());

    @Autowired
    private RestTemplate restTemplate;

    public User getUser(@PathVariable Long id) {
        return restTemplate.getForObject("http://Server-Provider/user/{id}", User.class, id);
    }

    public List<User> getUsers() {
        return this.restTemplate.getForObject("http://Server-Provider/user", List.class);
    }

    public String addUser() {
        User user = new User(1L, "mrbird", "123456");
        HttpStatus status = this.restTemplate.postForEntity("http://Server-Provider/user", user, null).getStatusCode();
        if (status.is2xxSuccessful()) {
            return "新增用户成功";
        } else {
            return "新增用户失败";
        }
    }

    public void updateUser() {
        User user = new User(1L, "mrbird", "123456");
        this.restTemplate.put("http://Server-Provider/user", user);
    }

    public void deleteUser(@PathVariable Long id) {
        this.restTemplate.delete("http://Server-Provider/user/{1}", id);
    }
}

接着改造UserService的getUser方法：

1
2
3
4
5
6
7
8
9
10
11
@HystrixCommand(fallbackMethod = "getUserDefault")
public User getUser(@PathVariable Long id) {
   return restTemplate.getForObject("http://Server-Provider/user/{id}", User.class, id);
}
public User getUserDefault(Long id) {
    User user = new User();
    user.setId(-1L);
    user.setUsername("defaultUser");
    user.setPassword("123456");
    return user;
}

我们在getUser方法上加入了@HystrixCommand注解，注解的fallbackMethod属性指定了被调用的方法不可用时的回调方法（服务熔断时的回调处理逻辑，即服务降级），这里为getUserDefault方法（必须与getUser方法的参数及返回值类型一致）。

在UserController中调用UserService的getUser方法：

1
2
3
4
5
6
7
8
9
10
11
12
@RestController
public class TestController {
    private Logger log = LoggerFactory.getLogger(this.getClass());

    @Autowired
    private UserService userService;

    @GetMapping("user/{id}")
    public User getUser(@PathVariable Long id) {
        return userService.getUser(id);
    }
}

修改完后启动Ribbon-Consumer并重重新启动8082端口的Eureka-Client，发送数次GET请求http://localhost:9000/user/1后，再次关闭8082端口的Eureka-Client。

断开后，继续发送GET请求http://localhost:9000/user/1，当轮询到8082端口时返回数据如下图所示：

QQ截图20180710154714.png

可以看到，当轮询到服务不可用时，触发了熔断机制，接口回调了fallbackMethod指定的方法。

我们也可以模拟服务超时的情况，可以在Eureka-Client提供的接口方法中设置线程等待，等待时间大于2000（Hystrix默认超时时间为2000 毫秒）即可触发调用方Ribbon-Consumer的服务熔断。

@HystrixCommand详解

@HystrixCommand注解还包含许多别的属性功能，下面介绍一些常用的属性配置。

服务降级

上面TestController中的getUser中我们用@HystrixCommand注解指定了服务降级方法getUserDefault。如果getUserDefault方法也抛出异常，那么我们可以再次使用@HystrixCommand注解指定getUserDefault方法降级的方法，比如定义一个getUserDefault2方法：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
@HystrixCommand(fallbackMethod = "getUserDefault2")
public User getUserDefault(Long id) {
    String a = null;
    // 测试服务降级
    a.toString();
    User user = new User();
    user.setId(-1L);
    user.setUsername("defaultUser");
    user.setPassword("123456");
    return user;
}

public User getUserDefault2(Long id) {
    User user = new User();
    user.setId(-2L);
    user.setUsername("defaultUser2");
    user.setPassword("123456");
    return user;
}

重启Ribbon-Consumer，并关闭8082端口的Eureka Client服务，访问http://localhost:9000/user/1：

QQ截图20180712112335.png

异常处理

在使用@HystrixCommand注解标注的方法中，除了HystrixBadRequestException异常外，别的异常都会触发服务降级。假如我们想指定某个异常不触发服务降级，可以使用@HystrixCommand注解的ignoreExceptions属性进行忽略。如：

1
2
3
4
5
6
7
8
9
10
11
12
@HystrixCommand(fallbackMethod = "getUserDefault2", ignoreExceptions = {NullPointerException.class})
public User getUserDefault(Long id) {
    String a = null;
    // 测试服务降级
    a.toString();
    User user = new User();
    user.setId(-1L);
    user.setUsername("defaultUser");
    user.setPassword("123456");
    throw new HystrixBadRequestException()
    return user;
}

此外，对于方法抛出的异常信息，我们可以在服务降级的方法中使用Throwable对象获取，如：

1
2
3
4
5
6
7
8
9
@HystrixCommand(fallbackMethod = "getUserDefault2")
public User getUserDefault(Long id, Throwable e) {
    System.out.println(e.getMessage());
    User user = new User();
    user.setId(-2L);
    user.setUsername("defaultUser2");
    user.setPassword("123456");
    return user;
}

命名与分组

通过指定@HystrixCommand注解的commandKey、groupKey以及threadPoolKey属性可以设置命令名称、分组以及线程池划分，如：

1
2
3
4
5
6
@HystrixCommand(fallbackMethod = "getUserDefault", commandKey = "getUserById", groupKey = "userGroup",
        threadPoolKey = "getUserThread")
public User getUser(@PathVariable Long id) {
	log.info("获取用户信息");
    return restTemplate.getForObject("http://Server-Provider/user/{id}", User.class, id);
}

上面的配置指定了命令的名称为getUserById，组名为userGroup，线程池名称为getUserThread。

通过设置命令组，Hystrix会根据组来组织和统计命令的告警、仪表盘等信息。默认情况下，Hystrix命令通过组名来划分线程池，即组名相同的命令放到同一个线程池里，如果通过threadPoolKey设置了线程池名称，则按照线程池名称划分。

当getUser方法被调用时，日志打印如下：

1
2018-06-06 15:32:55.945  INFO 16192 --- [getUserThread-1] com.example.demo.Service.UserService  : 获取用户信息

可看到线程名称为getUserThread-1。

Hystrix缓存

我们在Controller中调用三次getUser方法，参数都为1L：

1
2
3
4
5
6
7
8
9
10
11
12
13
@RestController
public class TestController {

    @Autowired
    private UserService userService;

    @GetMapping("testCache")
    public void testCache(){
        userService.getUser(1L);
        userService.getUser(1L);
        userService.getUser(1L);
    }
}

当访问http://localhost:9000/testCache时，控制台输出如下： QQ截图20180712173742.png

开启缓存可以让getUser方法只被调用一次，剩下两次直接从缓存里获取。

开启缓存

要在Hystrix中开启缓存很简单，只需使用@CacheResult注解即可，修改UserService的getUser方法：

1
2
3
4
@CacheResult
public User getUser(@PathVariable Long id) {
    return restTemplate.getForObject("http://Server-Provider/user/{id}", User.class, id);
}

通过上面的设定，Hystrix会将返回的User对象进行缓存，缓存的key默认为方法的所有参数，这里只有一个id参数，所以缓存的key为用户id。

这里在测试的时候遇到一个异常：

java.lang.IllegalStateException: Request caching is not available. Maybe you need to initialize the HystrixRequestContext? at com.netflix.hystrix.HystrixRequestCache.get(HystrixRequestCache.java:104) ~[hystrix-core-1.5.12.jar:1.5.12] at com.netflix.hystrix.AbstractCommand$7.call(AbstractCommand.java:478) ~[hystrix-core-1.5.12.jar:1.5.12] at com.netflix.hystrix.AbstractCommand$7.call(AbstractCommand.java:454) ~[hystrix-core-1.5.12.jar:1.5.12] …

在Hystrix的issue中找到了类似的提问：https://github.com/Netflix/Hystrix/issues/1314。

大致意思是在使用Hytrix缓存之前，需要通过HystrixRequestContext.initializeContext初始化Hystrix请求上下文，请求结束之后需要调用shutdown方法关闭请求。

所以我们可以定义一个过滤器来实现这个过程：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
@Component
@WebFilter(filterName = "hystrixRequestContextServletFilter", urlPatterns = "/*", asyncSupported = true)
public class HystrixRequestContextServletFilter implements Filter {
    @Override
    public void init(FilterConfig filterConfig) {
    }

    @Override
    public void doFilter(ServletRequest servletRequest, ServletResponse servletResponse, FilterChain filterChain) throws IOException, ServletException {
        HystrixRequestContext context = HystrixRequestContext.initializeContext();
        filterChain.doFilter(servletRequest, servletResponse);
        context.close();
    }

    @Override
    public void destroy() {
    }
}

到这里，我才意识到，其实Hystrix的缓存还是蛮鸡肋的，请求缓存不是只写入一次结果就不再变化的，而是每次请求到达Controller的时候，我们都需要为HystrixRequestContext进行初始化，之前的缓存也就是不存在了，我们是在同一个请求中保证结果相同，同一次请求中的第一次访问后对结果进行缓存，缓存的生命周期只有一次请求！

改造完毕后，重启项目再次访问http://localhost:9000/testCache，控制台输出如下：

QQ截图20180712181439.png

设定key值

我们也可以明确的指定缓存的key值是什么。指定key的值有两种方式：

  1. 通过@CacheKey注解指定，如：

    1
    2
    3
    4
    5
    6
    7
    @CacheResult
    @HystrixCommand(fallbackMethod = "getUserDefault", commandKey = "getUserById", groupKey = "userGroup",
            threadPoolKey = "getUserThread")
    public User getUser(@CacheKey("id") @PathVariable Long id) {
        log.info("获取用户信息");
        return restTemplate.getForObject("http://Server-Provider/user/{id}", User.class, id);
    }

    也可以指定参数对象内部属性为key值：

    1
    2
    3
    4
    5
    6
    7
    @CacheResult
    @HystrixCommand(fallbackMethod = "getUserDefault", commandKey = "getUserById", groupKey = "userGroup",
            threadPoolKey = "getUserThread")
    public User getUser(@CacheKey("id") User user) {
        log.info("获取用户信息");
        return restTemplate.getForObject("http://Server-Provider/user/{id}", User.class, user.getId());
    }

  2. 通过方法来指定，方法的返回值必须是String类型：

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    public String getCacheKey(Long id) {
        return String.valueOf(id);
    }

    @CacheResult(cacheKeyMethod = "getCacheKey")
    @HystrixCommand(fallbackMethod = "getUserDefault", commandKey = "getUserById", groupKey = "userGroup",
            threadPoolKey = "getUserThread")
    public User getUser(Long id) {
        log.info("获取用户信息");
        return restTemplate.getForObject("http://Server-Provider/user/{id}", User.class, id);
    }

值得注意的是，方法2的优先级比方法1高。

缓存清除

在涉及到更新User信息的方法上，我们要及时的清除相应的缓存，否则将会导致缓存数据和实际数据不一致的问题。我们在UserService的updateUser方法上做缓存清除操作：

1
2
3
4
5
@CacheRemove(commandKey = "getUserById")
@HystrixCommand
public void updateUser(@CacheKey("id") User user) {
    this.restTemplate.put("http://Server-Provider/user", user);
}

@CacheRemove的commandKey属性和getUser里定义的一致。

请求合并

请求合并就是将多个单个请求合并成一个请求，去调用服务提供者，从而降低服务提供者负载的，一种应对高并发的解决办法。

Hystrix中提供了一个@HystrixCollapser注解，该注解可以将处于一个很短的时间段（默认10 毫秒）内对同一依赖服务的多个请求进行整合并以批量方式发起请求。为了演示@HystrixCollapser注解的使用方法，我们改造下Eureka-Client（服务提供者）的UserController接口，提供一个批量处理的方法：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
@RestController
@RequestMapping("user")
public class UserController {
    private Logger log = LoggerFactory.getLogger(this.getClass());

    @GetMapping("users")
    public List<User> get(String ids) {
        log.info("批量获取用户信息");
        List<User> list = new ArrayList<>();
        for (String id : ids.split(",")) {
            list.add(new User(Long.valueOf(id), "user" + id, "123456"));
        }
        return list;
    }
    ...
}

然后在Ribbon-Consumer的UserService里添加两个方法：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
@HystrixCollapser(batchMethod = "findUserBatch", collapserProperties = {
        @HystrixProperty(name = "timerDelayInMilliseconds", value = "100")
})
public Future<User> findUser(Long id) {
    log.info("获取单个用户信息");
    return new AsyncResult<User>() {
        @Override
        public User invoke() {
            return restTemplate.getForObject("http://Server-Provider/user/{id}", User.class, id);
        }
    };
}

@HystrixCommand
public List<User> findUserBatch(List<Long> ids) {
    log.info("批量获取用户信息,ids: " + ids);
    User[] users = restTemplate.getForObject("http://Server-Provider/user/users?ids={1}", User[].class, StringUtils.join(ids, ","));
    return Arrays.asList(users);
}

@HystrixCollapser注解的batchMethod属性指定了批量处理的方法为下面定义的findUserBatch方法，timerDelayInMilliseconds的值为100（毫秒），意思是在100毫秒这个时间范围内的所有对findUser的调用，都将被合并为一个批量处理操作，进行批量处理操作的方法就是findUserBatch。

我们在TestController中添加一个测试方法：

1
2
3
4
5
6
7
8
9
10
11
12
@GetMapping("testRequestMerge")
public void testRequerstMerge() throws InterruptedException, ExecutionException {
    Future<User> f1 = userService.findUser(1L);
    Future<User> f2 = userService.findUser(2L);
    Future<User> f3 = userService.findUser(3L);
    f1.get();
    f2.get();
    f3.get();
    Thread.sleep(200);
    Future<User> f4 = userService.findUser(4L);
    f4.get();
}

上面的测试方法中对findUser方法进行了4次的调用，最后一次调用（f4）之前先让线程等待200毫秒（大于timerDelayInMilliseconds中定义的100毫秒），所以我们的预期是前三次调用会被合并，而最后一次调用不会被合并进去。

启动Ribbon-Consumer，访问http://localhost:9000/testRequestMerge,控制台输出如下：

QQ截图20180712185806.png

可以看到，控制台的输出符合我们的预期，f1、f2和f3被合并成了一个请求。

而且可以看到，控制台并没有打印出findUser方法中的获取单个用户信息的日志，实际上findUser方法并不会被调用，所以上面的代码可以简化为：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 @HystrixCollapser(batchMethod = "findUserBatch", collapserProperties = {
        @HystrixProperty(name = "timerDelayInMilliseconds", value = "100")
})
public Future<User> findUser(Long id) {
    log.info("获取单个用户信息");
    return null;
}

@HystrixCommand
public List<User> findUserBatch(List<Long> ids) {
    log.info("批量获取用户信息,ids: " + ids);
    User[] users = restTemplate.getForObject("http://Server-Provider/user/users?ids={1}", User[].class, StringUtils.join(ids, ","));
    return Arrays.asList(users);
}

虽然通过请求的合并可以减轻带宽和服务的压力，但合并请求的过程也会带来额外的开销。就拿上面的testCache来说，比如我们对单个findUser的方法调用耗时5ms，那么调用4次耗时可以粗略的估算为20ms。当我们使用Hystrix的请求合并功能后，前3次请求（f1、f2和f3）进行了合并，第4次请求（f4）没有进行合并，那么耗时可以粗略的估算为3*5+100+5=120ms（100为上面timerDelayInMilliseconds中指定的时间范围，在该时间段过后，才会调用第4次请求），结果明显比单独调用4次来得高。所以实际中是否该使用Hystrix的请求合并功能，需结合实际需求进行抉择。

Hystrix属性

除了上面涉及到的Hystrix属性配置外，其还包含了大量的别的可用配置。配置可以分为四个级别，优先级从低到高分别为：全局默认配置、全局配置、实例默认值、实例配置。

Commond

execution

execution.isolation.strategy： 该属性用来设置执行的隔离策略，它有如下两个选项。

  1. THREAD: 通过线程池隔离的策略。它在独立的线程上执行， 并且它的并发限制受线程池中线程数量的限制。

  2. SEMAPHORE: 通过信号量隔离的策略。它在调用线程上执行， 并且它的并发限制受信号量计数的限制。

属性级别默认值、配置方式、配置属性
全局默认配置THREAD
全局配置hystrix.command.default.execution.isolation.strategy
实例默认值@HystrixProperty(name=”execution.isolation.strategy”, value=”THREAD”)
实例配置hystrix.command.HystrixCommandKey.execution.isolation.strategy

实例配置中的HystrixCommandKey对应@HystrixCommand注解中commandKey 属性指定的值。

execution.isolation.thread.timeoutinMilliseconds： 该属性用来配置HystrixCommand执行的超时时间，单位为毫秒。当HystrixCommand执行时间超过该配置值之后， Hystrix会将该执行命令标记为TIMEOUT并进入服务降级处理逻辑。

属性级别默认值、配置方式、配置属性
全局默认配置1000亳秒
全局配置hystrix.command.default.execution.isolation.thread. timeoutinMilliseconds
实例默认值@HystrixProperty(name=”execution.isolation.thread.timeoutinMilliseconds”,value=”2000”)
实例配置hystrix.command.HystrixCommandKey.execution.isolation.thread.timeoutinMilliseconds

execution.timeout.enabled: 该属性用来配置HystrixCommand的执行是否启用超时时间。默认为true, 如果设置为false, 那么execution.isolation.thread.timeoutinMilliseconds属性的配置将不再起作用。

属性级别默认值、配置方式、配置属性
全局默认配置true
全局配置hystrix.command.default.execution.timeout.enabled
实例默认值@HystrixProperty(name=”execution.timeout.enabled”, value=”false”)
实例配置hystrix.command.HystrixCommandKey.execution.timeout.enabled

execution.isolation.thread.interruptOnTimeout: 该属性用来配置当HystrixCommand执行超时的时候是否要将它中断。

属性级别默认值、配置方式、配置属性
全局默认配置true
全局配置hystrix.command.default.execution.isolation.thread.interruptOnTimeout
实例默认值@HystrixProperty(name=”execution.isolation.thread.interruptOnTimeout”,value=”false”)
实例配置hystrix.command.HystrixCommandKey.execution.isolation.thread.interruptOnTimeout

execution.isolation.thread.interruptOnCancel: 该属性用来配置当HystrixCommand执行被取消的时候是否要将它中断。

属性级别默认值、配置方式、配置属性
全局默认配置true
全局配置hystrix.command.default.execution.isolation.thread.interruptOnCancel
实例默认值@HystrixProperty(name=”execution.isolation.thread.interruptOnCancel”,value= “false”)
实例配置hystrix.command.HystrixCommandKey.execution.isolation.thread.interruptOnCancel

execution.isolation.semaphore.maxConcurrentRequests: 当HystrixCommand的隔离策略使用信号量的时候，该属性用来配置信号量的大小（并发请求数）。当最大并发请求数达到该设置值时，后续的请求将会被拒绝。

属性级别默认值、配置方式、配置属性
全局默认配置10
全局配置hystrix.command.default.execution.isolation.semaphore.maxConcurrentRequests
实例默认值@HystrixProperty(name=”execution.isolation.semaphore.maxConcurrentRequests”, value=”2”)
实例配置hystrix.command.HystrixCommandKey.execution.isolation.semaphore.maxConcurrentRequests

fallback

fallback.enabled: 该属性用来设置服务降级策略是否启用，如果设置为false,那么当请求失败或者拒绝发生时，将不会调用降级服务。

属性级别默认值、配置方式、配置属性
全局默认配置true
全局配置hystrix.command.default.fallback.enabled
实例默认值@HystrixProperty(name= “fallback.enabled”, value=”false”)
实例配置hystrix.command.HystrixCommandKey.fallback.enabled

circuitBreaker断路器

circuitBreaker.enabled: 该属性用来确定当服务请求命令失败时， 是否使用断路器来跟踪其健康指标和熔断请求。

属性级别默认值、配置方式、配置属性
全局默认配置true
全局配置hystrix.command.default.circuitBreaker.enabled
实例默认值@HystrixProperty(name=”circutBreaker.enabled”,value=”false”)
实例配置hystrix.command.HystrixCommandKey.circuitBreaker.enabled

circuitBreaker.requestVolumeThreshold: 该属性用来设置在滚动时间窗中，断路器熔断的最小请求数。例如，默认该值为20 的时候，如果滚动时间窗（默认10秒）内仅收到了19个请求， 即使这19个请求都失败了，断路器也不会打开。

属性级别默认值、配置方式、配置属性
全局默认配置20
全局配置hystrix.command.default.circuitBreaker.requestVolumeThreshold
实例默认值@HystrixProperty(name=”circuitBreaker.requestVolumeThreshold”, value=”30”)
实例配置hystrix.comrnand.HystrixComrnandKey.circuitBreaker.requestVolumeThreshold

circuitBreaker.sleepWindowinMilliseconds: 该属性用来设置当断路器打开之后的休眠时间窗。休眠时间窗结束之后，会将断路器置为“半开” 状态， 尝试熔断的请求命令，如果依然失败就将断路器继续设置为“打开” 状态，如果成功就设置为“关闭” 状态。

属性级别默认值、配置方式、配置属性
全局默认配置5000
全局配置hystrix.command.default.circuitBreaker.sleepWindowinMilliseconds
实例默认值@HystrixProperty(name=”circuitBreaker.sleepWindowinMilliseconds”,value=”3000”)
实例配置hystrix.command.HystrixCommandKey.circuitBreaker.sleepWindowinMilliseconds

circuitBreaker.errorThresholdPercentage: 该属性用来设置断路器打开的错误百分比条件。例如，默认值为5000 的情况下，表示在滚动时间窗中，在请求数量超过circuitBreaker.requestVolumeThreshold阅值的前提下，如果错误请求数的百分比超过50, 就把断路器设置为“打开” 状态， 否则就设置为“关闭” 状态。

属性级别默认值、配置方式、配置属性
全局默认配置50
全局配置hystrix.command.default.circuitBreaker.errorThresholdPercentage
实例默认值@HystrixProperty(name=”circuitBreaker.errorThresholdPercentage”, value=”40”)
实例配置hystrix.command.HystrixCommandKey.circuitBreaker.errorThresholdPercentage

circuitBreaker.forceOpen: 如果将该属性设置为true, 断路器将强制进入“打开” 状态，它会拒绝所有请求。该属性优先于circuitBreaker.forceClosed属性。

属性级别默认值、配置方式、配置属性
全局默认配置false
全局配置hystrix.command.default.circuitBreaker.forceOpen
实例默认值@HystrixProperty (name=”circuitBreaker.forceOpen”, value=”true”)
实例配置hystrix.command.HystrixCommandKey.circuitBreaker.forceOpen

circuitBreaker.forceClosed: 如果将该属性设置为true, 断路器将强制进入“关闭” 状态， 它会接收所有请求。如果circuitBreaker.forceOpen属性为true, 该属性不会生效。

属性级别默认值、配置方式、配置属性
全局默认配置false
全局配置hystrix.command.default.circuitBreaker.forceClosed
实例默认值@HystrixProperty(name=”circui七Breaker.forceClosed”, value=”true”)
实例配置hystrix.comrnand.HystrixComrnandKey.circuitBreaker.forceClosed

metrics配置

该配置与HystrixCommand执行中捕获的指标信息有关。

metrics.rollingStats.timeinMilliseconds: 该属性用来设置滚动时间窗的长度， 单位为毫秒。该时间用于断路器判断健康度时需要收集信息的持续时间。断路器在收集指标信息的时候会根据设置的时间窗长度拆分成多个“桶” 来累计各度量值，每个“桶” 记录了一段时间内的采集指标。例如，当采用默认值10000毫秒时， 断路器默认将其拆分成10个桶（桶的数量也可通过metrics.rollingStats.numBuckets参数设置），每个桶记录1000毫秒内的指标信息。

属性级别默认值、配置方式、配置属性
全局默认配置10000
全局配置hystrix.command.default.metrics.rollingStats.timeinMilliseconds
实例默认值@HystrixProperty(name=”metrics.rollingStats.timeinMilliseconds”,value=”20000”)
实例配置hystrix.command.HystrixCommandKey.metrics.rollingStats.timeinMilliseconds

metrics.rollingstats.numBuckets: 该属性用来设置滚动时间窗统计指标信息时划分“桶” 的数量。

属性级别默认值、配置方式、配置属性
全局默认配置10
全局配置hystrix.command.default.metrics.rollingStats.numBuckets
实例默认值@HystrixProperty(name=”metrics.rollingStats.numBuckets”,value=”20”)
实例配置hystrix.comrnand.HystrixComrnandKey.metrics.rollingStats.numBuckets

metrics.rollingPercentile.enabled: 该属性用来设置对命令执行的延迟是否使用百分位数来跟踪和计算。如果设置为false，那么所有的概要统计都将返回-1。

属性级别默认值、配置方式、配置属性
全局默认配置true
全局配置hystrix.command.default.metrics.rollingPercentile.enabled
实例默认值@HystrixProperty(name=”metrics.rollingPercentile.enabled”, value=”false”)
实例配置hystrix.command.HystrixCommandKey.metrics.rollingPercentile.enabled

metrics.rollingPercentile.timeinMilliseconds: 该属性用来设置百分位统计的滚动窗口的持续时间，单位为毫秒。

属性级别默认值、配置方式、配置属性
全局默认配置60000
全局配置hystrix.command.default.metrics.rollingPercentile.timeinMilliseconds
实例默认值@HystrixProperty(name=”metrics.rollingPercentile.timeinMilliseconds”, value=”50000”)
实例配置hystrix.command.HystrixCommandKey.metrics.rollingPercentile.timeinMilliseconds

metrics.rollingPercentile.numBuckets: 该属性用来设置百分位统计滚动窗口中使用“桶”的数量。

属性级别默认值、配置方式、配置属性
全局默认配置6
全局配置hystrix.command.default.metrics.rollingPercentile.numBuckets
实例默认值@HystrixProperty(name=”metrics.rollingPercentilee.numBuckets”,value=”5”)
实例配置hystrix.command.HystrixCommandKey.metrics.rollingPercentile.numBuckets

metrics.rollingPercentile.bucketSize: 该属性用来设置在执行过程中每个“桶” 中保留的最大执行次数。如果在滚动时间窗内发生超过该设定值的执行次数，就从最初的位置开始重写。例如，将该值设置为100, 滚动窗口为10秒，若在10秒内一个“桶”中发生了500次执行，那么该“桶”中只保留最后的100次执行的统计。另外，增加该值的大小将会增加内存量的消耗，并增加排序百分位数所需的计算时间。

属性级别默认值、配置方式、配置属性
全局默认配置100
全局配置hystrix.command.default.metrics.rollingPercentile.bucketSize
实例默认值@HystrixProperty(name=”metrics.rollingPercentile.bucketSize”,value= “120”)
实例配置hystrix.command.HystrixCommandKey.metrics.rollingPercentile.bucketSize

metrics.healthSnapshot.intervalinMilliseconds: 该属性用来设置采集影响断路器状态的健康快照（请求的成功、错误百分比）的间隔等待时间。

属性级别默认值、配置方式、配置属性
全局默认配置500
全局配置hystrix.comrnand.default.metrics.healthSnapshot.intervalinMilliseconds
实例默认值@HystrixProperty(name=”metrics.healthSnapshot.intervalinMilliseconds”,value=”600”)
实例配置hystrix.command.HystrixCommandKey.metrics.healthSnapshot.intervalinMilliseconds

requestContext

requestCache.enabled: 此属性用来配置是否开启请求缓存。

属性级别默认值、配置方式、配置属性
全局默认配置true
全局配置hystrix.command.default.requestCache.enabled
实例默认值@HystrixProperty(name=”requestCache.enabled”, value=”false”)
实例配置hystrix.command.HystrixCommandKey.requestCache.enabled

collapser

maxRequestsinBatch: 该参数用来设置一次请求合并批处理中允许的最大请求数。

属性级别默认值、配置方式、配置属性
全局默认配置Integer.MAX_VALUE
全局配置hystrix.collapser.default.maxRequestsinBatch
实例默认值@HystrixProperty(name=”maxRequestsinBatch”,value=”false”)
实例配置hystrix.collapser.HystrixCollapserKey.maxRequestsinBatch

timerDelayinMilliseconds: 该参数用来设置批处理过程中每个命令延迟的时间，单位为毫秒。

属性级别默认值、配置方式、配置属性
全局默认配置10
全局配置hystrix.collapser.default.timerDelayinMilliseconds
实例默认值@HystrixProperty(name=”timerDelayinMilliseconds”,value=”20”)
实例配置hystrix.collapser.HystrixCollapserKey.timerDelayinMilliseconds

request Cache.enabled: 该参数用来设置批处理过程中是否开启请求缓存。

属性级别默认值、配置方式、配置属性
全局默认配置true
全局配置hystrix.collapser.default.requestCache.enabled
实例默认值@HystrixProperty(name=”requestCache.enabled”, value=”false”)
实例配置hystrix.collapser.HystrixCollapserKey.requestCache.enabled

threadPool

coreSize: 该参数用来设置执行命令线程池的核心线程数，该值也就是命令执行的最大并发量。

属性级别默认值、配置方式、配置属性
全局默认配置10
全局配置hystrix.threadpool.default.coreSize
实例默认值@HystrixProperty(name=”coreSize”, value=”false”)
实例配置hystrix.threadpool.HystrixThreadPoolKey.coreSize

maxQueueSize: 该参数用来设置线程池的最大队列大小。当设置为-1时，线程池将使用SynchronousQueue实现的队列，否则将使用LinkedBlockingQueue实现的队列。

属性级别默认值、配置方式、配置属性
全局默认配置-1
全局配置hystrix.threadpool.default.maxQueueSize
实例默认值@HystrixProperty(name=”maxQueueSize”,value=”lO”)
实例配置hystrix.threadpool.HystrixThreadPoolKey.maxQueueSize

queueSizeRejectionThreshold: 该参数用来为队列设置拒绝阈值。通过该参数，即使队列没有达到最大值也能拒绝请求。该参数主要是对LinkedBlockingQueue队列的补充， 因为LinkedBlockingQueue队列不能动态修改它的对象大小，而通过该属性就可以调整拒绝请求的队列大小了。

属性级别默认值、配置方式、配置属性
全局默认配置5
全局配置hystrix.threadpool.default.queueSizeRejectionThreshold
实例默认值@HystrixProperty(name=”queueSizeRejectionThreshold”, value=”lO”
实例配置hystrix.threadpool.HystrixThreadPoolKey.queueSizeRejectionThreshold

不得不说，配置是真的多……

QQ图片20180713111516.gif

源码链接：https://github.com/wuyouzhuguli/Spring-Boot-Demos/tree/master/30.Spring-Cloud-Hystrix-Circuit-Breaker

参考文章 《Spring Cloud微服务实战》

请作者喝瓶肥宅水🥤
0