Dubbo服務消費原理
關注可以查看更多粉絲專享blog~
概述
前面已經講過Dubbo服務暴露的原理了（傳送門），今天分析一下Dubbo服務消費原理，相比於服務暴露原理，服務消費就有點像把暴露原理倒過來，可以看一下消費原理圖。跟服務暴露的流程很相似，只是服務暴露的核心類是ServiceConfig，服務消費的核心類是ReferenceConfig，從名字上也可以看出來。
服務暴露流程是ServiceConfig --> ProxyFactory --> Invoker --> Protocol --> Exporter
服務消費流程是ReferenceConfig --> Protocol --> Invoker --> ProxyFactory --> ref
一個是把本地的推倒遠端，一個是把遠端的代理到本地，像本地調用一樣的進行遠程調用，具體是否調用本地或者遠端，對於我們來說是透明的，Dubbo已經幫我們封裝好了。
整體上看，Dubbo框架做服務消費也分爲兩大部分：
- 通過持有遠程對象實例生成Invoker，這個Invoker在客戶端是核心的遠程代理對象。
- 把Invoker通過動態代理轉換成實現用戶接口的動態代理引用。
這裏Invoker承載了網絡連接、服務調用和重試等功能，在客戶端，它可能是一個遠程的實現，也可能是一個集羣的實現。
框架真正進行服務引用的入口點在ReferenceBean#getObject，不管是XML還是註解，都會轉換成ReferenceBean，它繼承自ReferenceConfig。
服務消費過程
- 優先判斷是否處於同一個JVM裏面，默認場景下Dubbo會找出內存中的injvm協議的服務（服務暴露時會註冊一份到injvm，將服務實例放到內存map中）直接獲取實例調用。
- 在註冊中心追加消費者元數據信息，應用啓動時訂閱註冊中心、服務提供者參數等合併時會用到這部分信息。
- 處理只有一個註冊中心的場景，這種場景在客戶端中是最常見的，客戶端啓動拉取服務元數據，訂閱provider、路由和配置變更。
- 處理多註冊中心的場景。逐個獲取註冊中心的服務，並添加到invokers列表中，後面通過Cluster將多個Invoker轉換成一個Invoker。
相關文章：
Davids原理探究：Dubbo源碼編譯（2.7.8）
Davids原理探究：Dubbo SPI和Java SPI實現原理
Davids原理探究：Dubbo註冊中心（ZooKeeper、Redis）實現原理
Davids原理探究：Dubbo配置解析原理
Davids原理探究：Dubbo服務暴露原理
Davids原理探究：Dubbo服務消費原理
Davids原理探究：Dubbo優雅停機原理解析
Davids原理探究：Dubbo調用流程圖
Davids原理探究：Dubbo路由實現原理
Davids原理探究：Dubbo負載均衡實現原理
Davids原理探究：Dubbo過濾器原理