Dubbo服務(wù)發(fā)現(xiàn)、引用過程
本文轉(zhuǎn)載自微信公眾號「大魚仙人」，作者大魚仙人。轉(zhuǎn)載本文請聯(lián)系大魚仙人公眾號。
一.前言
前面兩篇分別介紹了Dubbo的入門和Dubbo的服務(wù)暴露
- Dubbo起飛
- 面試官問我：解釋一下Dubbo服務(wù)暴露
這篇我們要說的服務(wù)引用，服務(wù)引用是有兩種情況的，也可以看做是兩種時機，第一個是在Spring容器調(diào)用ReferenceBean的afterPropertiesSet方法時引用服務(wù)，第二個就是在ReferenceBean對應(yīng)的服務(wù)被注入到其他類中時引用。這兩個引用服務(wù)的時機區(qū)別在于，第一個是餓漢式的，第二個是懶漢式的
是不是一說餓漢和懶漢，大家順便回憶了一波單例模式
默認(rèn)情況下，Dubbo使用懶漢式引用服務(wù)。如果需要使用餓漢式，可通過配置
服務(wù)引入的三種方式：
第一種是引用本地 (JVM) 服務(wù)，上篇在服務(wù)暴露里面也說過了每個服務(wù)都會通過走injvm協(xié)議然后走本地的暴露，因為存在一個服務(wù)端和消費端是同一臺機器上的情況，這樣就直接走本地調(diào)用了，不需要走遠(yuǎn)程調(diào)用了，節(jié)省網(wǎng)絡(luò)開銷
第二是通過直連方式引用遠(yuǎn)程服務(wù)，這種在線上基本不會采用這種形式的，一般都是平時我們自己測試用，直接寫死服務(wù)端的地址來調(diào)用
第三是通過注冊中心引用遠(yuǎn)程服務(wù)，Consumer 通過注冊中心得知 Provider 的相關(guān)信息，然后進行服務(wù)的引入
不管是哪種引用方式，最后都會得到一個 Invoker 實例。如果有多個注冊中心，多個服務(wù)提供者，這個時候會得到一組 Invoker 實例，此時需要通過集群管理類 Cluster 將多個 Invoker 合并成一個實例。合并后的 Invoker 實例已經(jīng)具備調(diào)用本地或遠(yuǎn)程服務(wù)的能力了
但是呢，開發(fā)者秉承不對用戶業(yè)務(wù)代碼侵入的原則，所以此時框架還需要通過代理工廠類ProxyFactory為服務(wù)接口生成代理類，并讓代理類去調(diào)用Invoker邏輯，避免了Dubbo框架代碼對業(yè)務(wù)代碼的侵入
二.服務(wù)發(fā)現(xiàn)
dubbo的服務(wù)發(fā)現(xiàn)，就是通過從注冊中心訂閱服務(wù)提供者，并且組裝成URL，然后通過URL創(chuàng)建出invoker來實現(xiàn)的
服務(wù)的引入和服務(wù)的暴露一樣，也是通過 spring 自定義標(biāo)簽機制解析生成對應(yīng)的 Bean，Provider Service 對應(yīng)解析的是 ServiceBean 而 Consumer Reference 對應(yīng)的是 ReferenceBean
dubbo 的服務(wù)發(fā)現(xiàn)，是通過從注冊中心訂閱服務(wù)提供者組裝成 URL，然后通過 URL 創(chuàng)建出 Invoker 來實現(xiàn)的。
這里是入口，進去看ReferenceBean
createLazyProxy中我們會看到DubboReferenceLazyInitTargetSource這一目標(biāo)資源，點進來new的地方，里面的protected的方法createObject調(diào)用了getCallProxy，而這個方法最終調(diào)用的是referenceConfig.get()
點進來，我們進入的是ReferenceConfig類的方法，而非ReferenceBean的，這是因為ReferenceConfig是作為ReferenceBean的內(nèi)部的屬性出現(xiàn)的
Init()方法內(nèi)部主要就是通過Map設(shè)置各種參數(shù)，我們看init其中的一個方法叫做createProxy，我們根據(jù)名字也可以知道大概意思就是創(chuàng)建代理對象，點進去看看
如果是走本地的話，那么直接構(gòu)建個本地協(xié)議的 URL 然后進行服務(wù)的引入，即 refprotocol.refer，這個方法之后會做分析，本地的引入就不深入了，就是去之前服務(wù)暴露的 exporterMap 拿到服務(wù)
如果不是本地，那肯定是遠(yuǎn)程了，接下來就是判斷是點對點直連 provider 還是通過注冊中心拿到 provider 信息再連接 provider 了，我們分析一下配置了 url 的情況，如果配置了 url 那么不是直連的地址，就是注冊中心的地址
這其實就是整個流程了，簡述一下就是先檢查配置，通過配置構(gòu)建一個 map ，然后利用 map 來構(gòu)建 URL ，再通過 URL 上的協(xié)議利用自適應(yīng)擴展機制調(diào)用對應(yīng)的 protocol.refer 得到相應(yīng)的 invoker
我給大家總結(jié)個流程圖，這樣大家看著更加清晰
三.服務(wù)引用
Dubbo 的服務(wù)引用，實際上是為引用的接口創(chuàng)建一個 Proxy，這個 Proxy 的功能就是去執(zhí)行 refprotocol.refer(interfaceClass, url) 創(chuàng)建出來的 Invoker。當(dāng)服務(wù)提供者有多個時，就創(chuàng)建一個 ClusterInvoker。
Cluster 是一個 SPI 擴展點，默認(rèn)使用com.alibaba.dubbo.rpc.cluster.support.FailoverCluster
所以，Consumer 端服務(wù)調(diào)用的邏輯被封裝在 refprotocol.refer(interfaceClass, url) 創(chuàng)建出來的 Invoker 上
主要就是獲取注冊中心實例，然后調(diào)用 doRefer 進行真正的 refer。
這里會向注冊中心注冊自身的信息，生成一個Invoker，底層生成用于遠(yuǎn)程調(diào)用的invoker，然后通過cluster包裝一下再得到ClusterInvoker，因此一個服務(wù)可能有多個提供者，然后最后注冊相應(yīng)的監(jiān)聽器
拿到了Provider的信息之后就可以通過監(jiān)聽觸發(fā) Protocol# refer 了，具體調(diào)用哪個 protocol 還是得看 URL的協(xié)議的，我們看下這個內(nèi)部DubboProtocol的refer
而這個connect最終返回 HeaderExchangeClient里面封裝的是 NettyClient，然后最終得到的invoker就是對這個client的封裝，最終將返回一個Proxy的代理對象
四.回顧
其實整個流程看代碼啥的，一開始可能會遇到很多新名詞，但是細(xì)細(xì)一想其實不難，靜下心來好好分析，就都很簡單了
其實就是通過各種配置參數(shù)和協(xié)議組裝成相應(yīng)的URL，然后通過自動適配去對相應(yīng)的實現(xiàn)類進行相應(yīng)的服務(wù)的引入和后續(xù)的調(diào)用
如果是寫死的地址就直接連接，是注冊中心就向注冊中心注冊信息，然后訂閱注冊中心的相關(guān)信息，得到服務(wù)提供者的IP端口號等信息，通過netty進行連接，底層會通過directory和cluster進行底層多個服務(wù)的屏蔽和負(fù)載均衡的處理，得到代理對象Invoker，再通過動態(tài)代理封裝得到代理類，總之就是不侵入業(yè)務(wù)代碼，能用代理解決的就用代理
不侵入代碼的最好辦法就是加代理，遇事不決加層代理
