Dubbo源码分析----发起请求

从如下代码中还是分析

String sayHello = demoService.sayHello("123123");

我们知道demoService实际上是一个代理对象,那么假设使用的是JDK的代码,看看获取代理的地方

public class JdkProxyFactory extends AbstractProxyFactory {

    @SuppressWarnings("unchecked")
    public  T getProxy(Invoker invoker, Class[] interfaces) {
        return (T) Proxy.newProxyInstance(Thread.currentThread().getContextClassLoader(), interfaces,
                         new InvokerInvocationHandler(invoker));
    }

    public  Invoker getInvoker(T proxy, Class type, URL url) {
        return new AbstractProxyInvoker(proxy, type, url) {
            @Override
            protected Object doInvoke(T proxy, String methodName, 
                                      Class[] parameterTypes, 
                                      Object[] arguments) throws Throwable {
                Method method = proxy.getClass().getMethod(methodName, parameterTypes);
                return method.invoke(proxy, arguments);
            }
        };
    }

}

由动态代理的知识,可以知道代理对象调用方法的时候会经过InvocationHandler的invoke方法

    public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
        String methodName = method.getName();
        Class[] parameterTypes = method.getParameterTypes();
        //....
        return invoker.invoke(new RpcInvocation(method, args)).recreate();
    }

其中委托了invoker进行调用,这个invoker是什么呢? 要弄清楚这个问题,要回顾服务引用中的流程(com.alibaba.dubbo.config.ReferenceConfig#createProxy方法)

    private T createProxy(Map map) {
//....
            if (urls.size() == 1) {
                invoker = refprotocol.refer(interfaceClass, urls.get(0));
            } else {
                //....
                if (registryURL != null) { 
                    URL u = registryURL.addParameter(Constants.CLUSTER_KEY, AvailableCluster.NAME); 
                    invoker = cluster.join(new StaticDirectory(u, invokers));
                }  else { 
                    invoker = cluster.join(new StaticDirectory(invokers));
                }
            }
        }

        // 创建服务代理
        return (T) proxyFactory.getProxy(invoker);
    }

主要是通过refprotocol.refer构造的invoker,从protocol的refer返回的是MockClusterInvoker,其装饰了FailoverClusterInvoker(默认,如果cluster配置了其他,则是其他实现),主要做mock用,忽略。
那么InvokerInvocationHandler中的invoker就是FailoverClusterInvoker,invoke方法会调用到FailoverClusterInvoker的doInvoke方法

    public Result doInvoke(Invocation invocation, final List> invokers, LoadBalance loadbalance) throws RpcException {
        //....从多个invoker中选出一个进行调用
                Result result = invoker.invoke(invocation);
//....
                return result;
    }

这时候的invoker结构如下:


Dubbo源码分析----发起请求_第1张图片
image.png

第二层的invoker是ProtocolFilterWrapper的匿名内部类,其持有一个过滤器,这一层主要一层层调用,然后最后调用到DubboInvoker

public class DubboInvoker extends AbstractInvoker {

    @Override
    protected Result doInvoke(final Invocation invocation) throws Throwable {
        RpcInvocation inv = (RpcInvocation) invocation;
        final String methodName = RpcUtils.getMethodName(invocation);
        inv.setAttachment(Constants.PATH_KEY, getUrl().getPath());
        inv.setAttachment(Constants.VERSION_KEY, version);
        
        ExchangeClient currentClient;
        // 获取连接Client对象,默认为1,可通过connections配置
        if (clients.length == 1) {
            currentClient = clients[0];
        } else {
            currentClient = clients[index.getAndIncrement() % clients.length];
        }
        try {
            // 是否异步
            boolean isAsync = RpcUtils.isAsync(getUrl(), invocation);
            boolean isOneway = RpcUtils.isOneway(getUrl(), invocation);
            int timeout = getUrl().getMethodParameter(methodName, Constants.TIMEOUT_KEY,Constants.DEFAULT_TIMEOUT);
            if (isOneway) {
                boolean isSent = getUrl().getMethodParameter(methodName, Constants.SENT_KEY, false);
                currentClient.send(inv, isSent);
                RpcContext.getContext().setFuture(null);
                return new RpcResult();
            } else if (isAsync) {
                ResponseFuture future = currentClient.request(inv, timeout) ;
                RpcContext.getContext().setFuture(new FutureAdapter(future));
                return new RpcResult();
            } else {
                RpcContext.getContext().setFuture(null);
                return (Result) currentClient.request(inv, timeout).get();
            }
        } catch () {
            //....
        }
    }
}
 
 

根据选择的模式分为3种:

  1. 同步
  2. 异步
  3. 不需要返回值

同步

这种情况下,调用的是Client的request方法,底层是通过channel将请求发送出去

    public ResponseFuture request(Object request, int timeout) throws RemotingException {
        if (closed) {
            throw new RemotingException(this.getLocalAddress(), null, "Failed to send request " + request + ", cause: The channel " + this + " is closed!");
        }
        // create request.
        Request req = new Request();
        req.setVersion("2.0.0");
        req.setTwoWay(true);
        req.setData(request);
        DefaultFuture future = new DefaultFuture(channel, req, timeout);
        try{
            channel.send(req);
        }catch (RemotingException e) {
            future.cancel();
            throw e;
        }
        return future;
    }

由于是同步,而Netty发送是异步的,当时取不到返回结果,所以返回一个Future之后,需要等待结果返回,这时候调用的是get方法等待返回

异步

异步的情况和同步差不多,调用request方法发送请求得到future,返回放到RpcContext中,然后返回一个结果,使用如下:

            Future future = RpcContext.getContext().getFuture();
            result = future.get();

从源码上可以看出,如果同时异步调用了两个服务,那么后者的setFuture会覆盖前者的

不需要返回值

这种情况调用了send方法,底层类似,isSent表示是否等待消息发出

注意:
假设有这种情况,A--异步-->B--同步-->C
那么,A->B这种情况,会走上面异步的流程,因为配置了async属性,所以URL中存在这个属性,而当B->C,这个async属性被附带到B->C的调用附加参数中,导致走了异步的流程,但是其实应该是同步的
出现这种问题的原因如下,先看下A->B的时候,调用的ContextFilter

@Activate(group = Constants.PROVIDER, order = -10000)
public class ContextFilter implements Filter {

    public Result invoke(Invoker invoker, Invocation invocation) throws RpcException {
        Map attachments = invocation.getAttachments();
        if (attachments != null) {
            attachments = new HashMap(attachments);
            attachments.remove(Constants.PATH_KEY);
            attachments.remove(Constants.GROUP_KEY);
            attachments.remove(Constants.VERSION_KEY);
            attachments.remove(Constants.DUBBO_VERSION_KEY);
            attachments.remove(Constants.TOKEN_KEY);
            attachments.remove(Constants.TIMEOUT_KEY);
        }
        RpcContext.getContext()
                .setInvoker(invoker)
                .setInvocation(invocation)
                .setAttachments(attachments)
                .setLocalAddress(invoker.getUrl().getHost(), 
                                 invoker.getUrl().getPort());
        //....
    }
}

这个invocation是A带过来的参数,那么attachments中自然有async=true的属性,而下面,会把attachments放到当前的RpcContext中

当B->C时,调用DubboInvoker方法前调用了AbstractInvoker的invoke方法

    public Result invoke(Invocation inv) throws RpcException {
        //....
        Map context = RpcContext.getContext().getAttachments();
        if (context != null) {
            invocation.addAttachmentsIfAbsent(context);
        }
         
        //....
    }

这里,把context的attachments有设置回了invocation,导致B->C附带了async=true的属性

你可能感兴趣的:(Dubbo源码分析----发起请求)