Apache Dubbo的SPI機制是如何實現的
一、SPI
1.1 JDK自帶SPI實現
從JDK1.6開始引入SPI機制後,可以看到很多使用SPI的案例,比如最常見的數據庫驅動實現,在JDK中隻定義瞭java.sql.Driver的接口,具體實現由各數據庫廠商來提供。下面一個簡單的例子來快速瞭解下Java SPI的使用方式:
1)定義一個接口
package com.vivo.study public interface Car { void getPrice(); }
2)接口實現
package com.vivo.study.impl /** * 實現一 * */ public class AudiCar implements Car { @Override public void getPrice() { System.out.println("Audi A6L's price is 500000 RMB."); } } package com.vivo.study.impl /** * 實現二 * */ public class BydCar implements Car { @Override public void getPrice() { System.out.println("BYD han's price is 220000 RMB."); } }
3)掛載擴展類信息
在META-INF/services目錄下以接口全名為文件名的文本文件,對應此處即在META-INF/services目錄下創建一個文件名為com.vivo.study.Car的文件,文件內容如下:
com.vivo.study.impl.AudiCar com.vivo.study.impl.BydCar
4)使用
public class SpiDemo { public static void main(String[] args) { ServiceLoader<Car> load = ServiceLoader.load(Car.class); Iterator<Car> iterator = load.iterator(); while (iterator.hasNext()) { Car car = iterator.next(); car.getPrice(); } } }
上面的例子簡單的介紹瞭JDK SPI機制的使用方式,其中最關鍵的類為ServiceLoader,通過ServiceLoader類來加載接口的實現類,ServiceLoader是Iterable接口的實現類,對於ServiceLoader加載的詳細過程此處不展開。
JDK對SPI的加載實現存在一個較為突出的小缺點,無法按需加載實現類,通過ServiceLoader.load加載時會將文件中的所有實現都進行實例化,如果想要獲取具體某個具體的實現類需要進行遍歷判斷。
1.2 Dubbo SPI
SPI擴展是Dubbo的最大的優點之一,支持協議擴展、調用攔截擴展、引用監聽擴展等等。在Dubbo中,根據不同的擴展定位,擴展文件分別被放置在META-INF/dubbo/internal/,META-INF/dubbo/,META-INF/services/這三個路徑下。
Dubbo中有直接使用JDK SPI實現的方式,比如org.apache.dubbo.common.extension.LoadingStrategy放在META-INF/services/路徑下,但大多情況下都是使用其自身對JDK SPI的實現的一種優化方式,可稱為Dubbo SPI,也就是本文要講解的點。
相比於JDK的SPI的實現,Dubbo SPI具有以下特點:
配置形式更靈活:支持以key:value的形式在文件裡配置類似name:xxx.xxx.xxx.xx,後續可以通過name來進行擴展類按需精準獲取。
緩存的使用:使用緩存提升性能,保證一個擴展實現類至多會加載一次。
對擴展類細分擴展:支持擴展點自動包裝(Wrapper)、擴展點自動裝配、擴展點自適應(@Adaptive)、擴展點自動激活(@Activate)。
Dubbo對擴展點的加載主要由ExtensionLoader這個類展開。
二、加載-ExtensionLoader
ExtensionLoader在Dubbo裡的角色類似ServiceLoader在JDK中的存在,用於加載擴展類。在Dubbo源碼裡,隨處都可以見到ExtensionLoader的身影,比如在服務暴露裡的關鍵類ServiceConfig中等,弄清楚ExtensionLoader的實現細節對閱讀Dubbo源碼有很大的幫助。
2.1 獲取ExtensionLoader的實例
ExtensionLoader沒有提供共有的構造函數,
隻能通過ExtensionLoader.getExtensionLoader(Class type)來獲取ExtensionLoader實例。
public // ConcurrentHashMap緩存,key -> Class value -> ExtensionLoader實例 private static final ConcurrentMap<Class<?>, ExtensionLoader<?>> EXTENSION_LOADERS = new ConcurrentHashMap<>(64); private ExtensionLoader(Class<?> type) { this.type = type; objectFactory = (type == ExtensionFactory.class ? null : ExtensionLoader.getExtensionLoader(ExtensionFactory.class).getAdaptiveExtension()); } public static <T> ExtensionLoader<T> getExtensionLoader(Class<T> type) { if (type == null) { throw new IllegalArgumentException("Extension type == null"); } // 檢查是否是接口,如果不是則拋出異常 if (!type.isInterface()) { throw new IllegalArgumentException("Extension type (" + type + ") is not an interface!"); } // 檢查接口是否是被@SPI註解修飾,如果沒有則拋出異常 if (!withExtensionAnnotation(type)) { throw new IllegalArgumentException("Extension type (" + type + ") is not an extension, because it is NOT annotated with @" + SPI.class.getSimpleName() + "!"); } // 從緩存裡取,沒有則初始化一個並放入緩存EXTENSION_LOADERS中 ExtensionLoader<T> loader = (ExtensionLoader<T>) EXTENSION_LOADERS.get(type); if (loader == null) { EXTENSION_LOADERS.putIfAbsent(type, new ExtensionLoader<T>(type)); loader = (ExtensionLoader<T>) EXTENSION_LOADERS.get(type); } return loader; } }
上面的代碼展示瞭獲取ExtensionLoader實例的過程,可以看出,每一個被@SPI修飾的接口都會對應同一個ExtensionLoader實例,且對應ExtensionLoader隻會被初始化一次,並緩存在ConcurresntHashMap中。
2.2 加載擴展類
加載擴展類入口,當使用ExtensionLoader時,getExtensionName、getActivateExtension或是getDefaultExtension都要經過getExtensionClasses方法來加載擴展類,如下圖;
getExtensionClasses方法調用的路徑如下圖,getExtensionClasses是加載擴展類的一個起點,會首先從緩存中獲取,如果緩存中沒有則通過loadExtensionClasses方法來加載擴展類,所以說實際上的加載邏輯入口在loadExtensionClasses。
getExtensionClasses |->loadExtensionClasses |->cacheDefaultExtensionName |->loadDirectory |->loadResource |->loadClass
2.2.1 loadExtensionClasses加載擴展類
由於整個加載過程設計的源碼較多,因此用一個流程圖來進行描述,具體細節可以結合源碼進行查看。
loadExtensionClasses主要做瞭以下這幾件事:
默認擴展名:
抽取默認擴展實現名並緩存在ExtensionLoader裡的cachedDefaultName,默認擴展名配置通過@SPI註解在接口上配置,如配置@SPI(“defaultName”)則默認擴展名為defaultName。
加載擴展類信息:
從META-INF/dubbo/internal/,META-INF/dubbo/,META-INF/services/這三個路徑下尋找以類的全路徑名命名的文件,並逐行讀取文件裡的內容。
加載class並緩存:
對擴展類分為自適應擴展實現類(被@Adaptive修飾的實現類)、包裝類(擁有一個隻有一個為這個接口類型的參數的構造方法)、普通擴展類,其中普通擴展類中又包含自動激活擴展類(被@Activate修飾的類)和真普通的類,對自適應擴展實現類、包裝類、自動激活擴展類這三種類型的類分別加載並分別緩存到cachedAdaptiveClass、cachedActivates、cachedWrapperClasses。
返回結果Map<String, Class<?>>:
結果返回Map,其中key對應擴展文件裡配置的name,value對應擴展的類class,最後在getExtensionClasses方法裡會將此結果放入緩存cachedClasses中。此結果Map中包含除瞭自適應擴展實現類和包裝實現類的其他所用的擴展類名與對應類的映射關系。
通過loadExtensionClasses方法把擴展類(Class對象)都加載到相應的緩存中,是為瞭方便後面實例化擴展類對象,通過newInstance()等方法來實例化。
2.2.2擴展包裝類
什麼是擴展包裝類?是不是類名結尾包含瞭Wrapper的類就是擴展包裝類?
在Dubbo SPI接口的實現擴展類中,如果此類包含一個此接口作為參數的構造方法,則為擴展包裝類。擴展包裝類的作用是持有具體的擴展實現類,可以一層一層的被包裝,作用類似AOP。
包裝擴展類的作用是類似AOP,方便擴展增強。具體實現代碼如下:
從代碼中可以得出,可以通過boolean wrap選擇是否使用包裝類,默認情況下為true;如果有擴展包裝類,實際的實現類會被包裝類按一定的順序一層一層包起來。
如Protocol的實現類ProtocolFilterWrapper、ProtocolListenerWrapper都是擴展包裝類。
2.2.3自適應擴展實現類
2.2.3.1 @Adaptive
@Documented @Retention(RetentionPolicy.RUNTIME) @Target({ElementType.TYPE, ElementType.METHOD}) public @interface Adaptive { String[] value() default {}; }
從源碼以及源碼註釋中可以得出以下幾點:
Adaptive是一個註解,可以修飾類(接口,枚舉)和方法。
此註解的作用是為ExtensionLoader註入擴展實例提供有用的信息。
從註釋中理解value的作用:
value可以決定選擇使用具體的擴展類。
通過value配置的值key,在修飾的方法的入參org.apache.dubbo.common.URL中通過key獲取到對應的值value,根據value作為extensionName去決定使用對應的擴展類。
如果通過2沒有找到對應的擴展,會選擇默認的擴展類,通過@SPI配置默認擴展類。
2.2.3.2 @Adaptive簡單例子
由於@Adaptive修飾類時比較好理解,這裡舉一個@Adaptive修飾方法的例子,使用@Adaptive修飾方法的這種情況在Dubbo也是隨處可見。
/** * Dubbo SPI 接口 */ @SPI("impl1") public interface SimpleExt { @Adaptive({"key1", "key2"}) String yell(URL url, String s); }
如果調用
ExtensionLoader.getExtensionLoader(SimpleExt.class).getAdaptiveExtension().yell(url, s)方法,最終調用哪一個擴展類的實例去執行yell方法的流程大致為:先獲取擴展類的名稱extName(對應上面說的name:class中的name),然後通過extName來獲取對應的類Class,再實例化進行調用。所以關鍵的步驟在怎麼得到extName,上面的這個例子得到extName的流程為:
通過url.getParameters.get(“key1”)獲取,
沒有獲取到則用url.getParameters.get(“key2”),如果還是沒有獲取到則使用impl1對應的實現類,最後還是沒有獲取到則拋異常IllegalStateException。
可以看出,@Adaptive的好處就是可以通過方法入參決定具體調用哪一個實現類。下面會對@Adaptive的具體實現進行詳細分析。
2.2.3.3 @Adaptive加載流程
流程關鍵點說明:
1)黃色標記的,cachedAdaptiveClass是在ExtensionLoader#loadClass方法中加載Extension類時緩存的。
2)綠色標記的,如果Extension類中存在被@Adaptive修飾的類時會使用該類來初始化實例。
3)紅色標記的,如果Extension類中不存在被@Adaptive修飾的類時,則需要動態生成代碼,通過javassist(默認)來編譯生成Xxxx$Adaptive類來實例化。
4)實例化後通過injectExtension來將Adaptive實例的Extension註入(屬性註入)。
後續圍繞上述的關鍵點3詳細展開,關鍵點4此處不展開。
動態生成Xxx$Adaptive類:下面的代碼為動態生成Adaptive類的相關代碼,具體生成代碼的細節在AdaptiveClassCodeGenerator#generate中
public class ExtensionLoader<T> { // ... private Class<?> getAdaptiveExtensionClass() { // 根據對應的SPI文件加載擴展類並緩存,細節此處不展開 getExtensionClasses(); // 如果存在被@Adaptive修飾的類則直接返回此類 if (cachedAdaptiveClass != null) { return cachedAdaptiveClass; } // 動態生成Xxxx$Adaptive類 return cachedAdaptiveClass = createAdaptiveExtensionClass(); } private Class<?> createAdaptiveExtensionClass() { // 生成Xxxx$Adaptive類代碼,可自行加日志或斷點查看生成的代碼 String code = new AdaptiveClassCodeGenerator(type, cachedDefaultName).generate(); ClassLoader classLoader = findClassLoader(); // 獲取動態編譯器,默認為javassist org.apache.dubbo.common.compiler.Compiler compiler = ExtensionLoader.getExtensionLoader(org.apache.dubbo.common.compiler.Compiler.class).getAdaptiveExtension(); return compiler.compile(code, classLoader); } }
AdaptiveClassCodeGenerator#generate生成code的方式是通過字符串拼接,大量使用String.format,整個代碼過程比較繁瑣,可通過debug去瞭解細節。
最關鍵的的部分是生成被@Adaptive修飾的方法的內容,也就是最終調用實例的@Adaptive方法時,可通過參數來動態選擇具體使用哪個擴展實例。下面對此部分進行分析:
public class AdaptiveClassCodeGenerator { // ... /** * generate method content */ private String generateMethodContent(Method method) { // 獲取方法上的@Adaptive註解 Adaptive adaptiveAnnotation = method.getAnnotation(Adaptive.class); StringBuilder code = new StringBuilder(512); if (adaptiveAnnotation == null) { // 方法時沒有@Adaptive註解,生成不支持的代碼 return generateUnsupported(method); } else { // 方法參數裡URL是第幾個參數,不存在則為-1 int urlTypeIndex = getUrlTypeIndex(method); // found parameter in URL type if (urlTypeIndex != -1) { // Null Point check code.append(generateUrlNullCheck(urlTypeIndex)); } else { // did not find parameter in URL type code.append(generateUrlAssignmentIndirectly(method)); } // 獲取方法上@Adaptive配置的value // 比如 @Adaptive({"key1","key2"}),則會返回String數組{"key1","key2"} // 如果@Adaptive沒有配置value,則會根據簡寫接口名按駝峰用.分割,比如SimpleExt對應simple.ext String[] value = getMethodAdaptiveValue(adaptiveAnnotation); // 參數裡是否存在org.apache.dubbo.rpc.Invocation boolean hasInvocation = hasInvocationArgument(method); code.append(generateInvocationArgumentNullCheck(method)); // 生成String extName = xxx;的代碼 ,extName用於獲取具體的Extension實例 code.append(generateExtNameAssignment(value, hasInvocation)); // check extName == null? code.append(generateExtNameNullCheck(value)); code.append(generateExtensionAssignment()); // return statement code.append(generateReturnAndInvocation(method)); } return code.toString(); } }
上述生成Adaptive類的方法內容中最關鍵的步驟在生成extName的部分,也就是generateExtNameAssignment(value,hasInvocation),此方法if太多瞭(有點眼花繚亂)。
以下列舉幾個例子對此方法的實現流程進行簡單展示:假設方法中的參數不包含org.apache.dubbo.rpc.Invocation,包含org.apache.dubbo.rpc.Invocation的情況會更加復雜。
1)方法被@Adaptive修飾,沒有配置value,且在接口@SPI上配置瞭默認的實現
@SPI("impl1") public interface SimpleExt { @Adaptive String echo(URL url, String s); }
對應生成extName的代碼為:
String extName = url.getParameter("simple.ext", "impl1")
2)方法被@Adaptive修飾,沒有配置value,且在接口@SPI上沒有配置默認的實現
@SPI("impl1") public interface SimpleExt { @Adaptive({"key1", "key2"}) String yell(URL url, String s); }
對應生成extName的代碼為:
String extName = url.getParameter( "simple.ext")
3)方法被@Adaptive修飾,配置瞭value(假設兩個,依次類推),且在接口@SPI上配置瞭默認的實現
@SPI public interface SimpleExt { @Adaptive({"key1", "key2"}) String yell(URL url, String s); }
對應生成extName的代碼為:
String extName = url.getParameter("key1", url.getParameter("key2", "impl1"));
4)方法被@Adaptive修飾,配置瞭value(假設兩個,依次類推),且在接口@SPI沒有配置默認的實現
@SPI public interface SimpleExt { @Adaptive({"key1", "key2"}) String yell(URL url, String s); }
對應生成extName的代碼為:
String extName = url.getParameter("key1", url.getParameter("key2"));
完整的生成類可參見附錄。
2.2.4自動激活擴展類
如果你有擴展實現過Dubbo的Filter,那麼一定會對@Activate很熟悉。@Activate註解的作用是可以通過給定的條件來自動激活擴展實現類,通過ExtensionLoader#getActivateExtension(URL,String, String)方法可以找到指定條件下需要激活的擴展類列表。
下面以一個例子來對@Activate的作用進行說明,在Consumer調用Dubbo接口時,會經過消費方的過濾器鏈以及提供方的過濾器鏈,在Provider暴露服務的過程中會拼接需要使用哪些Filter。
對應源碼中的位置在ProtocolFilterWrapper#buildInvokerChain(invoker, key, group)方法中。
// export:key-> service.filter ; group-> provider private static <T> Invoker<T> buildInvokerChain(final Invoker<T> invoker, String key, String group) { // 在Provider暴露服務服務export時,會根據獲取Url中的service.filter對應的值和group=provider來獲取激活對應的Filter List<Filter> filters = ExtensionLoader.getExtensionLoader(Filter.class).getActivateExtension(invoker.getUrl(), key, group); }
ExtensionLoader#getActivateExtension(URL, String, String)是怎麼根據條件來自動激活對應的擴展類列表的可以自行查看該方法的代碼,此處不展開。
三、總結
本文主要對Dubbo SPI機制的擴展類加載過程通過ExtensionLoader類源碼來進行總結,可以概況為以下幾點:
1.Dubbo SPI結合瞭JDK SPI的實現,並在此基礎上進行優化,如精準按需加載擴展類、緩存提升性能。
2.分析ExtensionLoader加載擴展類的過程,加載META-INF/dubbo/internal/,META-INF/dubbo/,META-INF/services/這三個路徑下的文件,並分類緩存在ExtensionLoader實例。
3.介紹擴展包裝類及其實現過程,擴展包裝類實現瞭類似AOP的功能。
4.自適應擴展類,分析@Adptive修飾方法時動態生成Xxx$Adaptive類的過程,以及通過參數自適應選擇擴展實現類完成方法調用的案例介紹。
簡單介紹自動激活擴展類及@Activate的作用。
四、附錄
4.1 Xxx$Adaptive完整案例
@SPI接口定義
@SPI("impl1") public interface SimpleExt { // @Adaptive example, do not specify a explicit key. @Adaptive String echo(URL url, String s); @Adaptive({"key1", "key2"}) String yell(URL url, String s); // no @Adaptive String bang(URL url, int i); }
生成的Adaptive類代碼
package org.apache.dubbo.common.extension.ext1; import org.apache.dubbo.common.extension.ExtensionLoader; public class SimpleExt$Adaptive implements org.apache.dubbo.common.extension.ext1.SimpleExt { public java.lang.String yell(org.apache.dubbo.common.URL arg0, java.lang.String arg1) { if (arg0 == null) throw new IllegalArgumentException("url == null"); org.apache.dubbo.common.URL url = arg0; String extName = url.getParameter("key1", url.getParameter("key2", "impl1")); if (extName == null) throw new IllegalStateException("Failed to get extension (org.apache.dubbo.common.extension.ext1.SimpleExt) name from url (" + url.toString() + ") use keys([key1, key2])"); org.apache.dubbo.common.extension.ext1.SimpleExt extension = (org.apache.dubbo.common.extension.ext1.SimpleExt)ExtensionLoader.getExtensionLoader(org.apache.dubbo.common.extension.ext1.SimpleExt.class).getExtension(extName); return extension.yell(arg0, arg1); } public java.lang.String echo(org.apache.dubbo.common.URL arg0, java.lang.String arg1) { if (arg0 == null) throw new IllegalArgumentException("url == null"); org.apache.dubbo.common.URL url = arg0; String extName = url.getParameter("simple.ext", "impl1"); if (extName == null) throw new IllegalStateException("Failed to get extension (org.apache.dubbo.common.extension.ext1.SimpleExt) name from url (" + url.toString() + ") use keys([simple.ext])"); org.apache.dubbo.common.extension.ext1.SimpleExt extension = (org.apache.dubbo.common.extension.ext1.SimpleExt) ExtensionLoader.getExtensionLoader(org.apache.dubbo.common.extension.ext1.SimpleExt.class).getExtension(extName); return extension.echo(arg0, arg1); } public java.lang.String bang(org.apache.dubbo.common.URL arg0, int arg1) { throw new UnsupportedOperationException("The method public abstract java.lang.String org.apache.dubbo.common.extension.ext1.SimpleExt.bang(org.apache.dubbo.common.URL,int) of interface org.apache.dubbo.common.extension.ext1.SimpleExt is not adaptive method!"); } }
以上就是Apache Dubbo的SPI機制是如何實現的的詳細內容,更多關於Apache Dubbo的SPI機制的資料請關註WalkonNet其它相關文章!
推薦閱讀:
- 詳解SPI在Dubbo中的應用
- java spi最全使用總結
- 淺析Java SPI 與 dubbo SPI
- Java Spring Dubbo三種SPI機制的區別
- 快速學會Dubbo的配置環境及相關配置