dubbo源碼分析-服務(wù)暴露流程

如下圖：

doExportUrlsFor1Protocol(…)這個(gè)函數可以理解為通過(guò)具體協(xié)議進(jìn)行服務(wù)暴露。
(4)最終調用的是InjvmProtocol的export(), 然后構建了一個(gè)InjvmExporter對象作為本地暴露對象，然后將構建的對象存入AbstractProtocol的exporterMap中，與此同時(shí)，構建的InjvmExporter中也持有一份exporterMap的引用。
我們知道服務(wù)暴露的核心組件是ServiceBean，我們也知道ServiceBean是在基于spring可擴展的XMLschema實(shí)例化來(lái)的，也就是說(shuō)在spring容器啟動(dòng)的過(guò)程當中就完成了服務(wù)的暴露，接下來(lái)我們著(zhù)重分析這個(gè)類(lèi)就可以了。
很明顯，如果我們不配置動(dòng)態(tài)代理方式，那么缺省是javassist。

具體執行export的是ProtocolListenerWrapper，我們先看下執行的過(guò)程（接下來(lái)是一片連續代碼截圖~）

ServiceConfig#export()，這個(gè)方法首先會(huì )根據用戶(hù)配置判斷是否暴露，以及是否延遲暴露，不關(guān)注這塊邏輯的話(huà)，最關(guān)鍵的部分是調用doExport()這個(gè)方法。如圖：

從這個(gè)函數我們其實(shí)是可以看出dubbo默認支持dubbo協(xié)議，換個(gè)角度講，讀者如果看過(guò)官方文檔的話(huà)，不難了解到dubbo是支持多協(xié)議的并且默認（缺?。﹨f(xié)議是dubbo，官方截圖如下：

8. proxyFactory.getInvoker(ref, (Class) interfaceClass, local)這段邏輯是具體服務(wù)轉換為Invoker的過(guò)程，這個(gè)過(guò)程中用到了ProxyFactory這個(gè)概念，ProxyFactory的作用在開(kāi)篇也講過(guò)了，proxyFactory是根據spi動(dòng)態(tài)獲取到的，具體表現為一個(gè)動(dòng)態(tài)代理類(lèi)，如圖：

從這個(gè)函數的邏輯不難發(fā)現這塊邏輯的功能與我們探討doExport()函數時(shí)引申出的dubbo是支持多協(xié)議注冊想呼應。簡(jiǎn)言之，上圖的邏輯實(shí)現了多協(xié)議注冊，是多協(xié)議支持的根本。

至此，已經(jīng)一口氣完成了本地暴露，我結合代碼大概的說(shuō)一下暴露過(guò)程中需要注意的點(diǎn)：
9. 得到Invoker之后，接下來(lái)我們該馬不停蹄的進(jìn)行轉換Exporter的過(guò)程了。protocol.export(Invoker），

我們可以猜想AbstractInterfaceConfig#loadRegistries()這個(gè)函數會(huì )將用戶(hù)配置的協(xié)議轉換為內部的URL對象（dubbo統一數據模型）加載到一個(gè)list當中。斷點(diǎn)進(jìn)入loadRegistries()這個(gè)方法去驗證下我們的想法~ 如圖：
服務(wù)暴露時(shí)序圖