您的位置: 首页  >  文章  >  SpringCloud之feign的各种超时时间配置效果

SpringCloud之feign的各种超时时间配置效果

分类: 文章 • 2023-12-02 21:38:16

1. 前言

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

  1. zuul网关
#默认1000
zuul.host.socket-timeout-millis=2000
#默认2000
zuul.host.connect-timeout-millis=4000
  1. ribbon

ribbon:
  OkToRetryOnAllOperations: false #对所有操作请求都进行重试,默认false
  ReadTimeout: 5000   #负载均衡超时时间，默认值5000
  ConnectTimeout: 3000 #ribbon请求连接的超时时间，默认值2000
  MaxAutoRetries: 0     #对当前实例的重试次数，默认0
  MaxAutoRetriesNextServer: 1 #对切换实例的重试次数，默认1
  1. 熔断器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-feign

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 );
    }

service:

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

熔断方法:

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

测试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
  • 测试 500ms

SpringCloud之feign的各种超时时间配置效果
SpringCloud之feign的各种超时时间配置效果
请求正常.

  • 测试 2000ms
    熔断
    SpringCloud之feign的各种超时时间配置效果

接着测试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:
成功了
SpringCloud之feign的各种超时时间配置效果

调用4000ms
熔断了
SpringCloud之feign的各种超时时间配置效果

测试6000ms也是熔断

可见ReadTimeout和ConnectTimeout,服务生产者在耗时过长的时候, 对超时报错/熔断生效的是ReadTimeout,ConnectTimeout则表示连接服务的时间,一般不用配置太久,1~2秒左右就可以了

测试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 正常
SpringCloud之feign的各种超时时间配置效果

4000ms 熔断
SpringCloud之feign的各种超时时间配置效果

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

测试4

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

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

测试4000ms 正常
SpringCloud之feign的各种超时时间配置效果

测试6000ms 熔断. 此处是因为ribbon的ReadTimeout: 5000
SpringCloud之feign的各种超时时间配置效果

3.总结

由上面的测试可以得出:

  1. 如果hystrix.command.default.execution.timeout.enabled为true,则会有两个执行方法超时的配置,一个就是ribbon的ReadTimeout,一个就是熔断器hystrix的timeoutInMilliseconds, 此时谁的值小谁生效
  2. 如果hystrix.command.default.execution.timeout.enabled为false,则熔断器不进行超时熔断,而是根据ribbon的ReadTimeout抛出的异常而熔断,也就是取决于ribbon
  3. ribbon的ConnectTimeout,配置的是请求服务的超时时间,除非服务找不到,或者网络原因,这个时间才会生效
  4. ribbon还有MaxAutoRetries对当前实例的重试次数,MaxAutoRetriesNextServer对切换实例的重试次数, 如果ribbon的ReadTimeout超时,或者ConnectTimeout连接超时,会进行重试操作
  5. 通常熔断的超时时间需要配置的比ReadTimeout长,ReadTimeout比ConnectTimeout长
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: 10000 #断路器超时时间，默认1000ms

相关推荐