上篇文章说了server端的执行过程，这篇文章将说一下client端的执行过程，一样地还是从nettyclient的启动开始：
1：首先看看nettyclient是什么时候启动的，nettyclient是在spring实例化第一个<dubbo:reference>标签定义的bean,的时候会根据url判断引用的服务端是否有client启动，如果没有的话就会创建client,并随机生成一个client端口与server端进行DUBBO协议(在DUBBO中协议是可配置可扩展但默认使用DUBBO协议)的长连接。下面的图1和图2展示了spring在实例化<dubbo:reference>定义的bean的过程，直到创建client.并且可以从两张图中看出reference bean经过了多个filter的封装包括什么ProtocolFilter等。注意看过上篇文章的朋友可能会注意到在nettyserver创建的时候，创建了两个线程池boss和worker,这里创建nettyclient为什么没有这两组线程池呢？其实是有的，看下面的第三张图可知，这两个线程池在nettyclient类加载的时候就初始化到channelFactory中去了。
2：上面看到了client的创建，以及reference的引用bean创建完成后下面看看真正的调用过程。下图中可以看到，调用会先走到InvokerInvocationHandller,然后经过两个invoker(这两个invoker的作用读者可以自己去dubbo的官方文档中去看，这里就不再讲解了)在FailoverClusterInvoker中，会继续构建filter执行链，下图中也可以看到，invokers中包含的filter包括什么ConsumerContextFilter,FutureFilter等。
3：经过上面的filter和invoker后，最终会走到DubboInvoker,在这里，在DubboInvoker的doInvoker方法里，将会将请求信息交给nettyClient去处理，“主线程”将会在95行一直等待返回结果，直到请求超时或者有返回结果返回。，nettyclient封装请求信息后将会被请求信息交给channel去发送。channel处理发送信息会经过三个handler，见下面的第三张图。这三个handler的作用，在上一篇介绍server端的调用链是讲过，这里就不再讲了。
4：在经过上面的encoder编码后，最后一个handler,nettyhandler会继续将请求消息封装成为一个WriteTask,交给worker线程去发送消息
5：消息发送完成后，worker线程一直轮询channel,等待服务端响应，当收到服务端响应信息后，将响应信息解码后，发送给AllChannel交给业务线程池去处理响应消息(从下图右边的线程栈可以看出)，然后由业务线程DubboClientHandler“唤醒”一直在等待返回结果的future(下图二)。下图三是future在等待返回结果时的超时判断以及doResponse()，并最终会返回到上面“3”中提到的future.get()(下图四)。
6:在DefaulstFuture得到响应消息后，一层一层递返回到最初调用的地方。到这里整个请求+响应的过程就结束了。
