dubbo源码解析二invoker链

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数量发⽣变化时，z 更新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 是FailoverClusterInvoker的⽗类，invoke使⽤了模版⽅法，每次先获取最新的provider invoker列表，再调⽤⼦类的doInvoke。

继续看FailoverClusterInvoke.invoke
从最新的provider list⾥，使⽤负载均衡算法，获取其中⼀个Invoker，继续invoke⽅法。

经过⼀些列filter，最后执⾏DubboInvoker的invoke。