面試官問我什么是擴(kuò)展自適應(yīng)機(jī)制
掃描二維碼
隨時(shí)隨地手機(jī)看文章
Hola,我是 yes。
這篇繼續(xù)之前提到的 Dubbo SPI 來講講擴(kuò)展點(diǎn)自適應(yīng)機(jī)制(這篇文末會畫個(gè) Dubbo SPI 完整的流程圖,來幫助大家理解)。
這個(gè)名詞聽起來好像很高級,其實(shí)就是一個(gè)擴(kuò)展代理類,通過參數(shù)返回對應(yīng)的擴(kuò)展實(shí)現(xiàn)類。
我寫個(gè)代碼看看應(yīng)該就對擴(kuò)展自適應(yīng)一目了然了。
代碼中的 AdaptiveYes 就是代理類,實(shí)現(xiàn)同樣的接口,然后根據(jù)調(diào)用時(shí)候的參數(shù)去選取對應(yīng)的實(shí)現(xiàn)類進(jìn)行調(diào)用,這就是擴(kuò)展自適應(yīng)。
例如拿到的yesName 是“yesA”則返回YesA這個(gè)實(shí)現(xiàn)類,是“yesB”則返回YesB這個(gè)實(shí)現(xiàn)類
是不是沒什么花頭?就簡單加了一層,可以根據(jù)請求的參數(shù)來動態(tài)選擇對應(yīng)的擴(kuò)展實(shí)現(xiàn)類,讓擴(kuò)展更加靈活。
理解了什么是擴(kuò)展自適應(yīng)之后,我們再來具體看看 Dubbo 中的實(shí)現(xiàn)。
Dubbo 中的 Adaptive 注解
從代碼中可以看到 Adaptive 可以注解到類上或方法上。
注解到類上的話表明這個(gè)類就是要用的代理類,所以 Dubbo 不需要用字節(jié)碼工具為這個(gè)擴(kuò)展生成代理類。
注解在方法上表明 Dubbo 需要為這個(gè)方法生成代理邏輯。
拿上面提到的 AdaptiveYes 類來說,如果這個(gè)類上被標(biāo)注了@Adaptive 那么說明這個(gè)類就是 Yes 這個(gè)擴(kuò)展要用的代理類,框架就不用動態(tài)生成了。
如果 @Adaptive 被標(biāo)記在接口 Yes 的 sayHi 這個(gè)方法上,那 Dubbo 就需要用字節(jié)碼工具來生成 AdaptiveYes 這個(gè)代理類。
在 Dubbo 中,類上被修飾 @Adaptive 只有兩個(gè),分別是AdaptiveCompiler(自適應(yīng)選擇編譯器實(shí)現(xiàn))和
AdaptiveExtensionFactory(自適應(yīng)選擇擴(kuò)展工廠)
還記得之前提到的 Dubbo 自動注入功能的代碼嘛?就是通過 SPI 找到的擴(kuò)展實(shí)現(xiàn)類內(nèi)部需要注入對象的功能。
當(dāng)時(shí)留了個(gè)坑,現(xiàn)在填上。
這行代碼是要通過擴(kuò)展實(shí)現(xiàn)類 set 方法上的參數(shù)找到擴(kuò)展點(diǎn)要注入的對象,而這個(gè) objectFactory 就是自適應(yīng)擴(kuò)展代理類。
Dubbo 中的注入相對 Spring 而言比較復(fù)雜,因?yàn)橛锌赡苄枰⑷氲氖?Dubbo 中其它自適應(yīng)擴(kuò)展對象,也有可能注入的是 Spring Bean,或者是我們自行定義的容器里面的對象等等。
所以依賴注入的對象需要去多處查找,因此加了一層,搞了個(gè)自適應(yīng)代理擴(kuò)展類。
在 Dubbo 中的 ExtensionFactory (擴(kuò)展工廠,從工廠中查找要注入的對象)有三個(gè)實(shí)現(xiàn):
-
SpringExtensionFactory:從 Spring 容器中去加載 Extension
-
SpiExtensionFactory:Dubbo 自己的SPI 去加載 Extension
-
AdaptiveExtensionFactory: 自適應(yīng)的 AdaptiveExtensionLoader,也就是我們上面提到的代理類,由人工編寫的。
ExtensionLoader 中的 objectFactory 用的就是 AdaptiveExtensionFactory 這個(gè)實(shí)現(xiàn)類了,咱們跑起來打個(gè)斷點(diǎn)看看。
嗯,確實(shí)是,還能看到 AdaptiveExtensionFactory 的成員變量 factories 還保存了另外兩個(gè)工廠。
我們來簡單地看下 AdaptiveExtensionFactory 。
這個(gè)工廠會先去加載所有 ExtensionFactory 的擴(kuò)展類,然后查找 Extension 的時(shí)候會遍歷每個(gè) ExtensionFactory 實(shí)現(xiàn)類去找要注入的對象,找到了就返回。
所以 Dubbo 就是通過這種方式來實(shí)現(xiàn) IOC 的注入,很粗暴簡單,每個(gè)工廠遍歷過去查找需要注入的對象。
好了,填了之前文章 Dubbo IOC 的坑,也講了下 @Adaptive 修飾類的情況(就是直接把這個(gè)類作為代理類)。
接下來要講講修飾方法的情況,相對而言比修飾類要復(fù)雜。
不過也不難,無非就是多了幾步,要用字節(jié)碼工具生成代理類的源碼,然后編譯成 Java 字節(jié)碼,然后加載到 JVM 中,就是這樣。
我們來看看源碼,入口就是 getAdaptiveExtension 方法。
那個(gè) cachedApaptiveClass 就是 SPI 掃描對應(yīng)文件夾加載類的時(shí)候記錄的。
結(jié)合上面兩個(gè)代碼圖就知曉為什么類上標(biāo)注 @Adaptive 的時(shí)候直接就用那個(gè)類,不然就需要框架生成代理類了。
我們再來看看框架生成的代碼是怎樣的。
我們看的是 Protocol (協(xié)議接口,Dubbo 支持很多協(xié)議,默認(rèn)dubbo協(xié)議)的自適應(yīng)擴(kuò)展代碼,我們先看下 Protocol 這個(gè)接口的定義,然后再看看生成的代碼。
如何生成上面 code 內(nèi)容的方法我就不分析了,反正就是各種判斷然后字符串拼接而成的,至于編譯之前也提到了,Dubbo 默認(rèn)選的是 javassist。
至此整個(gè)自適應(yīng)邏輯擴(kuò)展已經(jīng)很清晰了,然后上完整 SPI 的圖,相信看了圖之后整個(gè)流程就了然于心了!
Dubbo 中的 Activate
再提一提 @Activate ,這個(gè)就不進(jìn)行源碼分析了,此注解是用來實(shí)現(xiàn)自動激活特性的。
主要的參數(shù)是:
-
group:表明類得在 Provider 端被激活還是在 Consumer 端被激活。
-
value:URL 參數(shù)上出現(xiàn)指定的值被激活。
-
order:擴(kuò)展激活類之間的排序。
簡單地說就是標(biāo)注了這個(gè)注解的擴(kuò)展會被記錄,然后調(diào)用的時(shí)候根據(jù)參數(shù)來選取合適的擴(kuò)展實(shí)現(xiàn)類。
比如參數(shù)的 group 和當(dāng)前擴(kuò)展類的 group 匹配,出現(xiàn)了指定的 key ,然后就會被激活。
對于 Filter 或者一些 Listener 來說比較有用,用來同時(shí)加載多個(gè)實(shí)現(xiàn)類,再看下官網(wǎng)的例子已經(jīng)就比較清楚了。
最后
Dubbo SPI 內(nèi)容算完結(jié)了,源碼分析其實(shí)不適合在公眾號看,所以建議摸魚的時(shí)候偷偷在電腦上打開看。
為了能讓大家更好的理解,我已經(jīng)做了標(biāo)紅的注釋和畫圖了,不知道效果如何。
反正源碼肯定是枯燥的,但是不管是為了深入學(xué)習(xí)還是為了應(yīng)付面試,看源碼這一步是一定要走的。
等 Dubbo 系列寫完之后我再整理成 pdf,基本上看來下對 Dubbo 內(nèi)部還是會有一定的了解的。
免責(zé)聲明:本文內(nèi)容由21ic獲得授權(quán)后發(fā)布,版權(quán)歸原作者所有,本平臺僅提供信息存儲服務(wù)。文章僅代表作者個(gè)人觀點(diǎn),不代表本平臺立場,如有問題,請聯(lián)系我們,謝謝!