SpringCloud--熔断器：Hystricx

1.1 Hystrix介绍

Hystrix的设计原则是什么？

• l 资源隔离（线程池隔离和信号量隔离）机制：限制调用分布式服务的资源使用，某一个调用的服务出现问题不会影响其它服务调用。
• l 限流机制：限流机制主要是提前对各个类型的请求设置最高的QPS阈值，若高于设置的阈值则对该请求直接返回，不再调用后续资源。
• l 熔断机制：当失败率达到阀值自动触发降级（如因网络故障、超时造成的失败率真高），熔断器触发的快速失败会进行快速恢复。
• l 降级机制：超时降级、资源不足时（线程或信号量）降级 、运行异常降级等，降级后可以配合降级接口返回托底数据。
• l 缓存支持：提供了请求缓存、请求合并实现
• l 通过近实时的统计/监控/报警功能，来提高故障发现的速度
• l 通过近实时的属性和配置热修改功能，来提高故障处理和恢复的速度

1.2 Hystrix整体工作流程

整个流程可以大致归纳为如下几个步骤：

1. l 创建HystrixCommand或者HystrixObservableCommand对象
2. l 执行 Command
3. l 检查请求结果是否被缓存
4. l 检查是否开启了短路器
5. l 检查 线程池/队列/semaphore 是否已经满
6. l 执行 HystrixObservableCommand.construct() or HystrixCommand.run()
7. l 计算短路健康状况
8. l 调用fallback降级机制
9. l 返回依赖请求的真正结果

1.3 Hystrix特性

1.3.1 资源隔离

l 说明：在Hystrix中, 主要通过线程池来实现资源隔离. 通常在使用的时候我们会根据调用的远程服务划分出多个线程池. 例如调用产品服务的Command放入A线程池, 调用账户服务的Command放入B线程池. 这样做的主要优点是运行环境被隔离开了. 这样就算调用服务的代码存在bug或者由于其他原因导致自己所在线程池被耗尽时, 不会对系统的其他服务造成影响. 但是带来的代价就是维护多个线程池会对系统带来额外的性能开销. 如果是对性能有严格要求而且确信自己调用服务的客户端代码不会出问题的话, 可以使用Hystrix的信号模式(Semaphores)来隔离资源

l Command执行方式

execute()：以同步堵塞方式执行 run()。调用 execute() 后，hystrix先创建一个新线程运行run()，接着调用程序要在 execute() 调用处一直堵塞着，直到 run() 运行完成。

queue()：以异步非堵塞方式执行 run() 。调用 queue() 就直接返回一个 Future 对象，同时hystrix创建一个新线程运行 run()，调用程序通过 Future.get() 拿到 run() 的返回结果，而Future.get() 是堵塞执行的。

observe()：立即执行，即事件subscribe()完成注册前执行 run()/construct() 。

第一步是事件注册前，先调用 observe() 自动触发执行 run()/construct()（如果继承的是HystrixCommand，hystrix将创建新线程非堵塞执行run()；如果继承的是HystrixObservableCommand，将以调用程序线程堵塞执行construct())，

第二步是从 observe() 返回后调用程序调用 subscribe() 完成事件注册，如果 run()/construct() 执行成功则触发 onNext() 和 onCompleted() ，如果执行异常则触发 onError() 。

toObservable()：延时执行，即事件subscribe()完成事件注册后执行 run()/construct() 。

第一步是事件注册前，调用 toObservable() 就直接返回一个 Observable<string> 对象，/<string>

第二步调用 subscribe() 完成事件注册后自动触发执行 run()/construct()（如果继承的是HystrixCommand，hystrix将创建新线程非堵塞执行 run() ，调用程序不必等待 run() ；如果继承的是HystrixObservableCommand，将以调用程序线程堵塞执行 construct()，调用程序等待construct()执行完才能继续往下走），如果 run()/construct() 执行成功则触发 onNext() 和 onCompleted() ，如果执行异常则触发 onError() 。

备注：execute()和queue()是HystrixCommand中的方法，observe()和toObservable()是HystrixObservableCommand 中的方法。其中HystrixCommand是用来获取一条数据的；HystrixObservableCommand是用来获取多条数据的。从底层实现来讲，HystrixCommand其实也是利用Observable实现的（如果我们看Hystrix的源码的话，可以发现里面大量使用了RxJava），虽然HystrixCommand只返回单个的结果，但HystrixCommand的queue方法实际上是调用了toObservable().toBlocking().toFuture()，而execute方法实际上是调用了queue().get()。

l 获取单个产品Command

public class GetProductInfoCommand extends HystrixCommand<productinfo>{

 private Long productId;

 public GetProductInfoCommand(Long productId) {

 super(HystrixCommandGroupKey.Factory.asKey("GetProductInfoCommandGroup"));

 this.productId=productId;

 }

 

 @Override

 protected ProductInfo run() throws Exception {

 String url = "http://127.0.0.1:8082/getProductInfo?productId="+productId;

 String response = HttpClientUtils.sendGetRequest(url);

 

 return JSONObject.parseObject(response,ProductInfo.class);

 }

}

  


//使用

HystrixCommand<productinfo> command = new GetProductInfoCommand(productId);

 ProductInfo productInfo=command.execute();

l 获取产品列表Command

// 获取产品列表Command

public class GetProductInfosCommand extends HystrixObservableCommand<productinfo> {

 

 private String[] productIds;

 public GetProductInfosCommand(String[] productIds) {

 super(HystrixCommandGroupKey.Factory.asKey("GetProductInfoGroup"));

 this.productIds = productIds;

 }

 @Override

 protected Observable<productinfo> construct() {

 return Observable.create(new Observable.OnSubscribe<productinfo>() {

 

 public void call(Subscriber super ProductInfo> observer) {

 try {

 for(String productId : productIds) {

 String url = "http://127.0.0.1:8082/getProductInfo?productId=" + productId;

 String response = HttpClientUtils.sendGetRequest(url);

 ProductInfo productInfo = JSONObject.parseObject(response, ProductInfo.class);

 observer.onNext(productInfo);

 }
 

 observer.onCompleted();

 } catch (Exception e) {

 observer.onError(e); 

 }

 }

 

 }).subscribeOn(Schedulers.io());

 }

}

 

//使用

HystrixObservableCommand<productinfo> getProductInfosCommand =

 new GetProductInfosCommand(productIds.split(",")); 

Observable<productinfo> observable = getProductInfosCommand.observe();

 

//observable = getProductInfosCommand.toObservable(); // 还没有执行

 

observable.subscribe(new Observer<productinfo>() { // 等到调用subscribe然后才会执行

 

 public void onCompleted() {

 System.out.println("获取完了所有的商品数据");

 }

 

 public void onError(Throwable e) {
 

 e.printStackTrace();

 }

 

 public void onNext(ProductInfo productInfo) {

 System.out.println(productInfo); 

 }

});/<productinfo>/<productinfo>/<productinfo>/<productinfo>/<productinfo>/<productinfo>/<productinfo>/<productinfo>

1.3.2 限流（通过配置）

限流在日常生活中很常见，比如节假日你去一个旅游景点，为了不把景点撑爆，管理部门通常会在外面设置拦截，限制景点的进入人数（等有人出来之后，再放新的人进去）。对应到计算机中，比如要搞活动、秒杀等，通常都会限流。在Hystrix中：

l 如果是线程隔离，可以通过线程数+队列大小限制。参数如下：

hystrix.threadpool.default.coreSize

hystrix.threadpool.default.maxQueueSize

hystrix.threadpool.default.queueSizeRejectionThreshold

hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds

l 如果是信号量隔离，可以设置最大并发请求数。参数如下：

hystrix.command.default.execution.isolation.semaphore.maxConcurrentRequests

1.3.3 熔断（CircuitBreaker）

熔断器的原理很简单，如同电力过载保护器。它可以实现快速失败，如果它在一段时间内侦测到许多类似的错误，会强迫其以后的多个调用快速失败，不再访问远程服务器，从而防止应用程序不断地尝试执行可能会失败的操作，使得应用程序继续执行而不用等待修正错误，或者浪费CPU时间去等到长时间的超时产生。熔断器也可以使应用程序能够诊断错误是否已经修正，如果已经修正，应用程序会再次尝试调用操作。

熔断器模式就像是那些容易导致错误的操作的一种代理。这种代理能够记录最近调用发生错误的次数，然后决定使用允许操作继续，或者立即返回错误。

熔断器开关相互转换的逻辑如下图：

熔断器就是保护服务高可用的最后一道防线。

当Hystrix Command请求后端服务时，在一定时间内（metrics.rollingStats.timeInMilliseconds，默认10s），请求次数超过了最低要求（circuitBreaker.requestVolumeThreshold，默认20次），并且其失败数量超过一定比例(circuitBreaker.errorThresholdPercentage，默认50%)，断路器会切换到开路状态(Open). 这时所有请求会直接失败而不会发送到后端服务. 断路器保持在开路状态一段时间后(circuitBreaker.sleepWindowInMilliseconds，默认5秒), 自动切换到半开路状态(HALF-OPEN). 这时会判断下一次请求的返回情况, 如果请求成功, 断路器切回闭路状态(CLOSED), 否则重新切换到开路状态(OPEN). Hystrix的断路器就像我们家庭电路中的保险丝, 一旦后端服务不可用, 断路器会直接切断请求链, 避免发送大量无效请求影响系统吞吐量, 并且断路器有自我检测并恢复的能力.

1.3.4 降级（Fallback）

Fallback相当于是降级操作。所谓降级，就是指在Hystrix执行非核心链路功能失败的情况下，该如何处理，比如返回默认值或者从缓存中取值

触发降级的情况

1、hystrix调用各种接口，或者访问外部依赖（如mysql、redis等等）时，执行方法中抛出了异常。

2、对每个外部依赖，无论是服务接口，中间件，资源隔离，对外部依赖只能用一定量的资源去访问，线程池/信号量，如果资源池已满，则后续的请求将会被 reject，即进行限流。

3、访问外部依赖的时候，访问时间过长，可能就会导致超时，报一个TimeoutException异常，即Timeout机制。

上述三种情况，都是常见的异常情况，对外部依赖的东西访问的时候出现了异常，发送异常事件到断路器中去进行统计。

4、如果断路器发现异常事件的占比达到了一定的比例，直接开启断路器。

上述四种情况，都会去调用fallback降级机制。

如果要实现回退或者降级处理，代码上需要实现HystrixCommand.getFallback()方法或者是HystrixObservableCommand. HystrixObservableCommand()。

1.3.5 Hystrix请求缓存（request cache）

Hystrix支持将一个请求结果缓存起来，在同一个请求上下文中，具有相同key的请求将直接从缓存中取出结果，很适合查询类的接口，可以使用缓存进行优化，减少请求开销，从而跳过真实服务的访问请求。

Hystrix请求结果缓存的作用：

1、在同一个请求上下文中，可以减少使用相同参数请求原始服务的开销。

3、请求缓存在 run() 和 construct() 执行之前生效，所以可以有效减少不必要的线程开销。

要使用Hystrix cache功能：

1、需要构建 RequestContext ，可以在拦截器中使用 HystrixRequestContext.initializeContext() 和 HystrixRequestContext.shutdown() 来初始化 RequestContext 和 关闭RequestContext资源。

2、需要重写 HystrixCommand 或 HystrixObservableCommand 中的 getCacheKey() 方法，指定缓存的 key，开启缓存配置。

l 配置HystrixRequestContextServletFilter

@WebFilter(filterName = "hystrixRequestContextServletFilter",urlPatterns = "/*",asyncSupported = true)

public class HystrixRequestContextServletFilter implements Filter {

 public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {

 HystrixRequestContext context = HystrixRequestContext.initializeContext();

 try {

 chain.doFilter(request, response); 


 } finally {

 context.shutdown();

 }

 }

 @Override

 public void init(FilterConfig filterConfig) throws ServletException {

 

 }

 

 @Override

 public void destroy() {

 

 }

}

l 开启缓存功能：继承HystrixCommand或HystrixObservableCommand，覆盖getCacheKey()方法，指定缓存的key，开启缓存配置。

private static final HystrixCommandKey COMMAND_KEY= HystrixCommandKey.Factory.asKey("GetProductInfoCommand");

@Override

 protected String getCacheKey() {

 return "product_info_"+productId;

 }

 

 public static void flushCache(Long productId){

 HystrixRequestCache.getInstance(COMMAND_KEY, HystrixConcurrencyStrategyDefault.getInstance()).clear("product_info_"+productId);

 } 

1.3.6 Hystrix请求合并（request collapser）

1.4 Feign使用Hystrix

见文章：https://www.toutiao.com/i6752760297146024460/

1.5 设置TimeOut注意事项

l 如果hystrix.command.default.execution.timeout.enabled为true,则会有两个执行方法超时的配置,一个就是ribbon的ReadTimeout,一个就是熔断器hystrix的timeoutInMilliseconds, 此时谁的值小谁生效

l 如果hystrix.command.default.execution.timeout.enabled为false,则熔断器不进行超时熔断,而是根据ribbon的ReadTimeout抛出的异常而熔断,也就是取决于ribbon

l ribbon的ConnectTimeout,配置的是请求服务的超时时间,除非服务找不到,或者网络原因,这个时间才会生效

l ribbon还有MaxAutoRetries对当前实例的重试次数,MaxAutoRetriesNextServer对切换实例的重试次数, 如果ribbon的ReadTimeout超时,或者ConnectTimeout连接超时,会进行重试操作

l 由于ribbon的重试机制,通常熔断的超时时间需要配置的比ReadTimeout长,ReadTimeout比ConnectTimeout长,否则还未重试,就熔断了

l 为了确保重试机制的正常运作,理论上（以实际情况为准）建议hystrix的超时时间为:(1 + MaxAutoRetries + MaxAutoRetriesNextServer) * ReadTimeout

1.6 Hystrix微服务优化实例

了解了Hystrix的特性和超时效果,再看看下面这个图,服务A调用服务B和服务C,服务C没有太复杂的逻辑处理,300毫秒内就处理返回了,服务B逻辑复杂,Sql语句就长达上百行,经常要卡个5,6秒返回,在大量请求调用到服务B的时候,服务A调用服务B的hystrix线程池已经不堪重负,全部卡住

这里的话,首先考虑的就是服务B的优化,优化SQL,加索引,加缓存, 优化流程,同步改异步,总之缩短响应时间

一个接口，理论的最佳响应速度应该在200ms以内，或者慢点的接口就几百毫秒。

a. 如何设置Hystrix线程池大小，Hystrix线程池大小默认为10

hystrix:

threadpool:

 default:

 coreSize: 10

每秒请求数 = 1/响应时长(单位s) * 线程数 = 线程数 / 响应时长(单位s)

即：线程数 = 每秒请求数 * 响应时长(单位s) + (缓冲线程数)

比如一台服务, 平均每秒大概收到20个请求,每个请求平均响应时长估计在500ms,

线程数 = 20 * 500 / 1000 = 10

为了应对峰值高并发,加上缓冲线程,比如这里为了好计算设为5,就是 10 + 5 = 15个线程

b. 如何设置超时时间

还拿上面的例子,比如已经配置了总线程是15个,每秒大概20个请求,那么极限情况,每个线程都饱和工作,也就是每个线程一秒内处理的请求为 20 / 15 = ≈ 1.3个 , 那每个请求的最大能接受的时间就是 1000 / 1.3 ≈ 769ms ,往下取小值700ms.

实际情况中,超时时间一般设为比99.5%平均时间略高即可,然后再根据这个时间推算线程池大小

1.7 资料

Hystrix属性配置详情：https://github.com/Netflix/Hystrix/wiki/Configuration

閱讀更多 包子餡2012 的文章

關鍵字: 设计 熔断器