dubbo源码解析二 invoker链

　　在上一篇中，调用远程服务的路径是业务接口代理proxy->MockClusterInvoker.invoke->invoker父类AbstractClusterInvoker.invoke->FailoverClusterInvoke.invoke。

AbstractClusterInvoker.invoke代码

List<Invoker<T>> invokers = list(invocation); 从zk获取最新的invoker列表

directory（开发文档）可以看做是 Invoker 集合，且这个集合中的元素会随注册中心的变化而进行动态调整。服务导入的时候，消费者向注册中心注册服务后订阅相应接口，传入回调listener参数，当该接口对应的zk临时文件数量即provider数量发生变化时，zk服务器通知comsumer传入参数List<Url> list回调listener，listener

更新provider list。和上篇RegistryProtocol一样，根据传入的url的protocol通过自适应代码生成Protocol代理类调用refer生成invoker，封装成provider list。

protocol封装如下：Protocol$Adpative->QosProtocolWrapper->ProtocolListenerWrapper->ProtocolFilterWrapper->DubboProtocol
refer传递调用时，和registy略有不一样，在ProtocolListenerWrapper的refer处，if分支区分两种invoker生成方式。

 

这块代码不再深入，大致是先new DubboInvoker，然后在之上封装动态获取的filter链，继续封装成ListenerInvokerWrapper后返回。

directory本身实现listener接口，可以随时更新实例的invoker list。详见dubbo
AbstractClusterInvoker 是FailoverClusterInvoker的父类，invoke使用了模版方法，每次先获取最新的provider invoker列表，再调用子类的doInvoke。
继续看FailoverClusterInvoke.invoke 

 

从最新的provider list里，使用负载均衡算法，获取其中一个Invoker，继续invoke方法。

经过一些列filter，最后执行DubboInvoker的invoke。

转载于:https://www.cnblogs.com/wxbty/p/10357607.html