Hystrix 线程 命令名称commandKey、分组groupKey以及线程池划分threadPoolKey

概念

command key，代表了一类command，一般来说，代表了底层的依赖服务的一个接口

command group，代表了某一个底层的依赖服务，合理，一个依赖服务可能会暴露出来多个接口，每个接口就是一个command key

举例：比如用户服务就是一个command group，用户服务里面有获取用户姓名、获取用户列表 这些都是不同的接口，就是不同的command key

command group，在逻辑上去组织起来一堆command key的调用，统计信息，成功次数，timeout超时次数，失败次数，可以看到某一个服务整体的一些访问情况

command group，一般来说，推荐是根据一个服务去划分出一个线程池，command key默认都是属于同一个线程池的

比如说你以一个服务为粒度，估算出来这个服务每秒的所有接口加起来的整体QPS在100左右

你调用那个服务的当前服务，部署了10个服务实例，每个服务实例上，其实用这个command group对应这个服务，给一个线程池，量大概在10个左右，就可以了，你对整个服务的整体的访问QPS大概在每秒100左右

一般来说，command group是用来在逻辑上组合一堆command的

举个例子，对于一个服务中的某个功能模块来说，希望将这个功能模块内的所有command放在一个group中，那么在监控和报警的时候可以放一起看

以下都是解释threadpool key的作用

command group，对应了一个服务，但是这个服务暴露出来的几个接口，访问量很不一样，差异非常之大，你可能就希望在这个服务command group内部，包含的对应多个接口的command key，做一些细粒度的资源隔离，对同一个服务的不同接口，都使用不同的线程池

逻辑上来说，多个command key属于一个command group，在做统计的时候，会放在一起统计

每个command key有自己的线程池，每个接口有自己的线程池，去做资源隔离和限流

但是对于thread pool资源隔离来说，可能是希望能够拆分的更加一致一些，比如在一个功能模块内，对不同的请求可以使用不同的thread pool

总结：command group一般来说，可以是对应一个服务，多个command key对应这个服务的多个接口，多个接口的调用共享同一个线程池

如果说你的command key，要用自己的线程池，可以定义自己的threadpool key，就ok了

 

实际测试：

配置方式：@HystrixCommand(fallbackMethod = "helloFallback", groupKey = "Group1", threadPoolKey = "HystrixFooServiceGaGa")

1.其中commandKey目前还没有发现有什么用，下面重点看groupKey 和 threadPoolKey

当上面3个属性都不配置的时候，比如工程中的一个HystrixUserService 这个类中所有标明了@HystrixCommand标的方法，都是使用1个线程池（线程名用的是类名

hystrix-HystrixUserService-1 ），而如果有HystrixUserService2，里面也有@HystrixCommand标的方法，那么执行的时候使用的是另一个线程池，所以默认就已经是线程池隔离的

2.如果同时配置了groupKey 和 threadPoolKey ，那么具有相同的threadPoolKey的使用同一个线程池；

3.如果只配置了groupKey ，那么具有相同的groupKey 的使用同一个线程池；比如如果配置的是@HystrixCommand(fallbackMethod = "helloFallback", groupKey = "Group1")，那么线程名就是hystrix-Group1-*

总结：《Spring Cloud 微服务实战》推荐：通常情况下，尽量通过 HystrixThreadPoolKey 的方式来指定线程池的划分， 而不是通过组名的默认方式实现划分， 因为多个不同的命令可能 从业务逻辑上来看属于同 一个组， 但是往往从实现本身上需要跟其他命令进行隔离，除非这个业务的各个接口调用频率都差不多，没有特别大的区别，那么就不需要单独设置ThreadPoolKey，直接用groupkey就可以了。