一张图看懂Dubbo服务引用全过程

本文通过图示（dubbo reference创建过程）描述了通过dubbo reference注解创建动态代理invoker的完整过程，不当之处，欢迎指出

• spring @reference注解：服务消费者引用服务配置，如

public class AnnotationConsumeService {

    @com.alibaba.dubbo.config.annotation.Reference
    public AnnotateService annotateService;

    // ...
}  
复制代码

• 通过beanpostprocessor和beanfactorypostprocessor处理注解，可参考之前文章Spring Boot系列之一：如何快速熟悉Spring技术栈，此处使用的是ServiceAnnotationBeanPostProcessor/ReferenceAnnotationBeanPostProcessor

• 核心在ReferenceConfig，组装url参数（url会注册到zookeeper或者dubbo等注册中心，url带有各种属性信息，贯穿处理流程始终），创建动态代理invoker

• 创建invoker动态代理对象时根据是否存在registry注册中心和url个数，决定是创建cluster invoker，还是直接创建对应protocol的代理对象，创建完成后即返回，具体调用时会走loadbalance等机制

• 此过程中大量使用了dubbo的spi机制，也就是动态获取处理类的机制，里面对于wrapper类型（将相同类型的instance做层层wrap，ProtocolListenerWrapper和ProtocolFilterWrapper就是对protocol类型的invoker做了wrap，详见ExtensionLoader处理）、adaptive类型（统一调用接口，可以通过javasist动态生成，进一步根据name获取对应的处理类）做了区分，具体内容请阅读源码或者网上搜索

• 存在多种cluster，默认为failover，cluster本身也是一个invoker，在调用cluster的invoke方法时，cluster会获取对应的directory下的invoker列表，如registryDirectory会从注册中心（如zookeeper）订阅provider信息，然后根据protocol（如dubbo）生成对应的invoker，再通过router做过滤，返回invoker列表

• cluster获取invoker列表后，走loadbalance，有多种loadbalance（如roundrobin、一致性哈希等）

• 调用具体invoker的invoke方法

• 不同协议的invoker（如dubbo）底层会通过netty或者grizzly创建client和对方通信，可以是共享client，也可以one client per connection，invoker将handler暴露给client，client获取消息后经过一系列消息处理然后回调handler

欢迎关注我的微信公众号