一張圖看懂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

歡迎關注個人微信公衆號