前言
真实的微服务业务场景中，可能出现跨服务调用失败的情况。最常见的就是被调用的服务正在发布，由于微服务之间通常有依赖关系，发布有一定的先后顺序，对于一个微服务应用常见的发布策略有两种
- 先停掉集群中一半的实例，然后重新启动这些应用，完成之后再停掉另一半的集群实例重新启动。
- 一台实例一台实例重启
那么此时被停掉的应用会处于临时的不可用，但是下线的信息还没有被同步到注册中心，导致 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 触发重试呢？前面的文章 SpringCloud OpenFeign 自定义响应解码器 。我们已经知道如何自定义 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 次 。
image.png
一个用户 125 次对于请求压力还不算什么，对于数据库的压力就很大了。我草，随便出个 bug 几百用户量就能瞬间把系统干垮了。。。。可怕吧？
如何防止重试雪崩？如果你的业务场景几乎只存在短链路调用，不会存在跨三个微服务的情况，那就不用考虑这个问题了。但是随着业务扩展，总是会出现长链路的调用场景，后面我们会学习如何防止重试雪崩。
网友评论