前面幾篇博客，說了很多dubbo服務提供者相關的流程；
復習一下：首先服務提供者去暴露服務介面資料到注冊中心，然后本地啟動netty服務端監聽是否有消費者的請求，現在我們可以看看消費者端是怎么從注冊中心獲取指定的介面資訊， 然后訪問netty服務端，就行了；
提前須知：要提前了解spring的ioc容器初始化的程序以及呼叫ioc容器的getBean的邏輯，這個不是我們的重點
1 準備作業
我們先大概看看服務消費者大概做了些什么事情，打開消費者端的demo，下圖所示，首先是初始化spring的ioc容器，然后從容器中獲取實體bean， 然后呼叫該bean的方法
結合我們知道的spring的知識，我們就大膽的猜測一下，在spring的ioc初始化的程序中，會決議我們配置在xml檔案中<dubbo:reference id="xxx" interface="xxx"/>，決議出來的物件放在ioc容器中，下圖所示，很明顯當前服務的BeanDefinition中封裝的是ReferenceBean物件，ReferenceBean封裝了該服務的資訊；
這里消費者端初始化ioc容器的時候，和服務提供者一樣，都是在DubboBootstrap的start方法開始發車，這個start方法里面會呼叫exportServices()方法暴露服務和referServices()參考服務，因為一個服務既可以是服務提供者，同時也可以是服務消費者，這個不難理解吧！比如A->B->C, B服務對A來說是服務提供者， 對C來說是服務消費者
然后就是spring的邏輯了，在從ioc獲取物件(也就是呼叫getBean方法)的時候，會判斷這個物件ReferenceBean有沒有實作FactoryBean介面，有的話，就呼叫FactoryBean的getObject方法
剛好我們去看看ReferenceBean類，巧了(￣o￣) . z Z，剛好實作了FactoryBean介面，于是就會呼叫下圖的getObject()方法
總結一下，服務消費者就干了三件事：
（1）啟動ioc容器進行初始化，初始化程序中對dubbo的組態檔進行決議
(2）從ioc容器獲取bean的時候，呼叫getBean方法的時候，會判斷當前的Bean是否實作了FactoryBean介面，有的話，就呼叫getObject方法生成代理物件，并放入ioc容器中
（3）呼叫代理物件的方法，這個方法內部封裝了遠程呼叫的細節，回傳呼叫結果；
2.生成代理物件
這里默認大家都對spring的ioc容器的啟動已經很熟悉了，就不再過多的描述，我們就看看是怎么生成代理物件的；
我們就從ReferenceBean的getObject方法開始出發，連續截圖三張，我們可以看到呼叫了父類的ReferenceConfig的get()方法， 再之后就是呼叫init()方法進行初始化操作
這個init方法很長， 我們等下看看呼叫createProxy(xxx)方法的邏輯
2.1 創建代理物件
這個init方法百分之九十的代碼都是設定引數到map里面，然后再根據這個map創建代理物件
下面都是createProxy方法內部比較重要的部分，總結一下其實就是干了幾件事，首先就是判斷參考的服務是本地注冊還是遠程注冊， 如果是遠程注冊就繼續判斷有幾個注冊中心，如果只有一個注冊中心的話，就去那個注冊中心獲取服務資料轉為一個invoker就好了；
如果是多個注冊中心，就將每個注冊中心中的該服務資訊多轉為invoker, 再用cluster將多個invoker合并成一個統一的invoker;
最終就是呼叫代理工廠proxyFactory將invoker生成代理物件；
最終的根據代理工廠將invoker生成代理物件
現在基本流程我們知道了，首先看看是否有多個注冊中心，因為一個服務可以同時注冊到多個注冊中心，這里會從多個注冊中心中獲取相同名字的服務， 然后再將這些服務合并成一個invoker，然后就是根據最后生成的invoker生成代理類
接下來我們繼續看看REF_PROTOCOL.refer(xxx)生成invoker的邏輯，還有FROXY_FACTORY.getProxy(invoker)生成代理類，理解了這兩個邏輯，就ok了；
2.2 REF_PROTOCOL.refer(xxx)生成invoker
由于現在只有一個注冊中心，我們從這里進入開始看看怎么生成invoker的邏輯
首先獲取到注冊中心實體，根據我們的消費者端的資訊，去注冊中心里創建consumer節點，然后接下來就是訂閱providers、configurators、routers 等節點資料，只要是這幾個節點有資料變化，就會通知到消費者端
其實到這里就已經很清晰了， 不過在上圖的第3步，就是用一個介面可能是集群部署的嘛，然后都注冊到同一個注冊中心中，我們需要將獲取到的這個介面的多個服務提供者，然后又給聚合成一個invoker（其實這里的directory比較形象，中文意思是目錄，這個目錄下可能有多個服務提供者的呀）
3.FROXY_FACTORY.getProxy(invoker)生成代理物件
在上面我們已經從所有注冊中心獲取了所有實作了該介面的服務，最后合并成了一個invoker，然后就是根據這個invoker生成代理物件
在getProxy()方法里面，其實就是判斷當前服務介面是不是一個泛化介面（可以去了解一下dubbo的泛化，就是另外一種呼叫介面的方式而已，可以不提供服務介面），如果是的話，就做特殊處理，否則就把代理物件直接回傳
這里很明顯就是直接回傳代理物件
當代理物件生成出來了之后，后續的就跟dubbo沒啥關系了， 就是spring的內容，將生成的代理物件放到ioc容器中，并該介面的全名稱對應起來，只要是下次我們再去獲取這個實體的時候，就直接從ioc容器中獲取了
下圖所示，可以看到是一個代理物件
可以看到最終的ioc容器中已經有個這個代理物件了
4.總結
服務消費者的邏輯會比較多，現在首先會根據你要呼叫的這個介面，去多個注冊中心看看，而且每個注冊中心相同的一個服務A還有可能有多個，我們最終就多個服務A給拼接成一個invoker
然后我們再使用代理工廠將這個invoker生成一個代理物件，并且和該服務介面名稱對應起來放到spring的ioc容器中，下次再去獲取這個介面的服務的時候，就能獲取到這個代理物件了，這個代理物件中肯定是封裝了netty遠程呼叫的邏輯
下一篇我們看看是怎么進行遠程呼叫，怎么拿到介面呼叫的回傳值
--------------以上皆原創，給未來的自己留下一點學習的痕跡!--------轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/455512.html
標籤：其他
下一篇：scrapy框架爬蟲