Dubbo源碼分析----發起請求

從如下代碼中還是分析

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

我們知道demoService實際上是一個代理對象，那麼假設使用的是JDK的代碼，看看獲取代理的地方

public class JdkProxyFactory extends AbstractProxyFactory {

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

    public <T> Invoker<T> getInvoker(T proxy, Class<T> type, URL url) {
        return new AbstractProxyInvoker<T>(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<String, String> 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<Invoker<T>> invokers, LoadBalance loadbalance) throws RpcException {
        //....從多個invoker中選出一個進行調用
                Result result = invoker.invoke(invocation);
//....
                return result;
    }

這時候的invoker結構如下：

第二層的invoker是ProtocolFilterWrapper的匿名內部類，其持有一個過濾器，這一層主要一層層調用，然後最後調用到DubboInvoker

public class DubboInvoker<T> extends AbstractInvoker<T> {

    @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<Object>(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<Result> 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<String, String> attachments = invocation.getAttachments();
        if (attachments != null) {
            attachments = new HashMap<String, String>(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<String, String> context = RpcContext.getContext().getAttachments();
        if (context != null) {
            invocation.addAttachmentsIfAbsent(context);
        }

        //....
    }

這裏，把context的attachments有設置回了invocation，導致B->C附帶了async=true的屬性

Dubbo源碼分析----發起請求

Dubbo源碼分析----處理請求

Dubbo源碼分析----發起請求

Netty源碼分析----PoolChunk

RocketMQ源碼分析----HA相關(1)

Netty源碼分析----PoolChunkList

Mac下配置sublime實現LaTeX

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結