什么是Hystrix、SpringCloud的各种超时时间配置及微服务优化措施

朱雀 2022-09-10 07:22 210阅读 0赞

**点击关注公众号，利用****碎片时间学习****![abc7f4fe263e14f772a01f100e1626d9.png][]**

### 1. 前言(以下的springcloud版本是Dalston.RC1) ###

以下的springcloud版本是Dalston.RC1

Springcloud框架中,超时时间的设置通常有三个层面:

**1.zuul网关**

#默认1000
    zuul.host.socket-timeout-millis=2000
    #默认2000
    zuul.host.connect-timeout-millis=4000

**2.ribbon**

ribbon:
      OkToRetryOnAllOperations: false #对所有操作请求都进行重试,默认false
      ReadTimeout: 5000   #负载均衡超时时间，默认值5000
      ConnectTimeout: 3000 #ribbon请求连接的超时时间，默认值2000
      MaxAutoRetries: 0     #对当前实例的重试次数，默认0
      MaxAutoRetriesNextServer: 1 #对切换实例的重试次数，默认1

**3.熔断器Hystrix**

hystrix:
      command:
        default:  #default全局有效，service id指定应用有效
          execution:
            timeout:
              #如果enabled设置为false，则请求超时交给ribbon控制,为true,则超时作为熔断根据
              enabled: true
            isolation:
              thread:
                timeoutInMilliseconds: 1000 #断路器超时时间，默认1000ms
    
    feign.hystrix.enabled: true

### 2.测试各个配置的效果 ###

这里我开了一个Eureka服务中心

*  开了两个个服务eureka-client,端口分别为8087和8088,进行负载均衡
 *  开了一个服务eureka-feign8080去调用eureka-client的方法,模拟eureka-client处理时间过长的时候出现的情况

生产者eureka-client的方法:

/**
       * 测试重试时间
       *
       * @return
       */
      @RequestMapping("/timeOut")
      public String timeOut(@RequestParam int mills) {
        log.info("[client服务-{}] [timeOut方法]收到请求,阻塞{}ms", port, mills);
        try {
          Thread.sleep(mills);
        } catch (InterruptedException e) {
          e.printStackTrace();
        }
        log.info("[client服务-{}] [timeOut]返回请求",port);
        return String.format("client服务-%s 请求ok!!!", port);
      }

消费者eureka-feign调用client的方法,通过传参数mills来控制client线程休眠的时间

/**
      * 测试重试时间
      * @return
      */
    @RequestMapping("/timeOut")
    public String timeOut(@RequestParam int mills){
        log.info("开始调用");
        return feignService.timeOut( mills );
    }

eureka-feign的service:

/**
         * 测试springcloud的超时机制
         * @param mills
         * @return
         */
        @RequestMapping(value = "/timeOut",method = RequestMethod.GET)
        String timeOut(@RequestParam(value = "mills") int mills);

eureka-feign的熔断方法:

@Override
        public String timeOut(int mills) {
            System.out.println("熔断");
            return "熔断了";
        }

访问8080端口, 调用eureka-feign的/timeOut接口, 然后eureka-feign再调用client的服务。下面的配置是eureka-feign的。推荐：[Java进阶视频资源][Java]

**测试1**

ribbon:
      OkToRetryOnAllOperations: false #对所有操作请求都进行重试,默认false
      ReadTimeout: 1000   #负载均衡超时时间，默认值5000
      ConnectTimeout: 3000 #ribbon请求连接的超时时间，默认值2000
      MaxAutoRetries: 0     #对当前实例的重试次数，默认0
      MaxAutoRetriesNextServer: 1 #对切换实例的重试次数，默认1
    
    hystrix:
      command:
        default:  #default全局有效，service id指定应用有效
          execution:
            timeout:
              #如果enabled设置为false，则请求超时交给ribbon控制,为true,则超时作为熔断根据
              enabled: true
            isolation:
              thread:
                timeoutInMilliseconds: 5000 #断路器超时时间，默认1000ms

测试 900ms

![1c9496a23f86857a7a98398a70f16a06.png][] ![8c4c2aa72eda8fc28bd1cc1c80a5b7e3.png][]

请求正常.

*  测试 2000ms

熔断

![7fe927bf63987815c4d769879efd47a1.png][]

接着测试4000ms, 6000都熔断了

**测试2**

更换两个超时时间:

ReadTimeout: 3000   #负载均衡超时时间，默认值5000
    ConnectTimeout: 1000 #ribbon请求连接的超时时间，默认值2000

ribbon:
      OkToRetryOnAllOperations: false #对所有操作请求都进行重试,默认false
      ReadTimeout: 3000   #负载均衡超时时间，默认值5000
      ConnectTimeout: 1000 #ribbon请求连接的超时时间，默认值2000
      MaxAutoRetries: 0     #对当前实例的重试次数，默认0
      MaxAutoRetriesNextServer: 1 #对切换实例的重试次数，默认1
    
    hystrix:
      command:
        default:  #default全局有效，service id指定应用有效
          execution:
            timeout:
              #如果enabled设置为false，则请求超时交给ribbon控制,为true,则超时作为熔断根据
              enabled: true
            isolation:
              thread:
                timeoutInMilliseconds: 5000 #断路器超时时间，默认1000ms

测试2000ms:

成功了

![ce4d399f3bdd8ba00ef26820a2b7f6bb.png][]

*  调用4000ms

熔断了

![31820aa7faedf8e828a75867f9905a24.png][]

测试6000ms也是熔断

可见ReadTimeout和ConnectTimeout,当调用某个服务等待时间过长的时候, 对超时报错/熔断生效的是ReadTimeout,ConnectTimeout则表示连接服务的时间,一般不用配置太久,1~2秒左右就可以了。推荐：[Java进阶视频资源][Java]

**测试3**

现在来测试ReadTimeout和timeoutInMilliseconds谁起作用

测试2中的配置如下:

ReadTimeout: 3000   #负载均衡超时时间，默认值5000
    ConnectTimeout: 1000 #ribbon请求连接的超时时间，默认值2000
    timeoutInMilliseconds: 5000 #断路器超时时间，默认1000ms

在4000ms熔断了,2000ms正常,说明是ReadTimeout生效, 现在换成:

ReadTimeout: 5000   #负载均衡超时时间，默认值5000
    ConnectTimeout: 1000 #ribbon请求连接的超时时间，默认值2000
    timeoutInMilliseconds: 3000 #断路器超时时间，默认1000ms

也就是

ribbon:
      OkToRetryOnAllOperations: false #对所有操作请求都进行重试,默认false
      ReadTimeout: 5000   #负载均衡超时时间，默认值5000
      ConnectTimeout: 1000 #ribbon请求连接的超时时间，默认值2000
      MaxAutoRetries: 0     #对当前实例的重试次数，默认0
      MaxAutoRetriesNextServer: 1 #对切换实例的重试次数，默认1
    
    hystrix:
      command:
        default:  #default全局有效，service id指定应用有效
          execution:
            timeout:
              #是否开启超时熔断
              enabled: true
            isolation:
              thread:
                timeoutInMilliseconds: 3000 #断路器超时时间，默认1000ms
    
    feign.hystrix.enabled: true

2000ms 正常

![b65c034c5084083f842714fd6af95d99.png][]

4000ms 熔断

![84f5a2d835c3d7eedc9123c47a064b9d.png][]

说明熔断器timeoutInMilliseconds: 3000起作用了

**测试4**

这里再测一个配置:

这个enable如果为false, 则表示熔断器不根据自己配置的超时时间进行熔断,这样的话就会收到ribbon的ReadTimeout配置的影响了,超过这个时间,eureka-feign会抛出timeout的异常,这个时候熔断器就会因为这个异常而进行熔断

hystrix:
      command:
        default:  #default全局有效，service id指定应用有效
          execution:
            timeout:
              #是否开启超时熔断
              enabled: false

测试4000ms 正常

![b5aa8b146b4ff91d40a174df3d7788a3.png][]

测试6000ms 熔断. 此处是因为ribbon的ReadTimeout: 5000

![8f8c31aba3000e82960bc4e9b6bedbe5.png][]

### 3.总结 ###

由上面的测试可以得出:

*  如果`hystrix.command.default.execution.timeout.enabled`为true,则会有两个执行方法超时的配置,一个就是ribbon的ReadTimeout,一个就是熔断器hystrix的timeoutInMilliseconds, 此时谁的值小谁生效
 *  如果`hystrix.command.default.execution.timeout.enabled`为false,则熔断器不进行超时熔断,而是根据ribbon的ReadTimeout抛出的异常而熔断,也就是取决于ribbon
 *  ribbon的ConnectTimeout,配置的是请求服务的超时时间,除非服务找不到,或者网络原因,这个时间才会生效
 *  ribbon还有MaxAutoRetries对当前实例的重试次数,MaxAutoRetriesNextServer对切换实例的重试次数, 如果ribbon的ReadTimeout超时,或者ConnectTimeout连接超时,会进行重试操作
 *  由于ribbon的重试机制,通常熔断的超时时间需要配置的比ReadTimeout长,ReadTimeout比ConnectTimeout长,否则还未重试,就熔断了
 *  为了确保重试机制的正常运作,理论上（以实际情况为准）建议hystrix的超时时间为:`(1 + MaxAutoRetries + MaxAutoRetriesNextServer) * ReadTimeout`

ribbon:
      OkToRetryOnAllOperations: false #对所有操作请求都进行重试,默认false
      ReadTimeout: 10000   #负载均衡超时时间，默认值5000
      ConnectTimeout: 2000 #ribbon请求连接的超时时间，默认值2000
      MaxAutoRetries: 0     #对当前实例的重试次数，默认0
      MaxAutoRetriesNextServer: 1 #对切换实例的重试次数，默认1
    
    hystrix:
      command:
        default:  #default全局有效，service id指定应用有效
          execution:
            timeout:
              enabled: true
            isolation:
              thread:
                timeoutInMilliseconds: 20000 #断路器超时时间，默认1000ms

### 4.微服务优化 ###

#### 4.1 什么是hystrix ####

我们先来看这么一个图,假如订单服务需要调用积分服务,库存服务,仓储服务,订单服务的线程池有100个线程,这个时候积分服务突然挂了.这时候同时有大量的请求来访问订单服务,最终的结果是这100个线程都会卡在积分服务这里,这时候订单服务也没有多余的线程处理请求了,所以订单服务也差不多挂了.

![9f73316de1b0baee0affb65ee433e084.png][]

这就是微服务中的服务雪崩问题.

而这时你会发现,如果我只是看看这个商品还有多少库存,那么订单服务就只需要调用库存服务就可以了,并不受积分服务的影响.

这个时候就是Hystrix的时刻了,Hystrix是隔离、熔断以及降级的一个框架。

Hystrix的特点,就是针对不同的服务,会搞很多个小小的线程池,比如订单服务请求库存服务是一个单独的线程池,请求积分服务是一个单独的线程池. 这样虽然积分服务的线程池全部卡住了,但是不影响库存服务的调用.

#### 4.2 服务降级和熔断 ####

现在库存服务的问题解决了,积分服务还没解决啊. 比如积分服务网络很差,订单服务要一直傻等积分服务响应吗?单单看一个请求,用户等个几秒可能还没什么,如果100个线程都卡住几秒,后面的请求全部得不到处理. 所以我们可以让Hystrix在一定时间后主动返回,不再等待,这就是熔断.

降级,顾名思义,就是将不重要或者不紧急的任务,延迟处理,或者暂不处理.比如上面的超时熔断,熔断了怎么办?获取不到用户的积分,直接给用户提示网络繁忙,请稍后再试,就是一种延迟处理. 比如秒杀活动,为了防止并发量太大,通常会采取限流措施,降级后的处理方案可以是：排队页面（将用户导流到排队页面等一会重试）、无货（直接告知用户没货了）、错误页（如活动太火爆了，稍后重试）。

#### 4.3 微服务优化 ####

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

![daa8c53f7ea1e12cc6c87b825904bee9.png][]

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

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

**a. 如何设置Hystrix线程池大小**

Hystrix线程池大小默认为10

hystrix:
     threadpool:
      default:
       coreSize: 10

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

也就是

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

标准一点的公式就是`QPS * 99% cost + redundancy count`

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

`线程数 = 20 * 500 / 1000 = 10`

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

**b. 如何设置超时时间**

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

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

*（感谢阅读，希望对你所有帮助)*

*来源：blog.csdn.net/zzzgd\_666/article/details/83314833*

推荐好文

[**主流Java进阶技术（学习资料分享）**][Java]

[**分享一套基于SpringBoot和Vue的企业级中后台开源项目，代码很规范！**][SpringBoot_Vue]

[**能挣钱的，开源 SpringBoot 商城系统，功能超全，超漂亮**][SpringBoot]![917a4bf3c5a6ae09631bfd0daedeb1b6.png][]

[abc7f4fe263e14f772a01f100e1626d9.png]: /images/20220829/c329e1365926458f863e0b85e9fc2b21.png
[Java]: http://mp.weixin.qq.com/s?__biz=MzU2MTI4MjI0MQ%3D%3D&chksm=fc79b1b2cb0e38a498933a034926df45b51524b044762583488d498ae2112c06cf35d412fb3b&idx=2&mid=2247506972&scene=21&sn=790959d9ee2b74e0d0c8a0a5395bc665#wechat_redirect
[1c9496a23f86857a7a98398a70f16a06.png]: https://img-blog.csdnimg.cn/img_convert/1c9496a23f86857a7a98398a70f16a06.png
[8c4c2aa72eda8fc28bd1cc1c80a5b7e3.png]: /images/20220829/56b5eafe6bd34fe9a141f72c10dcef78.png
[7fe927bf63987815c4d769879efd47a1.png]: /images/20220829/0739f8f747314bfaa7a1690504416bfa.png
[ce4d399f3bdd8ba00ef26820a2b7f6bb.png]: /images/20220829/e5e1e4b46f494692aae036f0e3a6e840.png
[31820aa7faedf8e828a75867f9905a24.png]: /images/20220829/52e2ee1a76094c39a62b1b8387004b2a.png
[b65c034c5084083f842714fd6af95d99.png]: /images/20220829/cb987f32f3fe40529667016f7144e065.png
[84f5a2d835c3d7eedc9123c47a064b9d.png]: /images/20220829/5f0ba64ae11b484d8c50affb0f3cb47d.png
[b5aa8b146b4ff91d40a174df3d7788a3.png]: /images/20220829/90dbb6f76c374f559417887848b8f9d8.png
[8f8c31aba3000e82960bc4e9b6bedbe5.png]: /images/20220829/ea8aa5f1cc17431f8b3fd0d6bbf84c94.png
[9f73316de1b0baee0affb65ee433e084.png]: /images/20220829/ec1ca0adadb94308be6edc0780eec001.png
[daa8c53f7ea1e12cc6c87b825904bee9.png]: /images/20220829/21830c19e5fc4c79bf9404a2b3d0159c.png
[SpringBoot_Vue]: http://mp.weixin.qq.com/s?__biz=MzU2MTI4MjI0MQ%3D%3D&chksm=fc799be6cb0e12f0b58479f8b031bc5ae79efdca1880ff9b19f0a107c3a88c37b9596dc73203&idx=2&mid=2247497288&scene=21&sn=65d7111a19e920df1e9416959594b2f4#wechat_redirect
[SpringBoot]: http://mp.weixin.qq.com/s?__biz=MzU2MTI4MjI0MQ%3D%3D&chksm=fc799a9ccb0e138a64a2671f31b8d4be1b3c061a288f7b0d1d4af02a60c45a72231446b91e00&idx=2&mid=2247497522&scene=21&sn=c5b4e596be4ac7d7f293e7e2f0ea0769#wechat_redirect
[917a4bf3c5a6ae09631bfd0daedeb1b6.png]: /images/20220829/c4cad4a024184bf7b42a291b51e5afd3.png