1 前言
上节我们看了下 OpenFeign 里的重试，后来我从源码的角度看了下它的原理，发现一个诡异的情况，就是我没开启重试的情况下，我的服务却被调用了两次，这是为什么呢？本节我们来看看这个问题。
2 环境准备
首先准备一下，我这里有两个服务，一个是 demo 一个是 virtuous，本地启动的 Eureka。
一个简单的调用过程，我这里简单画个图，这里比上节多了个 POST 方法的调用：
TestFeign 里有两个方法，一个是 GET 请求方式的，一个是 POST 请求方式的：
/**
* @author: kuku
* @description
*/
@FeignClient(value = "demo", path = "/user/", contextId = "testFeign")
public interface TestFeign {
@GetMapping(value = "/testFeign", produces = {"application/json"})
void testFeign();
@PostMapping(value = "/testPostFeign", produces = {"application/json"})
void testPostFeign(Map<String, Object> map);
}
我在 Virtuous 服务里配置了响应超时为 1 秒，并且在被调用服务里睡眠了 2 秒，来触发响应超时。
# 响应超时时间 feign.client.config.default.read-timeout=1000
3 问题现象
我们现在可以调用一下 GET 方式的请求：
这是 Virtuous 服务的 feign 请求日志：
可以看到我们的 Demo 服务被调用了两次：
那我们再试一下 POST 方式的，可以看到 POST 方式的只打印了一次：
至于为什么我这里多放一个 POST 的方式，是因为我分析完源码，发现只有 GET 方式下才会多调用一次，其他请求方式都不会多调用一次，大家也可以换一种别的请求方式试试。
那么接下来我们就从源码的角度看看，为什么没开启重试的情况下，GET 方式怎么会多调用一次呢？
4 源码分析
如果你对 OpenFeign 一点儿不了解的话，可以看看我之前的 【OpenFeign】@FeignClient 注入过程源码分析以及【OpenFeign】@FeignClient 代理对象的创建源码分析。
从哪里看起呢，就从它的执行看起吧，它的 Bean 是由 FeignClientFactoryBean 创建的，最后的落点是在 ReflectiveFeign 的 newInstance 方法中：
@Override
public <T> T newInstance(Target<T> target) {
Map<String, MethodHandler> nameToHandler = targetToHandlersByName.apply(target);
Map<Method, MethodHandler> methodToHandler = new LinkedHashMap<Method, MethodHandler>();
List<DefaultMethodHandler> defaultMethodHandlers = new LinkedList<DefaultMethodHandler>();
for (Method method : target.type().getMethods()) {
if (method.getDeclaringClass() == Object.class) {
continue;
} else if (Util.isDefault(method)) {
DefaultMethodHandler handler = new DefaultMethodHandler(method);
defaultMethodHandlers.add(handler);
methodToHandler.put(method, handler);
} else {
methodToHandler.put(method, nameToHandler.get(Feign.configKey(target.type(), method)));
}
}
/**
* InvocationHandlerFactory 工厂
* static final class Default implements InvocationHandlerFactory {
* @Override
* public InvocationHandler create(Target target, Map<Method, MethodHandler> dispatch) {
* return new ReflectiveFeign.FeignInvocationHandler(target, dispatch);
* }
* }
* 可以看到最后返回的增强逻辑是 ReflectiveFeign.FeignInvocationHandler
* 这里的 dispatch 是个 map
* key 就是你的 feign 的每个方法
* value 是方法的处理器 落点类是 SynchronousMethodHandler
*/
InvocationHandler handler = factory.create(target, methodToHandler);
// JDK 代理方式创建
T proxy = (T) Proxy.newProxyInstance(target.type().getClassLoader(),
new Class<?>[] {target.type()}, handler);
...
return proxy;
}
那么我们的 Feign 实际执行的时候，是不是就先走 JDK代理的增强逻辑了，是不是就是这里的 ReflectiveFeign.FeignInvocationHandler， 我们进去看看：
// FeignInvocationHandler
static class FeignInvocationHandler implements InvocationHandler {
private final Target target;
private final Map<Method, MethodHandler> dispatch;
FeignInvocationHandler(Target target, Map<Method, MethodHandler> dispatch) {
this.target = checkNotNull(target, "target");
this.dispatch = checkNotNull(dispatch, "dispatch for %s", target);
}
@Override
public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
// equals hashCode toString 方法略过
if ("equals".equals(method.getName())) {
try {
Object otherHandler =
args.length > 0 && args[0] != null ? Proxy.getInvocationHandler(args[0]) : null;
return equals(otherHandler);
} catch (IllegalArgumentException e) {
return false;
}
} else if ("hashCode".equals(method.getName())) {
return hashCode();
} else if ("toString".equals(method.getName())) {
return toString();
}
// 获取到当前要执行方法的 MethodHandler（SynchronousMethodHandler） 执行它的 invke 方法
return dispatch.get(method).invoke(args);
}
...
}
接下来我们进入 SynchronousMethodHandler 的 invoke 方法：
// SynchronousMethodHandler
@Override
public Object invoke(Object[] argv) throws Throwable {
// 构建请求模版 这是 feign 核心包里的
RequestTemplate template = buildTemplateFromArgs.create(argv);
Options options = findOptions(argv);
// 大家别被这个 retryer 误解，其实它就是 Retryer 接口中的 NEVER_RETRY 也就是不重试 有错就直接抛错
Retryer retryer = this.retryer.clone();
while (true) {
try {
// 执行请求
return executeAndDecode(template, options);
} catch (RetryableException e) {
try {
// 执行重试器的 continueOrPropagate 方法
// 简单看下不重试的内容其实就是直接抛出异常
// Retryer NEVER_RETRY = new Retryer() {
// @Override
// public void continueOrPropagate(RetryableException e) {
// throw e;
// }
// }
retryer.continueOrPropagate(e);
} catch (RetryableException th) {
Throwable cause = th.getCause();
if (propagationPolicy == UNWRAP && cause != null) {
throw cause;
} else {
throw th;
}
}
if (logLevel != Logger.Level.NONE) {
logger.logRetry(metadata.configKey(), logLevel);
}
continue;
}
}
}
继续看看 executeAndDecode 方法都做了些什么：
// SynchronousMethodHandler
Object executeAndDecode(RequestTemplate template, Options options) throws Throwable {
Request request = targetRequest(template);
if (logLevel != Logger.Level.NONE) {
logger.logRequest(metadata.configKey(), logLevel, request);
}
response;
long start = System.nanoTime();
try {
// 执行请求
response = client.execute(request, options);
// ensure the request is set. TODO: remove in Feign 12
// 构建 Response
response = response.toBuilder()
.request(request)
.requestTemplate(template)
.build();
} catch (IOException e) {
// 处理 IO 异常 比如响应超时 就会进入到这里
if (logLevel != Logger.Level.NONE) {
logger.logIOException(metadata.configKey(), logLevel, e, elapsedTime(start));
}
// 抛出 RetryableException 重试异常
throw errorExecuting(request, e);
}
// 正常响应 走下边这里 解码并返回结果
long elapsedTime = TimeUnit.NANOSECONDS.toMillis(System.nanoTime() - start);
if (decoder != null)
return decoder.decode(response, metadata.returnType());
// ...
}
}
看到 Client 的 execute 方法，因为我们的 Feign 是设置的服务名称，所以这里的 Client 是负载均衡型的 LoadBalancerFeignClient：
那我们看看它的 execute 方法：
// LoadBalancerFeignClient
@Override
public Response execute(Request request, Request.Options options) throws IOException {
try {
// URI 处理
URI asUri = URI.create(request.url());
String clientName = asUri.getHost();
URI uriWithoutHost = cleanUrl(request.url(), clientName);
FeignLoadBalancer.RibbonRequest ribbonRequest = new FeignLoadBalancer.RibbonRequest(
this.delegate, request, uriWithoutHost);
IClientConfig requestConfig = getClientConfig(options, clientName);
// lbClient方法 返回一个 FeignLoadBalancer 类型对象实际落点是 RetryableFeignLoadBalancer
// 它首先会从本地缓存获取服务的实例列表
// 不为空就用本地的，为空的话就从注册中心重新获取服务实例
// 然后执行请求 executeWithLoadBalancer
return lbClient(clientName)
.executeWithLoadBalancer(ribbonRequest, requestConfig).toResponse();
}
catch (ClientException e) {
IOException io = findIOException(e);
if (io != null) {
throw io;
}
throw new RuntimeException(e);
}
}
那么就到了 RetryableFeignLoadBalancer 的 executeWithLoadBalancer 方法，它是继承了 AbstractLoadBalancerAwareClient，所以这里看他父类的：
// AbstractLoadBalancerAwareClient
public T executeWithLoadBalancer(final S request, final IClientConfig requestConfig) throws ClientException {
// 看名称的话 像是命令模式
// 说实话这块我没太看懂 我们先看主流程
LoadBalancerCommand<T> command = this.buildLoadBalancerCommand(request, requestConfig);
try {
// 先 submit
return (IResponse)command.submit(new ServerOperation<T>() {
public Observable<T> call(Server server) {
URI finalUri = AbstractLoadBalancerAwareClient.this.reconstructURIWithServer(server, request.getUri());
S requestForServer = request.replaceUri(finalUri);
try {
// 最后会执行到这里 外边被套的一层我们可以先忽略
return Observable.just(AbstractLoadBalancerAwareClient.this.execute(requestForServer, requestConfig));
} catch (Exception var5) {
return Observable.error(var5);
}
}
})
// 再 blocking
.toBlocking()
// 再执行
.single();
} catch (Exception var6) {
Throwable t = var6.getCause();
if (t instanceof ClientException) {
throw (ClientException)t;
} else {
throw new ClientException(var6);
}
}
}
AbstractLoadBalancerAwareClient.this.execute(requestForServer, requestConfig) 因为当前是 RetryableFeignLoadBalancer 所以继续执行它的 execute 方法：
// RetryableFeignLoadBalancer
@Override
public RibbonResponse execute(final RibbonRequest request, IClientConfig configOverride) throws IOException {
// ...
// 重试策略
// 创建的是 RibbonLoadBalancedRetryPolicy
final LoadBalancedRetryPolicy retryPolicy = this.loadBalancedRetryFactory
.createRetryPolicy(this.getClientName(), this);
RetryTemplate retryTemplate = new RetryTemplate();
// ...
// 设置重试策略 可以看到用 FeignRetryPolicy 包装了一层 这里标记下 我们下边要用到
retryTemplate.setRetryPolicy(retryPolicy == null ? new NeverRetryPolicy() : new FeignRetryPolicy(request.toHttpRequest(), retryPolicy, this, this.getClientName()));
// 执行 哎哟 又是两个大 lambda 看的就头疼
// 我们这里看的是第一个表达式
return retryTemplate.execute(retryContext -> {
Request feignRequest = null;
// on retries the policy will choose the server and set it in the context
// extract the server and update the request being made
if (retryContext instanceof LoadBalancedRetryContext) {
ServiceInstance service = ((LoadBalancedRetryContext) retryContext)
.getServiceInstance();
if (service != null) {
feignRequest = ((RibbonRequest) request
.replaceUri(reconstructURIWithServer(
new Server(service.getHost(), service.getPort()),
request.getUri()))).toRequest();
}
}
if (feignRequest == null) {
feignRequest = request.toRequest();
}
// 执行请求
Response response = request.client().execute(feignRequest, options);
if (retryPolicy != null
&& retryPolicy.retryableStatusCode(response.status())) {
byte[] byteArray = response.body() == null ? new byte[] {}
: StreamUtils.copyToByteArray(response.body().asInputStream());
response.close();
throw new RibbonResponseStatusCodeException(
RetryableFeignLoadBalancer.this.clientName, response, byteArray,
request.getUri());
}
// 返回结果
return new RibbonResponse(request.getUri(), response);
}, new LoadBalancedRecoveryCallback<RibbonResponse, Response>() {
@Override
protected RibbonResponse createResponse(Response response, URI uri) {
return new RibbonResponse(uri, response);
}
});
}
接下来继续进入 RetryTemplate 的 execute 方法，就到我们本节看的重点了，你们说这想实现一个功能谈何容易啊，进过了多少类多少个方法了都，我们看看：
// RetryTemplate
@Override
public final <T, E extends Throwable> T execute(RetryCallback<T, E> retryCallback, RecoveryCallback<T> recoveryCallback) throws E {
return doExecute(retryCallback, recoveryCallback, null);
}
// 接下来就到我们本节的重点了
protected <T, E extends Throwable> T doExecute(RetryCallback<T, E> retryCallback, RecoveryCallback<T> recoveryCallback, RetryState state) throws E, ExhaustedRetryException {
RetryPolicy retryPolicy = this.retryPolicy;
BackOffPolicy backOffPolicy = this.backOffPolicy;
// Allow the retry policy to initialise itself...
RetryContext context = open(retryPolicy, state);
if (this.logger.isTraceEnabled()) {
this.logger.trace("RetryContext retrieved: " + context);
}
// Make sure the context is available globally for clients who need
// it...
RetrySynchronizationManager.register(context);
Throwable lastException = null;
boolean exhausted = false;
try {
// Give clients a chance to enhance the context... 执行监听器 默认是空的
boolean running = doOpenInterceptors(retryCallback, context);
if (!running) {
throw new TerminatedRetryException(
"Retry terminated abnormally by interceptor before first attempt");
}
// Get or Start the backoff context...
BackOffContext backOffContext = null;
Object resource = context.getAttribute("backOffContext");
if (resource instanceof BackOffContext) {
backOffContext = (BackOffContext) resource;
}
if (backOffContext == null) {
backOffContext = backOffPolicy.start(context);
if (backOffContext != null) {
context.setAttribute("backOffContext", backOffContext);
}
}
/*
* We allow the whole loop to be skipped if the policy or context already
* forbid the first try. This is used in the case of external retry to allow a
* recovery in handleRetryExhausted without the callback processing (which
* would throw an exception).
*/
// !!! 这里就是我们本节要看的重点 canRetry
while (canRetry(retryPolicy, context) && !context.isExhaustedOnly()) {
try {
// 发送请求
return retryCallback.doWithRetry(context);
}
catch (Throwable e) {
// ...
if (canRetry(retryPolicy, context) && !context.isExhaustedOnly()) {
try {
backOffPolicy.backOff(backOffContext);
}
catch (BackOffInterruptedException ex) {
// ...
throw ex;
}
}
// ...
}
if (state != null && context.hasAttribute(GLOBAL_STATE)) {
break;
}
}
// ...
}
catch (Throwable e) {
throw RetryTemplate.<E>wrapIfNecessary(e);
}
finally {
close(retryPolicy, context, state, lastException == null || exhausted);
doCloseInterceptors(retryCallback, context, lastException);
RetrySynchronizationManager.clear();
}
}
首先第一次进入 canRetry 方法：
// 是否可以重试
protected boolean canRetry(RetryPolicy retryPolicy, RetryContext context) {
// 直接调用重试策略 我们刚才看到的重试策略是 用 FeignRetryPolicy 包装了一层的 RibbonLoadBalancedRetryPolicy
return retryPolicy.canRetry(context);
}
那我们看看 FeignRetryPolicy 的 canRetry 方法：
// FeignRetryPolicy
@Override
public boolean canRetry(RetryContext context) {
// retryCount 第一次请求为 0 所以第一次判断是否可以的时候 直接返回 true
if (context.getRetryCount() == 0) {
return true;
}
return super.canRetry(context);
}
也就是当第一次发送请求的时候，这时候因为 retryCount == 0 所以直接返回 true ，可以发送第一次请求，当第一次请求失败的情况下，继续进入到 canRetry 方法，这时候 retryCount = 1，
那么再次进来的时候，不满足
// FeignRetryPolicy
@Override
public boolean canRetry(RetryContext context) {
// retryCount 第二次请求 count =1 不满足所以执行 super.canRetry 方法
if (context.getRetryCount() == 0) {
return true;
}
return super.canRetry(context);
}
那我们看看父类的 canRetry 方法：
// InterceptorRetryPolicy
public class InterceptorRetryPolicy implements RetryPolicy {
//
public boolean canRetry(RetryContext context) {
LoadBalancedRetryContext lbContext = (LoadBalancedRetryContext)context;
// 因为 count = 1 所以这里不满足走 else
if (lbContext.getRetryCount() == 0 && lbContext.getServiceInstance() == null) {
lbContext.setServiceInstance(this.serviceInstanceChooser.choose(this.serviceName));
return true;
} else {
// this.policy 是谁
// 我们上边是不是说了 它是用 FeignRetryPolicy 包装了一层的 RibbonLoadBalancedRetryPolicy
return this.policy.canRetryNextServer(lbContext);
}
}
}
所以我们最后看一下 RibbonLoadBalancedRetryPolicy 的 canRetryNextServer 方法：
// RibbonLoadBalancedRetryPolicy
public boolean canRetryNextServer(LoadBalancedRetryContext context) {
// 左边的表达式是满足的 我们直接看右边的 canRetry
return this.nextServerCount <= this.lbContext.getRetryHandler().getMaxRetriesOnNextServer() && this.canRetry(context);
}
// RibbonLoadBalancedRetryPolicy
public boolean canRetry(LoadBalancedRetryContext context) {
HttpMethod method = context.getRequest().getMethod();
// 唉 是不是一下豁然开朗了 就是这里了 是 GET 请求 返回 true
return HttpMethod.GET == method || this.lbContext.isOkToRetryOnAllOperations();
}
哎哟，最后看到这里，算是差不多到头了。
另外插入一个跟本节没关的，当我们没有配置重试的情况下，默认的重试器是 NEVER，可以在 FeignClientsConfiguration 看到，它也是位于 Retryer 接口中的一个默认实现：
5 小结
以前还真没碰到过这种情况，大概知道 GET 请求为什么会多一次请求的原因了，那么为什么要这么设计呢？还请知道的小伙伴指点一下，本节就看到这里哈，下节再看重试器的源码。
标签：return,OpenFeign,canRetry,下未,request,重试,context,new,null From： https://www.cnblogs.com/kukuxjx/p/18405166