一张图看懂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

欢迎关注个人微信公众号