SpringCloud中Feign最佳实践和Feign与Hystrix的超时机制关系

发表于 | 分类于

SpringCloud中Feign最佳实践和Feign与Hystrix的超时机制关系

0x01 Feign最佳实践

SpringCloud这套框架刚流行没多久，网上很多相关的文章，比如Feign一般的案例都是：

  • Feign单独的项目写一遍Rest接口
  • 生产者一份RestController代码，再照着Feign写一遍接口
  • 消费者依赖Feign模块或者项目调用

这里出现的问题就是Feign和生产者的接口方法和@GetMapping等重复，稍不注意就容易写错导致请求不到，还会增加代码复杂度，而且增加一个接口，生产者一定要去实现，没有约束；

下面讲一下我们对Feign的优化；

  1. 每个项目有一个context模块和feign模块。（当然也可以把feign全部抽取到一个公共的项目中）
    模块分类
  2. 首先在feign模块中建立对应的feign；eg：UserClient并定义接口和对应的请求
    接口定义
  3. 在我们的生产者的Controller中实现UserFeign（接口约束 + 不用重新定义@RequestMapping）
    接口实现

这样的方式就可以避免上面所说的问题；

0x02 Feign和Hystrix的超时机制？

这两个都可以配置单独的超时机制，但是到底谁生效，怎么控制他们这个问题刚开始接触会有点懵；
生产端测试代码（自己有空可以试试）：

1
2
3
4
5
@RequestMapping("/test")
public String test(@RequestParam("time") int time) {
    TimeUnit.MILLISECONDS.sleep(time);
    return "result";
}

并在Feign中开启和配置Hystrix的熔断

1
2
3
4
5
@Override
public String test(int time) {
    System.out.println("触发熔断");
    return "触发熔断";
}

然后修改Ribbon和Hystrix的参数来逐一测试；

1
2
3
4
5
6
7
8
9
10
11
12
hystrix:
  command:
    default:             #default全局，指定service id应用有效
      execution:
        timeout:
          enabled: true  #false，请求超时交给ribbon控制,为true,超时熔断处理
        isolation:
          thread:
            timeoutInMilliseconds: 1000     #断路器超时时间
ribbon:
  ReadTimeout: 5000    #请求超时时间
  ConnectTimeout: 2000 #连接的超时时间！服务找不到或者网络原因才会用这个

得出如下结论：

  • 当hystrix的timeout.enable = true时，两个超时配置同时会启用，谁小就谁先生效
  • 当hystrix的timeout.enable = false时，只会使用ribbon的超时配置抛出异常，并熔断
  • 一般建议熔断的时间 > ribbon的超时时间，这个还要看你有没有配置重试机制来决定