Dubbo学习笔记10：Dubbo服务消费方启动流程源码分析

同理我们看下服务消费端启动流程时序图：

在《Dubbo整体架构分析》一文中，我们提到服务消费方需要使用ReferenceConfig API来消费服务，具体是调用代码（1）get()方法来生成远程调用代理类。get()方法最终会调用createProxy方法来具体创建代理类，其中createProxy结合时序图的核心代码如下：

@SuppressWarnings({"unchecked" , "rawtypes" , "deprecation"})
private T createProxy(Map<String , String> map){
    ...
    if(isJvmRefer){
        ...
    }else{
        ...
        // (1) 当只配置一个服务中心的时候
        if(urls.size() == 1){
            invoker = refprotocol.refer(interfaceClass , urls.get(0));
        }else{
            // (2) 多个服务中心的时候
            ...
        }
    }
    ...
    // (3) 创建代理服务
    return (T)proxyFactory.getProxy(invoker);
}

其中refprotocol的定义如下：

private static final Protocol refprotocol = ExtensionLoader.getExtensionLoader(Protocol.class).getAdaptiveExtension();

可知refprotocol是Protocol扩展接口的适配器类，这里调用refprotocol.refer(interfaceClass , urls.get(0));实际调用的是Protocol$Adaptive的refer方法。从Protocol$Adaptive的refer方法内部，我们可以发现当前协议类型为registry，也就是这里需要调用RegistryProtocol的refer方法，但是RegistryProtocol被QosProtocolWrapper / ProtocolFilterWrapper / ProtocolListenerWrapper三个wrapper类增强了。所以这里经过一层层调用后，最后调用到了RegistryProtocol的refer方法，其内部主要是调用了doRefer方法，doRefer代码如下：

private <T> Invoker<T> doRefer(Cluster cluster , Registry registry , Class<T> type , URL url){
    ...
    // (3)
    directory.subscribe(subscribeUrl.addParameter(Constants.CATEGORY_KEY , Constants.PROVIDERS_CATEGORY + "," + Constants.CONFIGURATORS_CATEGORY + "," + Constants.ROUTERS_CATEGORY));
    // (4)
    return cluster.join(directory);
}

如上代码（3）的作用是向服务注册中心订阅服务提供者的服务，代码（4）则是调用扩展接口Cluster的适配器类的join方法，根据参数选择配置的集群容错策略。这里我们先讲讲代码（3）的逻辑，看看如何把服务消费方远程服务转换到Invoker，这里结合Zookeeper作为服务治理中心来讲解，首先看看时序图：

如上时序图步骤（2）（3）（4），从Zookeeper获取服务提供者的地址列表，等Zookeeper返回地址列表后会调用RegistryDirectory的notify方法，代码（6）（7）（8）根据获取的最新的服务提供者url地址转换为具体的invoker列表，也就是每个提供者的url会被转换为一个Invoker对象，具体转换在toInvokers方法中进行：

private Map<String , Invoker<T>> toInvokers(List<URL> urls){
    Map<String , Invoker<T>> newUrlInvokerMap = new HashMap<String , Invoker<T>>();
    ...
    for(URL providerUrl : urls){
        ...
        Map<String , Invoker<T>> localUrlInvokerMap = this.urlInvokerMap;    //
        Invoker<T> invoker = localUrlInvokerMap == null ? null : localUrlInvokerMap.get(key);
        if(invoker == null){
            try{
                ...
                if(enabled){
                    // 这里具体调用dubbo协议转换服务为invoker
                    invoker = new InvokerDelegete<T>(protocol.refer(serviceType , url) , url , providerUrl);
                }
            }catch(Throwable t){

            }
            if(invoker != null){
                newUrlInvokerMap.put(key , invoker);
            }
        }else{
            newUrlInvokerMap.put(key , invoker);
        }
    }
    return newUrlInvokerMap;
}

如上代码，具体转换服务到invoker对象是通过调用protocol.refer(serviceType , url)来完成的，这里的protocol对象也是Protocol扩展接口的适配器对象，所以调用protocol.refer实际是调用Protocol$Adaptive的refer方法。url中协议默认为dubbo，所以适配器里调用的应该是DubboProtocol的refer方法。

前面章节也讲过，Dubbo默认提供了一系列Wrapper类对扩展实现类进行了功能增强，当然这里也不例外，Dubbo使用了ProtocolListenerWrapper / ProtocolFilterWrapper等类对DubboProtocol进行了功能增强。所以这里经过一次次调用后才调用到DubboProtocol的refer方法，DubboProtocol的refer代码内容如下：

public <T> Invoker<T> refer(Class<T> serviceType , URL url) throws RpcException{
    // create rpc invoker.
    DubboInvoker<T> invoker = new DubboInvoker<T>(serviceType , url ,getClients(url) , invokers);
    invokers.add(invoker);
    return invoker;
}

如上代码，首先getClients方法从（12）到（18）创建服务消费端的NettyClient对象用来连接服务提供者。另外可知refer方法内部返回了一个DubboInvoker，这个就是原生的invoker对象，服务方远程服务转换就是为了这个invoker。代码（12）则对这个invoker进行装饰，使用一系列filter形成了责任链，invoker被放到责任链的末尾，下面看看buildInvokerChain如何形成责任链，代码如下：

private static <T> Invoker<T> buildInvokerChain(final Invoker<T> invoker , String key , String group){
    Invoker<T> last = invoker;
    // 获取所有激活的filter，然后使用链表方式形成责任链
    List<Filter> filters = ExtensionLoader.getExtensionLoader(Filter.class).getActivateExtension(invoker.getUrl() , key , group);
    if(filters.size() > 0){
        for(int i=filters.size()-1 ; i>=0 ; i--){
            final Filter filter = filters.get(i);
            final Invoker<T> next = last;
            last = new Invoker<T>(){
                public Class<T> getInterface(){
                    return invoker.getInterface();
                }
                public URL getUrl(){
                    return invoker.getUrl();
                }
                public boolean isAvailable(){
                    return invoker.isAvailable();
                }
                public Result invoke(Invocation invocation) throws RpcException{
                    return filter.invoke(next , invocation);
                }
                public void destroy(){
                    invoker.destroy();
                }
                @Override
                public String toString(){
                    return invoker.toString();
                }
            };
        }
    }
    return last;
}

其中扩展接口Filter对应的实现类，如下所示：

其中MonitorFilter和监控中心进行交互，FutureFilter用来实现异步调用，GenericFilter用来实现泛化调用，ActiveLimitFilter用来控制消费端最大并发调用量，ExecuteLimitFilter用来控制服务提供方最大并发处理量等，当然你可以写自己的filter。由于是责任链，所以ProtocolFilterWrapper的refer返回的是责任链头部的filter到ProtocolListenerWrapper，而ProtocolListenerWrapper的refer方法内容如下：

public <T> Invoker<T> refer(Class<T> type , URL url) throws RpcException{
    ...
    return new ListenerInvokerWrapper<T>(protocol.refer(type,url) , Collections.unmodifiableList(ExtensionLoader.getExtensionLoader(InvokerListener.class).getActivateExtension(url , Constants.INVOKER_LISTENER_KEY)));
}

ProtocolListenerWrapper的refer返回的是ListenerInvokerWrapper对象，所以代码（9）返回的也是url对应的ListenerInvokerWrapper对象，然后再回到时序图代码（8）的toInvokers方法，可知toInvokers返回的是使用InvokerDelegete对ListenerInvokerWrapper包裹的对象。到这里RegistryDirectory里就维护了所有服务者的invoker列表，消费端发送信息时就是根据集群容错和负载均衡算法从invoker列表里选择一个进行调用，当服务提供者挂了的时候，Zookeeper会通知更新这invoker列表。

到这里我们讲完了本节第一个时序图中的步骤（3），下面我们接着讲解步骤（4） 。

默认下步骤（4）会调用FailoverCluster的join方法，FailoverCluster的join方法代码如下：

public class FailoverCluster implements Cluster{
    private static final String NAME = "failover";
    public <T> Invoker<T> join(Directory<T> directory) throws RpcException{
        return new FailoverClusterInvoker<T>(directory);
    }
}

这里把directory对象包裹到了FailoverClusterInvoker，这里需要注意下directory就是上面讲解的RegistryDirectory，其内部维护了所有服务提供者的invoker列表，而FailoverCluster就是集群容错策略。

其实Dubbo对cluster扩展接口实现类使用wrapper类MockClusterWrapper进行增强，这个从下图可以得到证明：

实际上的调用时序图如下图所示：

该时序图中（3）返回了FailbackClusterInvoker对象到（2），下面看看MockClusterWrapper的代码：

public class MockClusterWrapper implements Cluster{
    private Cluster cluster;
    public MockClusterWrapper(Cluster cluster){
        this.cluster = cluster;
    }
    public <T> Invoker<T> join(Directory<T> directory) throws RpcException{
        return new MockClusterInvoker<T>(directory , this.cluster.join(directory));
    }
}

可知MockClusterWrapper类把FailoverClusterInvoker包装成了MockClusterInvoker实例，所以整个调用链最终调用返回的是MockClusterInvoker对象。也就是本文第一个时序图步骤（4）返回的是MockClusterWrapper。然后执行代码（13）获取MockClusterInvoker的代理实现invoker到客户端接口的转换，这里默认调用的是JavassistProxyFactory的getProxy方法，代码如下：

public <T> T getProxy(Invoker<T> invoker , Class<?>[] interfaces){
    return (T)Proxy.getProxy(interfaces).newInstance(new InvokerInvocationHandler(invoker));
}

其中InvokerInvocationHandler为具体拦截器。至此我们按照逆序的方式把服务消费端启动流程讲解完毕，下面在顺过来讲解一次远程调用过程。

Dubbo服务消费端一次调用流程原理分析

同理先上时序图：

由于服务消费端通过ReferenceConfig的get()方法返回的是一个代理类，并且方法拦截器为InvokerInvocationHandler，所以当调用了服务的方法后会被InvokerInvocationHandler拦截，执行如上时序图流程。

如上流程，首先步骤（1）（2）（3）调用了集群容错策略FailoverClusterInvoker，其内部首先根据设置的负载均衡策略选择一个invoker作为FailoverClusterInvoker具体的远程调用者，如果调用发生异常，则根据FailoverClusterInvoker的策略重新选择一个invoker进行调用。

FailoverClusterInvoker内每次调用具体invoker的invoke方法都会走到步骤（8）（9），然后步骤（10）（11）（12）是filter内创建的责任链，最后调用了原生的DubboInvoker，具体使用nettyclient与服务提供者进行交互。