Dubbo擴展源泉之SPI機制
作者：飄渺Jam
SPI是一種擴展機制，核心就是將服務(wù)配置化，在核心代碼不用改動的前提下，通過加載配置文件中的服務(wù)，然后根據(jù)傳遞的參數(shù)來決定到底走什么邏輯，走哪個服務(wù)的邏輯。這樣就對擴展是開放的，對修改是關(guān)閉的。
1、什么是SPI
1.1、SPI簡介
SPI ，全稱為 Service Provider Interface，是一種服務(wù)發(fā)現(xiàn)機制。它通過在ClassPath路徑下的META-INF/services文件夾查找文件，自動加載文件里所定義的類。 這一機制為很多框架擴展提供了可能，比如在Dubbo、JDBC中都使用到了SPI機制。我們先通過一個很簡單的例子來看下它是怎么用的。
簡單來說，SPI是一種擴展機制，核心就是將服務(wù)配置化，在核心代碼不用改動的前提下，通過加載配置文件中的服務(wù)，然后根據(jù)傳遞的參數(shù)來決定到底走什么邏輯，走哪個服務(wù)的邏輯。這樣就對擴展是開放的，對修改是關(guān)閉的。
1.2、SPI的運用場景
當(dāng)你在寫核心代碼的時候，如果某個點有涉及到會根據(jù)參數(shù)的不同走不同的邏輯的時候，如果沒有SPI，你可能會在代碼里面寫大量的if else代碼，這樣代碼就非常不靈活，假設(shè)有一天又新增了一種邏輯，代碼里面也要跟著改，這個就違背了開閉原則，SPI的出現(xiàn)就是解決這種擴展問題的，你可以把實現(xiàn)類全部都配置到配置文件中，然后在核心代碼里面就只要加載配置文件，然后根據(jù)入?yún)⒏虞d的這些類進行匹配，如果匹配的就走該邏輯，這樣如果有一天新增了邏輯，核心代碼是不用變的，唯一變的就是自己工程里面的配置文件和新增類，符合了開閉原則。
2、JDK中的SPI機制
前面已經(jīng)介紹過SPI是什么以及在哪些地方用了，在這里就重點介紹一下SPI在JDK中的實現(xiàn)，下面我們看看具體的
2.1、案例
2.1.1、頂層接口
public interface KLog {
boolean support(String type);
void debug();
void info();
}2.1.2、接口實現(xiàn)
public classLog4jimplementsKLog {
@Override
publicbooleansupport(String type) {
return"log4j".equalsIgnoreCase(type);
}
@Override
publicvoiddebug() {
System.out.println("====log4j.debug======");
}
@Override
publicvoidinfo() {
System.out.println("====log4j.info======");
}
}
publicclassLogbackimplementsKLog {
@Override
publicbooleansupport(String type) {
return"Logback".equalsIgnoreCase(type);
}
@Override
publicvoiddebug() {
System.out.println("====Logback.debug======");
}
@Override
publicvoidinfo() {
System.out.println("====Logback.info======");
}
}
publicclassSlf4jimplementsKLog {
@Override
publicbooleansupport(String type) {
return"Slf4j".equalsIgnoreCase(type);
}
@Override
publicvoiddebug() {
System.out.println("====Slf4j.debug======");
}
@Override
publicvoidinfo() {
System.out.println("====Slf4j.info======");
}
}2.1.3、文件配置
在resources/META-INF/services目錄創(chuàng)建文件，文件名稱必須跟接口的完整限定名相同。如圖
圖片
這個接口文件中配置了該接口的所有實現(xiàn)類的完整限定名，如圖：
圖片
現(xiàn)在要根據(jù)輸入的參數(shù)來決定到底是走Log4j的邏輯還是Logback的邏輯。
2.1.4、單元測試
public classMyTest {
//不同的入?yún)ⅲ瑢?yīng)調(diào)用的邏輯是不一樣的
publicstaticvoidmain(String[] args) {
//這個是我們業(yè)務(wù)的核心代碼，核心代碼會根據(jù)外部的參數(shù)決定要掉哪一個實例
//可以去讀配置文件 properties配置，去決定掉哪個實例
//jdk api 加載配置文件配置實例
ServiceLoader<KLog> all = ServiceLoader.load(KLog.class);
Iterator<KLog> iterator = all.iterator();
Scannerscanner=newScanner(System.in);
Strings= scanner.nextLine();
while (iterator.hasNext()) {
GLognext= iterator.next();
//這個實例是不是我們需要掉的
// 策略模式 當(dāng)前實例是不是跟入?yún)⑵ヅ? if(next.support(s)) {
next.debug();
}
}
}
}2.2、總結(jié)
我們可以把這個單元測試代碼看成是自己業(yè)務(wù)中的核心代碼，這個代碼是不需要改動的，擴展新增的只是接口對應(yīng)的實現(xiàn)類而已，然后在核心代碼中我們只要根據(jù)傳入的參數(shù)去調(diào)用不同的邏輯就可以了，這個就是SPI擴展的魅力，核心代碼不需要改動。
從上面的測試代碼我們還了解一個點，JDK中的SPI也是獲取類實例的一種方式，然后配合策略模式就可以根據(jù)參數(shù)選擇實例調(diào)用了。
3、dubbo中的SPI機制
dubbo中的spi機制大體上的流程跟jdk中的spi類似的，但是也有很多細節(jié)方面不一樣，下面我們就重點看看dubbo中的spi機制。
3.1、案例
3.1.1、頂層接口
//這個是必須的
@SPI("spring")
public interface ActivateApi {
@Adaptive
String todo(String param, URL url);
}3.1.2、接口實現(xiàn)
@Adaptive
publicclassDubboActivateimplementsActivateApi {
@Override
public String todo(String param, URL url) {
return param;
}
}
publicclassMybatisActivateimplementsActivateApi {
private ActivateApi activateApi;
@Override
public String todo(String param, URL url) {
return param;
}
publicvoidsetActivateApi(ActivateApi activateApi) {
this.activateApi = activateApi;
System.out.println(activateApi);
}
}
publicclassRabbitmq1ActivateimplementsActivateApi {
@Override
public String todo(String param, URL url) {
return param;
}
}
publicclassRabbitmq2ActivateimplementsActivateApi {
@Override
public String todo(String param, URL url) {
return param;
}
}
publicclassRabbitmqActivateimplementsActivateApi {
@Override
public String todo(String param, URL url) {
return param;
}
}
publicclassSpringActivateimplementsActivateApi {
@Override
public String todo(String param, URL url) {
return param;
}
}
publicclassSpringCloudActivateimplementsActivateApi {
@Override
public String todo(String param, URL url) {
return param;
}
}3.1.3、文件配置
在resources/META-INF/dubbo下面配置接口文件，文件名稱必須跟接口完整限定名相同，如圖：
圖片
接口文件中配置的內(nèi)容就是該接口的實現(xiàn)類的完整限定名，跟jdk中配置不一樣的地方就是，dubbo中可以帶key，這個key就是該實現(xiàn)類的映射key，可以根據(jù)這個key獲取到該key對應(yīng)的類實例。如圖：
圖片
3.1.4、單元測試
@Test
public void adaptive() {
ActivateApi adaptiveExtension =
ExtensionLoader.getExtensionLoader(ActivateApi.class).getAdaptiveExtension();
System.out.println(adaptiveExtension.getClass());
}下面我們來介紹一下dubbo中幾個非常重要的SPI的API。
3.2、getAdaptiveExtension()
3.2.1、方法功能
該方法是獲取到一個接口的實現(xiàn)類，獲取的方式有：
1、獲取類上有@Adaptive注解的類的實例2、如果接口的所有實現(xiàn)類都沒有@Adaptive注解則dubbo動態(tài)生成一個
3.2.2、方法用法
//需要獲取什么接口的實現(xiàn)類，getExtensionLoader中就傳該接口的類型
ActivateApi adaptiveExtension =
ExtensionLoader.getExtensionLoader(ActivateApi.class).getAdaptiveExtension();3.2.3、源碼分析
3.2.3.1、ExtensionLoader
public static <T> ExtensionLoader<T> getExtensionLoader(Class<T> type) {
if (type == null) {
thrownewIllegalArgumentException("Extension type == null");
}
if (!type.isInterface()) {
thrownewIllegalArgumentException("Extension type (" + type + ") is not an interface!");
}
//如果接口上沒有@SPI注解，則報錯
if (!withExtensionAnnotation(type)) {
thrownewIllegalArgumentException("Extension type (" + type +
") is not an extension, because it is NOT annotated with @" +
SPI.class.getSimpleName() + "!");
}
//從緩存中獲取
ExtensionLoader<T> loader = (ExtensionLoader<T>) EXTENSION_LOADERS.get(type);
if (loader == null) {
//每一個@SPI接口類型都會對應(yīng)一個ExtensionLoader對象
//這里需要知道，一個接口類型對應(yīng)著一個ExtensionLoader對象
EXTENSION_LOADERS.putIfAbsent(type, newExtensionLoader<T>(type));
loader = (ExtensionLoader<T>) EXTENSION_LOADERS.get(type);
}
return loader;
}3.2.3.2、getAdaptiveExtension
核心思想就是先從緩存中拿實例，如果沒有才調(diào)用createAdaptiveExtension();方法創(chuàng)建實例。創(chuàng)建完成后放入到緩存中。緩存就是在ExtensionLoader中的一個Holder對象，如：Holder cachedAdaptiveInstance = new Holder<>();
public T getAdaptiveExtension() {
//先從緩存中拿實例
Objectinstance= cachedAdaptiveInstance.get();
//DCL 思想
if (instance == null) {
if (createAdaptiveInstanceError != null) {
thrownewIllegalStateException("Failed to create adaptive instance: " +
createAdaptiveInstanceError.toString(),
createAdaptiveInstanceError);
}
synchronized (cachedAdaptiveInstance) {
instance = cachedAdaptiveInstance.get();
if (instance == null) {
try {
//創(chuàng)建接口實例的核心方法
instance = createAdaptiveExtension();
cachedAdaptiveInstance.set(instance);
} catch (Throwable t) {
createAdaptiveInstanceError = t;
thrownewIllegalStateException("Failed to create adaptive instance: " +
t.toString(), t);
}
}
}
}
return (T) instance;
}3.2.3.3、createAdaptiveExtension
該方法就是創(chuàng)建實例的方法，創(chuàng)建實例并對實例進行IOC屬性的依賴注入。
private T createAdaptiveExtension() {
try {
//injectExtension 是dubbo中的ioc邏輯，對屬性進行賦值操作
return injectExtension((T) getAdaptiveExtensionClass().newInstance());
} catch (Exception e) {
throw new IllegalStateException("Can't create adaptive extension " + type + ",
cause: " + e.getMessage(), e);
}
}3.2.3.4、getAdaptiveExtensionClass
獲取到要實例化的類的Class對象并返回
private Class<?> getAdaptiveExtensionClass() {
//核心方法 ，重點看 。建立名稱和類的映射關(guān)系
getExtensionClasses();
//如果有@Adaptive注解的類，則返回該類
if (cachedAdaptiveClass != null) {
return cachedAdaptiveClass;
}
//動態(tài)拼湊類，動態(tài)編譯生成
return cachedAdaptiveClass = createAdaptiveExtensionClass();
}3.2.3.5、getExtensionClasses
該方法是一個非常核心的方法，dubbo spi中的很多API都需要先調(diào)用這個方法來建立key和class的映射關(guān)系。獲取映射關(guān)系的流程也是先從緩存里面拿，如果緩存沒有才讀配置文件建立映射關(guān)系，并把映射關(guān)系緩存起來。
該方法的作用：
建立key和class的映射關(guān)系2、給ExtensionLoader里面的很多全局變量賦值，這些全局變量在dubbo spi的api中有用到
private Map<String, Class<?>> getExtensionClasses() {
//先從緩存拿
Map<String, Class<?>> classes = cachedClasses.get();
//DCL
if (classes == null) {
synchronized (cachedClasses) {
classes = cachedClasses.get();
if (classes == null) {
//從本地文件中加載key和類的關(guān)系
classes = loadExtensionClasses();
//把加載到的映射關(guān)系緩存起來
cachedClasses.set(classes);
}
}
}
return classes;
}3.2.3.6、loadExtensionClasses
該方法就是讀取resources/META-INF/dubbo、META-INF/dubbo/internal/下面的配置文件，然后解析配置文件，建立key和class的映射關(guān)系，給ExtensionLoader里面的全局變量賦值等功能。
private Map<String, Class<?>> loadExtensionClasses() {
//獲取默認的實現(xiàn)類名稱并緩存起來
cacheDefaultExtensionName();
Map<String, Class<?>> extensionClasses = new HashMap<>();
//從jdk的spi機制中獲取LoadingStrategy 實例
for (LoadingStrategy strategy : strategies) {
//加載目錄下的文件，建立名稱和類的映射關(guān)系 。核心邏輯
loadDirectory(extensionClasses, strategy.directory(), type.getName(),
strategy.preferExtensionClassLoader(), strategy.overridden(), strategy.excludedPackages());
loadDirectory(extensionClasses, strategy.directory(),
type.getName().replace("org.apache", "com.alibaba"), strategy.preferExtensionClassLoader(),
strategy.overridden(), strategy.excludedPackages());
}
return extensionClasses;
}3.2.3.6.1、cacheDefaultExtensionName
設(shè)置ExtensionLoader中的全局變量cachedDefaultName的值，全局變量值的來源就是接口中@SPI("spring")注解的value值。
private voidcacheDefaultExtensionName() {
//獲取類上的@SPI注解
finalSPIdefaultAnnotation= type.getAnnotation(SPI.class);
if (defaultAnnotation == null) {
return;
}
Stringvalue= defaultAnnotation.value();
//如果@SPI注解中有value值
if ((value = value.trim()).length() > 0) {
String[] names = NAME_SEPARATOR.split(value);
if (names.length > 1) {
thrownewIllegalStateException("More than 1 default extension name on extension
" + type.getName()
+ ": " + Arrays.toString(names));
}
//把value值設(shè)置到 cachedDefaultName，，這個就是默認的實現(xiàn)類
if (names.length == 1) {
cachedDefaultName = names[0];
}
}
}3.2.3.6.2、loadDirectory
加載目錄下的所有文件，建立名稱和類的映射關(guān)系 ，設(shè)置全局變量的值。循環(huán)調(diào)用loadResource
while (urls.hasMoreElements()) {
java.net.URL resourceURL = urls.nextElement();
//加載接口對應(yīng)的文件的核心方法
loadResource(extensionClasses, classLoader, resourceURL, overridden, excludedPackages);
}3.2.3.6.3、loadResource
該方法就是對每一個文件進行處理的，建立名稱和類的映射關(guān)系 ，設(shè)置全局變量的值。對讀到的文件中的每一行數(shù)據(jù)進行處理。
private voidloadResource(Map<String, Class<?>> extensionClasses, ClassLoader classLoader,
java.net.URL resourceURL, boolean overridden, String... excludedPackages) {
try {
try (BufferedReaderreader=newBufferedReader(new
InputStreamReader(resourceURL.openStream(), StandardCharsets.UTF_8))) {
String line;
Stringclazz=null;
//讀一行數(shù)據(jù)
while ((line = reader.readLine()) != null) {
finalintci= line.indexOf('#');
//如果一行數(shù)據(jù)中有#號，則只要#前面那部分,,后面那部分可以寫注釋
if (ci >= 0) {
line = line.substring(0, ci);
}
line = line.trim();
if (line.length() > 0) {
try {
Stringname=null;
//=分割
inti= line.indexOf('=');
if (i > 0) {
//=號前面那部分是key
name = line.substring(0, i).trim();
//=號后面那部分則是類
clazz = line.substring(i + 1).trim();
} else {
clazz = line;
}
if (StringUtils.isNotEmpty(clazz) && !isExcluded(clazz, excludedPackages)) {
//加載類的核心邏輯
loadClass(extensionClasses, resourceURL, Class.forName(clazz, true, classLoader), name, overridden);
}
} catch (Throwable t) {
IllegalStateExceptione=newIllegalStateException("Failed to load
extension class (interface: " + type + ", class line: " + line + ") in " + resourceURL + ",
cause: " + t.getMessage(), t);
exceptions.put(line, e);
}
}
}
}
} catch (Throwable t) {
logger.error("Exception occurred when loading extension class (interface: " +
type + ", class file: " + resourceURL + ") in " + resourceURL, t);
}
}3.2.3.6.4、loadClass
該方法核心就是走了三套邏輯：
- 如果類上有@Adaptive注解2、如果類是包裝類3、沒有@Adaptive注解又不是包裝類
private voidloadClass(Map<String, Class<?>> extensionClasses, java.net.URL resourceURL,
Class<?> clazz, String name, boolean overridden)throws NoSuchMethodException {
//如果類類型和接口類型不一致，報錯
if (!type.isAssignableFrom(clazz)) {
thrownewIllegalStateException("Error occurred when loading extension class
(interface: " +
type + ", class line: " + clazz.getName() + "), class "
+ clazz.getName() + " is not subtype of interface.");
}
//如果類上面有@Adaptive注解
if (clazz.isAnnotationPresent(Adaptive.class)) {
//在這個方法里面 對 cachedAdaptiveClass變量賦值
cacheAdaptiveClass(clazz, overridden);
} elseif (isWrapperClass(clazz)) {
//如果是包裝類，包裝類必然是持有目標接口的引用的，有目標接口對應(yīng)的構(gòu)造函數(shù)
//對 cachedWrapperClasses 變量賦值
cacheWrapperClass(clazz);
} else {
//獲取類的無參構(gòu)造函數(shù)，如果是包裝類，這里會報錯,,其實這里包裝類走不進來了，包裝類先處理的
clazz.getConstructor();
//如果沒有配置key
if (StringUtils.isEmpty(name)) {
//如果類有Extension注解，則是注解的value
//如果沒注解則是類名稱的小寫做為name
name = findAnnotationName(clazz);
if (name.length() == 0) {
thrownewIllegalStateException("No such extension name for the class " +
clazz.getName() + " in the config " + resourceURL);
}
}
String[] names = NAME_SEPARATOR.split(name);
if (ArrayUtils.isNotEmpty(names)) {
//如果類上面有@Activate注解，則建立名稱和注解的映射
//對 cachedActivates 全局變量賦值
cacheActivateClass(clazz, names[0]);
for (String n : names) {
cacheName(clazz, n);
//這里 extensionClasses 建立了 key和class的映射
saveInExtensionClass(extensionClasses, clazz, n, overridden);
}
}
}
}3.2.3.7、createAdaptiveExtensionClass
前面分析類建立映射關(guān)系的過程，如果cachedAdaptiveClass屬性不為空，也就是有@Adaptive注解的類，則直接返回該類，如果該屬性為空，則會走到createAdaptiveExtensionClass方法，該方法的核心作用：
- 自動根據(jù)接口中的注解和參數(shù)配置生成類的字符串2、根據(jù)類的字符串動態(tài)編譯生成字節(jié)碼文件加載到j(luò)vm
接口定義的規(guī)則
- 接口中的方法必須要有一個方法有@Adaptive注解，要不然會報錯2、方法的參數(shù)中必須要有URL參數(shù)，要不然會報錯
為什么要這樣設(shè)計
因為這種方式dubbo會自動生成一個類，這個類其實就是一個代理類，但是dubbo并不知道應(yīng)該都哪個邏輯，也就是這個代理類并不知道走該接口的哪個實現(xiàn)類，所以我們必須用代理對象掉方法的時候用方法的入?yún)⒏嬖Vdubbo應(yīng)該走哪個實現(xiàn)類，而選擇掉哪個實現(xiàn)類的參數(shù)就在URL參數(shù)中。所以參數(shù)中必須要有URL參數(shù)，如下是dubbo生成的代理類：
import org.apache.dubbo.common.extension.ExtensionLoader;
publicclassActivateApi$Adaptiveimplementscn.enjoy.dubbospi.ActivateApi {
public java.lang.String todo(java.lang.String arg0, org.apache.dubbo.common.URL arg1) {
if (arg1 == null) thrownewIllegalArgumentException("url == null");
org.apache.dubbo.common.URLurl= arg1;
StringextName= url.getParameter("activate.api", "spring");
if(extName == null) thrownewIllegalStateException("Failed to get extension
(cn.enjoy.dubbospi.ActivateApi) name from url (" + url.toString() + ") use
keys([activate.api])");
cn.enjoy.dubbospi.ActivateApiextension=
(cn.enjoy.dubbospi.ActivateApi)ExtensionLoader.getExtensionLoader(cn.enjoy.dubbospi.Activate
Api.class).getExtension(extName);
return extension.todo(arg0, arg1);
}
}從代碼中可以看出，是根據(jù)url入?yún)磉x擇接口的某個實例，然后用該實例去掉方法，也就是ActivateApi$Adaptive這種類只是一個代理層，并沒有實質(zhì)性的業(yè)務(wù)邏輯，是一個根據(jù)參數(shù)選擇實例掉用的過程。
3.2.3.8、injectExtension
前面我們分析到已經(jīng)生成了一個實例了，該方法就是對該實例進行屬性的依賴注入操作，其實是掉該實例的setxxx方法進行參數(shù)賦值
private T injectExtension(T instance) {
if (objectFactory == null) {
return instance;
}
try {
//對實例中的setXXX方法進行屬性注入
for (Method method : instance.getClass().getMethods()) {
if (!isSetter(method)) {
continue;
}
/**
* Check {@link DisableInject} to see if we need auto injection for this
property
*/
//如果有DisableInject注解，則不注入
if (method.getAnnotation(DisableInject.class) != null) {
continue;
}
Class<?> pt = method.getParameterTypes()[0];
if (ReflectUtils.isPrimitives(pt)) {
continue;
}
try {
//根據(jù)方法名稱獲取該方法的屬性名稱
Stringproperty= getSetterProperty(method);
//獲取需要依賴注入的值
Objectobject= objectFactory.getExtension(pt, property);
if (object != null) {
//反射賦值
method.invoke(instance, object);
}
} catch (Exception e) {
logger.error("Failed to inject via method " + method.getName()
+ " of interface " + type.getName() + ": " + e.getMessage(), e);
}
}
} catch (Exception e) {
logger.error(e.getMessage(), e);
}
return instance;
}但是這里要強調(diào)的是，對調(diào)setxxx方法，參數(shù)值的來源
- 通過dubbo的spi方式獲取到參數(shù)值2、通過spring容器的getbean獲取到參數(shù)值
dubbo spi的方式獲取值
其實這種方法就是調(diào)用了getAdaptiveExtension方法獲取到了實例
public classSpiExtensionFactoryimplementsExtensionFactory {
@Override
public <T> T getExtension(Class<T> type, String name) {
if (type.isInterface() && type.isAnnotationPresent(SPI.class)) {
ExtensionLoader<T> loader = ExtensionLoader.getExtensionLoader(type);
if (!loader.getSupportedExtensions().isEmpty()) {
return loader.getAdaptiveExtension();
}
}
returnnull;
}
}spring容器的方式獲取值
這種方式就是掉getBean獲取到容器中的實例
public classSpringExtensionFactoryimplementsExtensionFactory, Lifecycle {
privatestaticfinalLoggerlogger=
LoggerFactory.getLogger(SpringExtensionFactory.class);
privatestaticfinal Set<ApplicationContext> CONTEXTS = new
ConcurrentHashSet<ApplicationContext>();
publicstaticvoidaddApplicationContext(ApplicationContext context) {
CONTEXTS.add(context);
if (context instanceof ConfigurableApplicationContext) {
((ConfigurableApplicationContext) context).registerShutdownHook();
// see https://github.com/apache/dubbo/issues/7093
DubboShutdownHook.getDubboShutdownHook().unregister();
}
}
publicstaticvoidremoveApplicationContext(ApplicationContext context) {
CONTEXTS.remove(context);
}
publicstatic Set<ApplicationContext> getContexts() {
return CONTEXTS;
}
// currently for test purpose
publicstaticvoidclearContexts() {
CONTEXTS.clear();
}
@Override
@SuppressWarnings("unchecked")
public <T> T getExtension(Class<T> type, String name) {
//SPI should be get from SpiExtensionFactory
if (type.isInterface() && type.isAnnotationPresent(SPI.class)) {
returnnull;
}
for (ApplicationContext context : CONTEXTS) {
Tbean= BeanFactoryUtils.getOptionalBean(context, name, type);
if (bean != null) {
return bean;
}
}
//logger.warn("No spring extension (bean) named:" + name + ", try to find an
//extension (bean) of type " + type.getName());
returnnull;
}
@Override
publicvoidinitialize()throws IllegalStateException {
clearContexts();
}
@Override
publicvoidstart()throws IllegalStateException {
// no op
}
@Override
publicvoiddestroy() {
clearContexts();
}
}3.2.4、總結(jié)
getAdaptiveExtension方法是dubbo spi中一個分成核心的方法，做了兩件事情，一個是獲取實例，一個是在ExtensionLoader中賦值了全局變量，這個變量會用到其他api中。實例獲取也分為兩種，獲取類上有@Adaptive注解的類的實例，一個是dubbo自動生成的代理實例，代理實例會根據(jù)接口配置來生成，接口的方法必須要有一個有@Adaptive注解，方法的入?yún)⒈仨氁cURL參數(shù)。
責(zé)任編輯：武曉燕
來源：
JAVA日知錄
