目录
1、添加@HystrixCommand后,Hystrix是如何实现超时和降级功能?
思考:当活动服务出现性能问题以后,我们只能眼睁睁看着活动服务被压垮吗?
1、添加@HystrixCommand后,Hystrix是如何实现超时和降级功能?
1、在某个方法上添加了@HystrixCommand后,该方法会被包裹在Hystrix里,并将该方法放到线程池中。类似切面。
分析:用户的请求会到达一个带有@HystrixCommand注解的方法,则该方法被放到线程池中进行执行【Hystrix的线程池中默认有10个线程】,该线程池会调用活动服务。
此时如果用户的其他请求到达该另一个被@HystrixCommand修饰的方法时,方法1已经有10个请求占据了10个线程,则方法2的请求会等待。
以上模式的问题:所有带有@HystrixCommand注解的方法都用的同一个线程池,而这个线程池的线程数量是有限的,所以,当线程池被方法1占满以后,方法2就无法请求到X服务。
2、启动服务直观查看线程数量
1⃣️、启动
2⃣️、打印启动的进程。jps:当前用户下的java进程
3⃣️、进行多次请求fallback接口
4⃣️、查看线程数。jstack:查看指定进程(pid)的堆栈信息
5⃣️、多次请求timeout接口
6⃣️、查看仍只有10个线程
结论:用户请求的两个方法公用一个线程池。此时有性能问题的服务,当请求过多时,会导致正常的服务无法访问。
如何解决这个问题?
1、增加线程数:不可行,因为如果将线程数从10增加到100,而请求方法1的请求有10000个,此时仍然影响方法2的调用。
2、方法间的线程池隔离:以下隔离方式Hystrix称为 舱壁模式即(bulkhead)
2、线程池隔离
1、通过使用@HystrixCommand使每个方法单独设置线程池
@HystrixCommand(
threadPoolKey = "firstLoginFallback",
threadPoolProperties = {
@HystrixProperty(name = "coreSize",value = "1"),
@HystrixProperty(name="maxQueueSize",value = "20")
},
fallbackMethod = "firstLoginFallback0")
@Service
public class ActivityServiceBulkhead {
@Autowired
private RestTemplate restTemplate;
/**
* 调用活动服务,完成初次登陆,奖励发放
**/
public String firstLogin(Long userId){
//使用服务名,实际上Spring会将服务名转为对应ip
return restTemplate.postForObject("http://activity/firstLoginActivity", userId, String.class);
}
/**
* 调用活动服务,完成初次登陆,奖励发放
* 定义超时时间,让用户服务不再等待活动服务的响应
* 这样的话,可以及时释放资源。
* 使用hystrix,设置超时时间超过2s时则不继续等待调用,直接返回
* HystrixThreadPoolProperties类中Setter中(可以进去找配置)
* threadPoolKey:该属性为方法单独定义线程池,当key存在时直接使用定义过的线程池,不存在时新创建线程池
* threadPoolProperties:为线程池定义属性
* coreSize:允许有多少个线程
* maxQueueSize:当线程占满,允许排队的请求数量
**/
@HystrixCommand(
threadPoolKey = "firstLoginTimeout",
threadPoolProperties = {
@HystrixProperty(name = "coreSize",value = "2"),
@HystrixProperty(name="maxQueueSize",value = "20")
},
commandProperties = {
@HystrixProperty(name="execution.isolation.thread.timeoutInMilliseconds",value = "2000")
})
public String firstLoginTimeout(Long userId){
//使用服务名,实际上Spring会将服务名转为对应ip
return restTemplate.postForObject("http://activity/firstLoginActivityTimeout", userId, String.class);
}
/**
* 需要提供一个备用方案,当活动服务不可用时,执行备用方案,即降级
**/
@HystrixCommand(
threadPoolKey = "firstLoginFallback",
threadPoolProperties = {
@HystrixProperty(name = "coreSize",value = "1"),
@HystrixProperty(name="maxQueueSize",value = "20")
},
fallbackMethod = "firstLoginFallback0")
public String firstLoginFallback(Long userId){
//使用服务名,实际上Spring会将服务名转为对应ip
return restTemplate.postForObject("http://activity/firstLoginActivityError", userId, String.class);
}
public String firstLoginFallback0(Long userId){
return "活动备用方案--降级";
}
}
2、启动成功
3、发请求
4、实际线程数:此时只有3个。
3、Hystrix工作流程
思考:当活动服务出现性能问题以后,我们只能眼睁睁看着活动服务被压垮吗?
我们希望是什么样子呢?
如果活动服务出现性能问题,如果用户服务不继续请求,那么活动服务肯定不会被压垮;如果用户服务继续请求,很可能会压垮,而且是无意义的压垮。
1、当调用出现错误时,