浅谈SpringCloud 如何使用OpenFeign进行请求重试？

亦凉 2024-03-24 14:48 40阅读 0赞

### 前言 ###

真实的微服务业务场景中，可能出现跨服务调用失败的情况。最常见的就是被调用的服务正在发布，由于微服务之间通常有依赖关系，发布有一定的先后顺序，对于一个微服务应用常见的发布策略有两种

*  先停掉集群中一半的实例，然后重新启动这些应用，完成之后再停掉另一半的集群实例重新启动。
 *  一台实例一台实例重启

那么此时被停掉的应用会处于临时的不可用，但是下线的信息还没有被同步到注册中心，导致 `Feign` 调用的时候还是有可能被负载均衡策略选择到已经停掉的机器，从而导致调用失败。这种情况下我们应该要重新发起一次请求。

### 请求重试前置知识 ###

在决定做重试前，我们应该要思考以下几个问题

*  `200、4xx、5xx` 哪些错误响应码需要重试？
 *  `GET、POST、PUT、DELETE...` 什么类型的请求可以重试？
 *  重试的这次请求怎样避免再次访问到不可用实例？

我们可以先认真思考上述问题，然后我们开始分析上述问题。

#### 哪些错误响应码需要重试 ####

常见的响应码除了`200` 就是 `4xx、5xx` 了。通常 `4xx` 错误是不该重试的，因为这是客户端错误。以 `400、405` 为例，不管重试多少次都是一样的结果，没必要浪费系统资源。

接下来就是 `5xx` 了，`503` 是肯定应该重试的，那 `500` 要不要重试？这个东西很难去界定，如果说是因为程序本身的 `bug` 导致，那大概率不用重试，因为还会失败。如果被调用方请求了一个第三方接口，然后因为奇怪的原因返回了奇怪的异常。这种我觉得是可以进行重试的，所以对于 `5xx` 我觉得可以定义一些特殊的异常标明它们是可重试的。

具体对哪些响应码/哪些异常重试还是看不同公司，还有很多公司无论请求成功失败一律返回 `200` 的呢对吧。。。。

#### 哪些请求类型可以重试 ####

接口的幂等性，这是很重要的一点，你敢对 `POST` 请求重试吗？即便不是微服务的调用，在设计普通 `Rest` 接口时我们也要考虑接口的幂等性。对于 `POST` 这种本身就不幂等的 `HTTP` 请求，对它开启重试不是自己给自己找 `bug` 吗。顺便想提一句那些啥请求都 `POST` 一把梭的公司做微服务调用重试的时候是不是又要加工作量了......当然车到山前必有路，很可能别人会采取不通过 `OpenFeign` 重试来解决问题~~

我们都知道 `HTTP` 请求中 `GET、HEAD、PUT、DELETE` 等方法都是幂等的，所以在正确的实现下我们可以对这些请求类型进行重试。

#### 重试如何选择到可用实例 ####

以新一代负载均衡器 `SpringCloud LoadBalancer` 为例，提供了两种负载均衡策略实现。

*  `RoundRobinLoadBalancer` 轮询（默认）
 *  `RandomLoadBalancer` 随机

在应用发布的场景下，无论是一台一台发布还是一半一半发布，这两种策略都没法保证我们重试的那一次能够访问到可用的实例。具体原因和解决方案我将会在后面 `SpringCloud LoadBalancer` 文章中分析。

### OpenFeign 开启重试 ###

`OpenFeign` 是通过 `Retry` 来实现重试的，默认是关闭该功能的，这一点我们可以从 `FeignClientsConfiguration` 里面看到

@Bean
    @ConditionalOnMissingBean
    public Retryer feignRetryer() {
       return Retryer.NEVER_RETRY; //代表永远不重试
    }
    复制代码

所以开启重试我们只需要自己定义一个 `Retry` 的 `Bean` 即可。

@Bean
    public Retryer retryer(){
        return new Retryer.Default();
    }
    复制代码

我们观察 `Retry.Default` 类的核心成员变量

private final int maxAttempts; //最大重试次数，初始调用算一次，默认实现值是 5 
    private final long period;     //初始重试间隔 ，默认实现值是 100 ms
    private final long maxPeriod;  //最大重试间隔 ，默认实现值是 1000 ms
    复制代码

### Retryer 重试的原理 ###

这个其实很简单，追踪一下 `OpenFeign` 调用的源码即可， `SynchronousMethodHandler` 类

@Override
    public Object invoke(Object[] argv) throws Throwable {
      //可以看到 OpenFeign 就是用 RestTemplate 实现远程调用的
      RequestTemplate template = buildTemplateFromArgs.create(argv);
      Options options = findOptions(argv);
      Retryer retryer = this.retryer.clone();
      while (true) {
        try {
          return executeAndDecode(template, options);
        } catch (RetryableException e) {
          try {
            retryer.continueOrPropagate(e);
          } catch (RetryableException th) {
            //...省略throw
            //...省略日志
            continue;
          }
        }
      }
    }
    复制代码

代码中上来就是一个循环，如果我们调用过程中抛出了 `RetryableException`，并且 `retryer.continueOrPropagate(e)` 还没超过重试次数就继续发起请求，如果到了重试次数就抛出异常结束循环。这问题就简单了，也就是说如果我们要控制 `OpenFeign` 发起重试只需要抛出 `RetryableException` 。

### 实现 ErrorDecoder ###

前面的文章我们提到了 `Feign` 的解码器，用于解析正常响应的结果。其实在 `Feign` 的错误响应结果也有一个专用的解码器。

return executeAndDecode(template, options);
    复制代码

在这行代码中如果出现了异常会调用 `ErrorDecoder.decode()`。默认的实现逻辑中，会根据响应头来判断要不要抛出 `RetryableException`。观察源码

@Override
    public Exception decode(String methodKey, Response response) {
      FeignException exception = errorStatus(methodKey, response);
      //根据 response 里面的 header.Retry-After 来决定要不要重试
      Date retryAfter = retryAfterDecoder.apply(firstOrNull(response.headers(), RETRY_AFTER));
      if (retryAfter != null) {
        return new RetryableException(
            response.status(),
            exception.getMessage(),
            response.request().httpMethod(),
            exception,
            retryAfter,
            response.request());
      }
      return exception;
    }
    复制代码

感觉怪怪的，这样是否需要重试决定权在被调用方，我觉得还是自己在客户端一方根据响应码去决定要不要重试会更好。所以我们可以实现自己的 `ErrorDecoder` 。

@Configuration
    public class FeignErrorDecoder implements ErrorDecoder {
        @Override
        public Exception decode(String methodKey, Response response) {
            if (is4xx(response.status())) {
                log.error("请求xxx服务-{},返回:{}", response.status(), response.body());
                throw new ClientException(response.status(), "xx");
            }
            FeignException exception = errorStatus(methodKey, response);
            if (response.request().httpMethod() == Request.HttpMethod.GET) { //只对 GET 重试
                return new RetryableException(
                        response.status(),
                        exception.getMessage(),
                        response.request().httpMethod(),
                        exception,
                        new Date(),
                        response.request());
            }
            return exception;
        }
    }
    复制代码

### 超时重试 ###

`Feign` 默认会重试 `IOException`，例如最常见的超时，首先我们配置超时时间

feign:
      client:
        config:
          default:
            connectTimeout: 100 #单位 ms
            readTimeout: 100    #单位 ms
    复制代码

只要超过配置时间还未得到响应，当前应用就会抛出

java.net.SocketTimeoutException: Read timed out
    复制代码

它属于 `IOException` 。然后下面这行代码

return executeAndDecode(template, options);
    复制代码

这个方法内部捕捉了 `IOException` ，将它封装成 `RetryException` 抛出去触发 `Retry` 重试。对于 `IOException` 源码中会将它视为短暂网络抖动异常。

### 200 一把梭的方案怎么重试 ###

很多公司没有按照规范来，无论接口响应是成功还是失败给的 HTTP 响应都是 200 。然后类似以下格式包装

HTTP 200 OK
    {
        "success": true/false,
        "code": "0/1",
        "message": "success/error",
        "data": Object/xxxException
    }
    复制代码

这种情况无论成功还是失败，Http 的响应都是 200，也就是说它是不会走到 `ErrorDecoder.decoder()` 方法的，那我们要怎样控制它失败的时候抛出 `RetryException` 触发重试呢？我们已经知道如何自定义 `Feign` 响应的 `Decoder`。我们仿照之前自定义的 `Decoder`，解析这个响应体，根据上述结构解析出来的 `code` （前提是 `JSON` 内部结构要存在一个正确的 `HTTP.code`）去抛出 `RetryException`。部分代码如下：

com.feign.test.config.Response<?> result =
        ( com.feign.test.config.Response<?>) this.decoder.decode(response, newType);
    log.info("-----{}---",result);
    if(result.code == 500){
        return new RetryableException(
                result.code,
                result.message,
                response.request().httpMethod(),
                new RuntimeException(),
                new Date(),
                response.request());
    }
    复制代码

我本以为触发异常能够让他走到 `ErrorDecoder.decode`，但实际上没有，跟踪源码我们发现`AsyncResponseHandler.handleResponse()`内部核心代码

else if (response.status() >= 200 && response.status() < 300) {
      if (isVoidType(returnType)) {
        resultFuture.complete(null);
      } else {
        final Object result = decode(response, returnType); // 这里并没有向外抛出 RetryException 有点奇怪
        shouldClose = closeAfterDecode;
        resultFuture.complete(result);
      }
    复制代码

很遗憾未能解决......我也懒得再去看怎么解决了，这就是不遵守规范的后果，后面要花费更多的精力来填坑！！！所以，自定义数据响应结构没关系，你可以把业务状态码包在内部结构里面，重要的是你特喵的要用标准的 HTTP 响应码啊！！！

### 重试雪崩 ###

重试雪崩就是一个连串的微服务调用其中一个节点报错，会导致上游服务触发指数级别的重试次数。

这是个非常严重的问题，假设有一个业务流程非常复杂，其微服务调用流程是 `A → B → C → D`。我们都配置了调用失败重试，`maxAttempts = 5`。`C → D` 的过程中失败了，这时候会返回到 `C`，触发 `C` 重试五次，然后五次都失败会返回到 `B` ，又触发 `B` 的五次重试，`B` 的每次重试都会导致 `C` 重试五次 `D`，完了之后 `D` 已经重试了 `25` 次，`B` 五次失败又返回到 `A`，触发 `A` 的五次重试，完了之后 `D` 总共被调用了 `5*5*5 = 125` 次 。

![format_png][]

一个用户 `125` 次对于请求压力还不算什么，对于数据库的压力就很大了。我草，随便出个 `bug` 几百用户量就能瞬间把系统干垮了。。。。可怕吧？

如何防止重试雪崩？如果你的业务场景几乎只存在短链路调用，不会存在跨三个微服务的情况，那就不用考虑这个问题了。但是随着业务扩展，总是会出现长链路的调用场景，后面我们会学习如何防止重试雪崩。

### 结语 ###

本篇文章简单介绍了 `OpenFeign` 的重试相关知识。

[format_png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/cace9f8b1bca439f9a1e91b73ef32ef1.png