dubbo源碼分析8（服務消費者之生成代理對象）

　　前面幾篇博客，說了很多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遠程調用的邏輯

　　下一篇我們看看是怎麼進行遠程調用，怎麼拿到介面調用的返回值