3.3 Dubbo服务消费方启动流程剖析
我们看看服务消费方启动流程时序图（如图3.8所示）。
图3.8
在2.2节中，我们提到服务消费方需要使用ReferenceConfig API来消费服务，这里就是执行图3.8中步骤1的get（）方法来生成远程调用代理类。get（）方法首先会执行init（）方法：其中，checkMock（）方法用来检查设置的mock是否正确（有关细节我们在第5章会展开讲解），然后通过调用createProxy（）方法来创建代理类，createProxy（）方法的核心代码如下：
上面的代码比较简单，首先判断是否需要开启本地引用，如果需要则创建JVM协议的本地引用，然后加载服务注册中心信息，服务注册中心可以有多个。
在2.2节我们讲过，服务暴露第一步是调用Protocol扩展接口实现类的refer（）方法以生成Invoker实例，这正是代码4做所的事情，其中refprotocol的定义如下：
从上面的代码可知，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（）方法的代码如下：
代码1根据订阅的URL创建路由规则链，代码2的作用是向服务注册中心订阅服务提供者的服务，代码3则是调用扩展接口Cluster的适配器类的join（）方法，根据参数选择配置的集群容错策略。这里我们先讲讲代码2的逻辑，看看Invoker是如何生成的，这里结合ZooKeeper作为服务注册中心来讲解，首先看看如图3.9所示的时序图。
图3.9
图3.9中的步骤2、步骤3和步骤4用来从ZooKeeper获取服务提供者的地址列表，等ZooKeeper返回地址列表后会调用RegistryDirectory的notify（）方法：
在上面代码的notify（）方法内，对元数据信息进行了分类保存。
图3.9中的步骤6、步骤7和步骤8根据获取的最新的服务提供者URL地址，将其转换为具体的invoker列表，也就是说每个提供者的URL会被转换为一个Invoker对象，具体转换在toInvokers（）方法中进行：
从上面的代码可知，将服务接口转换到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（）方法的代码如下：
从上面的代码可知，getClients（）方法创建服务消费端的NettyClient对象，其调用链的时序图如图3.10所示，其中NettyClient构造函数如下：
在ChannelHandlers.wrap函数内会确定消费端Dubbo内部的线程池模型（关于线程池模型，在后面的章节会做具体讲解）。
NettyClient的父类AbstractClient的构造函数如下：
在上面的代码中，首先调用了NettyClient的doOpen（）方法：
上面的代码创建了一个启动NettyClient的bootstrap并对其进行设置，这里是把编解码器和自定义的nettyClientHandler添加到了链接Channel对应的管线里，在后面的第13章会做具体讲解。
在调用doOpen（）方法后会调用NettyClient的doConnect（）方法与服务提供者建立TCP链接，其中NettyClient的doConnect（）方法的代码如下：
另外需要注意的是，在NettyClient的父类AbstractEndpoint中确定了编解码器，这里默认为DubboCodec：
然后，在doOpen（）方法中，代码NettyCodecAdapter adapter=new NettyCodecAdapter（getCodec（），getUrl（），NettyClient.this）；使用getCodec（）方法获取了该编解码器并封装到NettyCodecAdapter适配器中，然后把编解码器设置到链接Channel的管线中。关于编解码器的使用，后面有专门的章节进行讲解。
这里需要注意三点：第一点，由于同一个服务提供者机器可以提供多个服务，那么消费者机器需要与同一个服务提供者机器提供的多个服务共享连接，还是与每个服务都建立一个连接？第二点，消费端是启动时就与服务提供者机器建立好连接吗？第三点，每个服务消费端与服务提供者集群中的所有机器都有连接吗？对于第三点，我们可以看看图3.9中的toRouters（）方法就可以找到答案，其内部是把具体服务的所有服务提供者的URL信息转换为了Invoker，也就是说服务消费端与服务提供者的所有机器都有连接。
为了回答上面的问题，我们看看getClients（）方法的代码：
通过上面的代码可知，在默认情况下当消费端引用同一个服务提供者机器上多个服务时，这些服务复用一个Netty连接，这里回答了第一个问题。
下面我们从initClient（）方法里看第二个问题的答案：
上面的代码默认lazy为false，所以当消费端启动时就与提供者建立了连接，这里回答了第二个问题。
另外，从DubboProtocol的refer（）方法可知，其内部返回了一个DubboInvoker，这就是原生的invoker对象，服务消费方远程服务转换就是为了这个invoker。图3.9中的步骤17则是对这个invoker进行装饰，即使用一系列Filter形成了责任链，invoker被放到责任链的末尾。下面我们看看ProtocolFilterWrapper的buildInvokerChain（）方法是如何形成责任链的，具体代码如下：
其中，扩展接口Filter对应的实现类如下所示：
其中，MonitorFilter和监控中心进行交互，FutureFilter用来实现异步调用，GenericFilter用来实现泛化调用，ActiveLimitFilter用来控制消费端最大并发调用量，ExecuteLimitFilter用来控制服务提供方最大并发处理量等，当然也可以写自己的Filter。
需要注意的是，消费端启动时并不是把所有的Filter扩展实现都放到责任链中，而是把group=consumer并且value值在URL里的才会放到责任链中，这一点在2.5节中提到过。
由于是责任链，所以ProtocolFilterWrapper的refer（）方法是将责任链头部的Filter返回到ProtocolListenerWrapper。ProtocolListenerWrapper的refer（）方法的代码如下：
至此可知，在图3.10中，在RegistryDirectory里维护了所有服务者的invoker列表，消费端发起远程调用时就是根据集群容错和负载均衡算法以及路由规则从invoker列表里选择一个进行调用的，当服务提供者宕机的时候，ZooKeeper会通知更新这个invoker列表。
图3.10
到这里，我们就讲完了图3.9中directory.subscribe（）方法是如何订阅服务提供者服务的，并且把服务提供者所有的URL信息转换为了invoker列表，并保存到RegistryDirectory里。下面，我们接着讲解图3.9中RegistryProtocol的doRefer（）方法中的cluster.join（directory）是如何使用集群容错扩展将Dubbo协议的invoker客户端转换为需要的接口的。在默认情况下，cluster的扩展接口实现为FailoverCluster，所以这里是调用FailoverCluster的join（）方法，FailoverCluster的join（）方法的代码如下：
这里是把directory对象包裹到了FailoverClusterInvoker里，需要注意的是，directory就是上面讲解的RegistryDirectory，其内部维护了所有服务提供者的invoker列表，而FailoverCluster就是集群容错策略。
其实，Dubbo对cluster扩展接口实现类使用Wrapper类MockClusterWrapper进行增强，这一点从图3.11可以得到证明。
图3.11
实际上调用的时序图如图3.12所示。
图3.12
图3.12中的步骤3将FailbackClusterInvoker对象返回到步骤2，下面看看MockClusterWrapper类的代码：
从上面的代码可知，MockClusterWrapper类把FailoverClusterInvoker包装成了MockClusterInvoker实例，所以整个调用链最终调用返回的是MockClusterInvoker对象。也就是说，本节第一个时序图（见图3.8）中的步骤4返回的是MockClusterWrapper，然后执行图3.9中的步骤14以获取MockClusterInvoker的代理，实现invoker到客户端接口的转换，这里默认调用的是JavassistProxyFactory的getProxy（）方法，其代码如下：
其中，InvokerInvocationHandler为具体拦截器。至此，我们按照逆序的方式把服务消费端启动流程讲解完了，下面一节讲解一次远程调用过程。