面試官問(wèn)我什么是擴(kuò)展自適應(yīng)機(jī)制

這個(gè)名詞聽(tīng)起來(lái)好像很高級(jí)，其實(shí)就是一個(gè)擴(kuò)展代理類(lèi)，通過(guò)參數(shù)返回對(duì)應(yīng)的擴(kuò)展實(shí)現(xiàn)類(lèi)。

我寫(xiě)個(gè)代碼看看應(yīng)該就對(duì)擴(kuò)展自適應(yīng)一目了然了。

代碼中的 AdaptiveYes 就是代理類(lèi)，實(shí)現(xiàn)同樣的接口，然后根據(jù)調(diào)用時(shí)候的參數(shù)去選取對(duì)應(yīng)的實(shí)現(xiàn)類(lèi)進(jìn)行調(diào)用，這就是擴(kuò)展自適應(yīng)。

例如拿到的yesName 是“yesA”則返回YesA這個(gè)實(shí)現(xiàn)類(lèi)，是“yesB”則返回YesB這個(gè)實(shí)現(xiàn)類(lèi)

是不是沒(méi)什么花頭？就簡(jiǎn)單加了一層，可以根據(jù)請(qǐng)求的參數(shù)來(lái)動(dòng)態(tài)選擇對(duì)應(yīng)的擴(kuò)展實(shí)現(xiàn)類(lèi)，讓擴(kuò)展更加靈活。

理解了什么是擴(kuò)展自適應(yīng)之后，我們?cè)賮?lái)具體看看 Dubbo 中的實(shí)現(xiàn)。

Dubbo 中的 Adaptive 注解

從代碼中可以看到 Adaptive 可以注解到類(lèi)上或方法上。

注解到類(lèi)上的話表明這個(gè)類(lèi)就是要用的代理類(lèi)，所以 Dubbo 不需要用字節(jié)碼工具為這個(gè)擴(kuò)展生成代理類(lèi)。

注解在方法上表明 Dubbo 需要為這個(gè)方法生成代理邏輯。

拿上面提到的 AdaptiveYes 類(lèi)來(lái)說(shuō)，如果這個(gè)類(lèi)上被標(biāo)注了@Adaptive 那么說(shuō)明這個(gè)類(lèi)就是 Yes 這個(gè)擴(kuò)展要用的代理類(lèi)，框架就不用動(dòng)態(tài)生成了。

如果 @Adaptive 被標(biāo)記在接口 Yes 的 sayHi 這個(gè)方法上，那 Dubbo 就需要用字節(jié)碼工具來(lái)生成 AdaptiveYes 這個(gè)代理類(lèi)。

在 Dubbo 中，類(lèi)上被修飾 @Adaptive 只有兩個(gè)，分別是AdaptiveCompiler(自適應(yīng)選擇編譯器實(shí)現(xiàn))和 AdaptiveExtensionFactory(自適應(yīng)選擇擴(kuò)展工廠)

還記得之前提到的 Dubbo 自動(dòng)注入功能的代碼嘛？就是通過(guò) SPI 找到的擴(kuò)展實(shí)現(xiàn)類(lèi)內(nèi)部需要注入對(duì)象的功能。

當(dāng)時(shí)留了個(gè)坑，現(xiàn)在填上。

這行代碼是要通過(guò)擴(kuò)展實(shí)現(xiàn)類(lèi) set 方法上的參數(shù)找到擴(kuò)展點(diǎn)要注入的對(duì)象，而這個(gè) objectFactory 就是自適應(yīng)擴(kuò)展代理類(lèi)。

Dubbo 中的注入相對(duì) Spring 而言比較復(fù)雜，因?yàn)橛锌赡苄枰⑷氲氖?Dubbo 中其它自適應(yīng)擴(kuò)展對(duì)象，也有可能注入的是 Spring Bean，或者是我們自行定義的容器里面的對(duì)象等等。

所以依賴(lài)注入的對(duì)象需要去多處查找，因此加了一層，搞了個(gè)自適應(yīng)代理擴(kuò)展類(lèi)。

在 Dubbo 中的 ExtensionFactory (擴(kuò)展工廠，從工廠中查找要注入的對(duì)象)有三個(gè)實(shí)現(xiàn)：

• SpringExtensionFactory：從 Spring 容器中去加載 Extension
• SpiExtensionFactory：Dubbo 自己的SPI 去加載 Extension
• AdaptiveExtensionFactory: 自適應(yīng)的 AdaptiveExtensionLoader，也就是我們上面提到的代理類(lèi)，由人工編寫(xiě)的。

ExtensionLoader 中的 objectFactory 用的就是 AdaptiveExtensionFactory 這個(gè)實(shí)現(xiàn)類(lèi)了，咱們跑起來(lái)打個(gè)斷點(diǎn)看看。

嗯，確實(shí)是，還能看到 AdaptiveExtensionFactory 的成員變量 factories 還保存了另外兩個(gè)工廠。

我們來(lái)簡(jiǎn)單地看下 AdaptiveExtensionFactory 。

這個(gè)工廠會(huì)先去加載所有 ExtensionFactory 的擴(kuò)展類(lèi)，然后查找 Extension 的時(shí)候會(huì)遍歷每個(gè) ExtensionFactory 實(shí)現(xiàn)類(lèi)去找要注入的對(duì)象，找到了就返回。

所以 Dubbo 就是通過(guò)這種方式來(lái)實(shí)現(xiàn) IOC 的注入，很粗暴簡(jiǎn)單，每個(gè)工廠遍歷過(guò)去查找需要注入的對(duì)象。

好了，填了之前文章 Dubbo IOC 的坑，也講了下 @Adaptive 修飾類(lèi)的情況（就是直接把這個(gè)類(lèi)作為代理類(lèi)）。

接下來(lái)要講講修飾方法的情況，相對(duì)而言比修飾類(lèi)要復(fù)雜。

不過(guò)也不難，無(wú)非就是多了幾步，要用字節(jié)碼工具生成代理類(lèi)的源碼，然后編譯成 Java 字節(jié)碼，然后加載到 JVM 中，就是這樣。

我們來(lái)看看源碼，入口就是 getAdaptiveExtension 方法。

那個(gè) cachedApaptiveClass 就是 SPI 掃描對(duì)應(yīng)文件夾加載類(lèi)的時(shí)候記錄的。

結(jié)合上面兩個(gè)代碼圖就知曉為什么類(lèi)上標(biāo)注 @Adaptive 的時(shí)候直接就用那個(gè)類(lèi)，不然就需要框架生成代理類(lèi)了。

我們?cè)賮?lái)看看框架生成的代碼是怎樣的。

我們看的是 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)行源碼分析了，此注解是用來(lái)實(shí)現(xiàn)自動(dòng)激活特性的。

主要的參數(shù)是：

• group：表明類(lèi)得在 Provider 端被激活還是在 Consumer 端被激活。
• value：URL 參數(shù)上出現(xiàn)指定的值被激活。
• order：擴(kuò)展激活類(lèi)之間的排序。

簡(jiǎn)單地說(shuō)就是標(biāo)注了這個(gè)注解的擴(kuò)展會(huì)被記錄，然后調(diào)用的時(shí)候根據(jù)參數(shù)來(lái)選取合適的擴(kuò)展實(shí)現(xiàn)類(lèi)。

比如參數(shù)的 group 和當(dāng)前擴(kuò)展類(lèi)的 group 匹配，出現(xiàn)了指定的 key ，然后就會(huì)被激活。

對(duì)于 Filter 或者一些 Listener 來(lái)說(shuō)比較有用，用來(lái)同時(shí)加載多個(gè)實(shí)現(xiàn)類(lèi)，再看下官網(wǎng)的例子已經(jīng)就比較清楚了。