一張圖看懂Dubbo服務引用全過程

Dubbo reference建立過程

本文透過圖示（dubbo reference建立過程）描述了透過dubbo reference註解建立動態代理invoker的完整過程，不當之處，歡迎指出

• spring @reference註解：服務消費者引用服務配置，如

public class AnnotationConsumeService {    @com.alibaba.dubbo.config.annotation.Reference    public AnnotateService annotateService;    // ...}

• 透過beanpostprocessor和beanfactorypostprocessor機制處理註解，可參考之前文章，此處使用的是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

作者：68號小喇叭
連結：