业务背景
在微服务架构体系下,服务间不可避免地会发生依赖关系,一般来说会通过REST Api来进行通信,这里先盗一个图来举例说明一个具体的业务场景(逃):
比如一个商城系统的微服务化结构,订单、商品、库存这三个服务是紧密依赖的,在理想情况下,什么问题都不发生当然是最好的。但服务运行期间难免会出现各种问题,如网络阻塞,延迟过高(比如因为内存泄露导致的Full GC次数飙高) ,甚至服务直接挂掉(比如流量激增把服务打挂了)等情况都是很有可能发生的。倘若库存服务挂掉了,那对于所有对库存服务有依赖关系的服务都会受到很大影响,最终甚至会扩散到整个微服务体系,这种就称之为雪崩效应。
因此,在某一个服务发生故障时,我们要及时对该服务的故障进行隔离,不能让其扩散到整个微服务体系中。因为,为了搭建一个稳定且可靠的微服务系统,我们就需要给系统加上自我保护,出现故障自动隔离的能力。而**Hystrix**就能做到这一点
什么是Hystrix
Hystrix是Netflix开源的一款分布式容错框架,Netflix旗下还有Eureka,Zuul等优秀的分布式开源项目,Spring Cloud也提供了对Netflix中部门项目的支持,成为了SpringCloud下的一些子项目 。
Hystrix的功能:
- 阻止故障的连锁反应,实现熔断
- 快速失败,实现优雅降级
- 提供实时的监控和告警
Hystrix简单实现
public class QueryUserIdCommand extends HystrixCommand<Integer> {
private final static Logger logger = LoggerFactory.getLogger(QueryUserIdCommand.class);
private UserServiceProvider userServiceProvider;
public QueryUserAgeCommand(UserServiceProvider userServiceProvider) {
super(Setter.withGroupKey(HystrixCommandGroupKey.Factory.asKey("userService"))
.andCommandKey(HystrixCommandKey.Factory.asKey("queryByUserId"))
.andCommandPropertiesDefaults(HystrixCommandProperties.Setter()
.withCircuitBreakerRequestVolumeThreshold(10)//至少有10个请求,熔断器才会开始进行错误率计算
.withCircuitBreakerSleepWindowInMilliseconds(5000)//熔断器中断请求,5秒后会进入一个半打开状态,放开部分请求去进行重试
.withCircuitBreakerErrorThresholdPercentage(50)//错误率达到50%就开启熔断保护
.withExecutionTimeoutEnabled(true))
.andThreadPoolPropertiesDefaults(HystrixThreadPoolProperties
.Setter().withCoreSize(10)));
this.userServiceProvider = userServiceProvider;
}
@Override
protected Integer run() {
return userServiceProvider.queryByUserId();
}
@Override
protected Integer getFallback() {
return -1;
}
}
发起请求
Integer res = new QueryUserIdCommand(userServiceProvider).execute();
log.info("result:{}", res);
访问接口,正常情况下,会返回正确的信息,当把UserServiceProvider所依赖的服务的接口改为直接抛出一个异常,就会发现总是返回-1了。这样就做到了对错误进行隔离。
Hystrix容错
那接下来从三个角度来聊一下Hystrix提供的容错功能,分别是资源隔离,熔断和降级
资源隔离
我们之前也讨论过,微服务体系中,各个服务之间都通过REST Api来进行调用,从而建立依赖关系。倘若该服务调用和业务代码在同一个线程会中执行的话,如果 api在调用的时候出现了网络堵塞等情况,那么不仅会对业务代码进行阻塞,也会对后面的请求造成阻塞,因为线程池的线程数是额定的。所以,Hystrix也提供了资源隔离的机制,主要是线程隔离和信号量隔离
资源隔离-线程池
刚才我们简单地应用了一下Hystrix,很明显看到我们得先实现一个自己的HystrixCommand,然后把服务调用的操作封装在这个类里面。而实际上,线程级别的资源隔离就是在HystrixCommand中实现。Hystrix会给每一个Command分配一个单独的线程池,这样在进行单个服务调用的时候,就可以在独立的线程池里面进行,而不会对其他线程池造成影响。