Dubbo自适应扩展机制
Dubbo里除了Service和Config层为API，其它各层均为SPI。相比于JAVA中的SPI仅仅通过接口类名获取所有实现，Dubbo的实现可以通过接口类名和key值来获取一个具体的实现。通过SPI机制，Dubbo实现了面向插件编程，只定义了模块的接口，实现由各插件来完成。
1. 使用方式
1.1 Java SPI
在扩展类的jar包内，放置扩展点配置文件META-INF/service/接口全限定名，内容为：扩展实现类全限定名，多个实现类用换行符分隔。
如下为MySQL中Driver接口的实现：
package com.mysql.jdbc;
import java.sql.SQLException;
public class Driver extends NonRegisteringDriver implements java.sql.Driver {
... }
调用时使用ServiceLoader加载所有的实现并通过循环来找到目标实现类
ServiceLoader<Driver> loadedDrivers = ServiceLoader.load(Driver.class);
Iterator<Driver> driversIterator = loadedDrivers.iterator();try{
while(driversIterator.hasNext()) {
driversIterator.next(); }} catch(Throwable t) {
// Do nothing
}
1.2 Dubbo SPI
拿Dubbo中Protocol接口来说，Protocol的定义如下：
package org.Apache.dubbo.rpc;
import org.apache.dubbo.common.URL;
import org.apache.dubbo.common.extension.Adaptive;
import org.apache.dubbo.common.extension.SPI;
@SPI("dubbo")
public interface Protocol { int getDefaultPort();
@Adaptive
<T> Exporter<T> export(Invoker<T> invoker) throws RpcException; @Adaptive
<T> Invoker<T> refer(Class<T> type, URL url) throws RpcException; void destroy();
}
需要指出的是Invoker继承了Node接口，而Node接口提供了getUrl方法，既每个方法都能从入参获得URL对象。
public interface Node {
URL getUrl();
boolean isAvailable();
void destroy();
}
要求
1.接口上有org.apache.dubbo.common.extension.SPI注解，提供默认的实现
2.对于支持自适应扩展的方法要求方法入参能获得org.apache.dubbo.common.URL对象，同时方法上有org.apache.dubbo.common.extension.Adaptive注解，Adaptive注解可以提供多个key名，以便从URL中获取对应key的值，从而匹配到对应的实现(这里Protocol比较特别，没有提供key名也能根据URL来动态获取实现，后面会说明)
3.在扩展类的jar包内，放置扩展点配置文件META-INF/dubbo/接口全限定名，内容为：配置名=扩展实现类全限定名，多个实现类用换行符分隔。如Protocol的默认实现:
注意：META-INF/dubbo/internal为Dubbo内部实现的配置文件路径
调用时通过ExtensionLoader根据需要来选择具体的实现类，
ExtensionLoader<Protocol> loader = ExtensionLoader.getExtensionLoader(Protocol.class);
可选方式包括
1.选择默认的实现
Protocol protocol = loader.getDefaultExtension();
2.根据指定key选择实现
Protocol protocol = loader.getExtension("dubbo");
3.根据URL参数动态获取实现
Protocol protocol = loader.getAdaptiveExtension();
2. Dubbo SPI 特性
Dubbo对Java中的标准SPI进行了扩展增强，官方文档中提到其提供了如下特性：
- 扩展点自动包装
- 扩展点自动装配
- 扩展点自适应
- 扩展点自动激活
在介绍各个特性前先介绍下大概的内部实现。从上面的使用中可以看到Dubbo对SPI扩展的主要实现在ExtensionLoader类中，关于这个类源码的讲解可以看官方文档，讲解的很详细，这边主要说下大概过程：
- 根据传入的类型从classpath中查找META-INF/dubbo/internal和META-INF/dubbo路径下所有对应的扩展点配置文件
- 读取扩展点配置文件中所有的键值对
- 根据键值对缓存Class对象，如果类有同类型参数的构造函数，则为包装类，会缓存在另一个容器中
- 实例化对象，缓存后并返回
2.1 扩展点自动包装
在返回真正实例前，会用该类型的包装类进行包装，既采用装饰器模式进行功能增强。
if (CollectionUtils.isNotEmpty(wrApperClasses)) {
// 循环创建 Wrapper 实例
for (Class<?> wrapperClass : wrapperClasses) {
// 将当前 instance 作为参数传给 Wrapper 的构造方法，并通过反射创建 Wrapper 实例。
// 然后向 Wrapper 实例中注入依赖，最后将 Wrapper 实例再次赋值给 instance 变量
instance = injectExtension((T) wrapperClass.getConstructor(type).newInstance(instance));
}
}
其实就是使用静态代理来实现AOP
2.2 扩展点自动装配
返回实例前会遍历所有的setXXX方法，判断set方法参数是否存在自适应对象，如果存在则通过ExtensionLoader加载自适应对象然后进行赋值，可以通过方法上加org.apache.dubbo.common.extension.DisableInject注解来屏蔽该功能。该功能其实就是实现了IOC，具体可以看ExtensionLoader的injectExtension方法。
2.3 扩展点自适应
同上面介绍的一样，Dubbo的SPI可以根据传入的URL参数中携带的数据来动态选择具体的实现。
2.4 扩展点自动激活
上面介绍过，Adaptive注解是加在方法上的，类似的有个注解org.apache.dubbo.common.extension.Activate是加在实现类上。当加在Class上时，ExtensionLoader会将对应的key和Class信息缓存到另一个容器中，后续可以通过ExtensionLoader获取某一类的实现列表，既如下方法
public List<T> getActivateExtension(URL url, String[] values){
...}
3. ExtensionLoader自适应扩展机制
ExtensionLoader自适应扩展机制的大概实现逻辑是这样的：Dubbo会为拓展接口生成具有代理功能的代码，然后通过 javassist 或 jdk 编译这段代码，得到 Class 类。最后再通过反射创建代理类，在代理类中，就可以通过URL对象的参数来确定到底调用哪个实现类。主要实现在createAdaptiveExtensionClass方法中。
private Class<?> createAdaptiveExtensionClass() {
String code = new AdaptiveClassCodeGenerator(type, cachedDefaultName).generate();
ClassLoader classLoader = findClassLoader(); org.apache.dubbo.common.compiler.Compiler compiler = ExtensionLoader.getExtensionLoader(org.apache.dubbo.common.compiler.Compiler.class).getAdaptiveExtension();
return compiler.compile(code, classLoader);
}
上面的Protocol接口经过处理后的内容如下：
public class Protocol$Adaptive implements org.apache.dubbo.rpc.Protocol {
public void destroy() {
throw new UnsupportedOperationException(
"The method public abstract void org.apache.dubbo.rpc.Protocol.destroy() of interface org.apache.dubbo.rpc.Protocol is not adaptive method!");
} public int getDefaultPort() {
throw new UnsupportedOperationException(
"The method public abstract int org.apache.dubbo.rpc.Protocol.getDefaultPort() of interface org.apache.dubbo.rpc.Protocol is not adaptive method!");
} public org.apache.dubbo.rpc.Exporter export(org.apache.dubbo.rpc.Invoker arg0) throws org.apache.dubbo.rpc.RpcException {
if (arg0 == null) {
throw new IllegalArgumentException("org.apache.dubbo.rpc.Invoker argument == null");
} if (arg0.getUrl() == null) {
throw new IllegalArgumentException("org.apache.dubbo.rpc.Invoker argument getUrl() == null");
} org.apache.dubbo.common.URL url = arg0.getUrl(); String extName = (url.getProtocol() == null ? "dubbo" : url.getProtocol());
if (extName == null) {
throw new IllegalStateException(
"Failed to get extension (org.apache.dubbo.rpc.Protocol) name from url (" + url.toString() + ") use keys([protocol])");
} org.apache.dubbo.rpc.Protocol extension = (org.apache.dubbo.rpc.Protocol) ExtensionLoader .getExtensionLoader(org.apache.dubbo.rpc.Protocol.class).getExtension(extName);
return extension.export(arg0);
} public org.apache.dubbo.rpc.Invoker refer(java.lang.Class arg0, org.apache.dubbo.common.URL arg1) throws org.apache.dubbo.rpc.RpcException {
if (arg1 == null) {
throw new IllegalArgumentException("url == null");
} org.apache.dubbo.common.URL url = arg1; String extName = (url.getProtocol() == null ? "dubbo" : url.getProtocol());
if (extName == null) {
throw new IllegalStateException(
"Failed to get extension (org.apache.dubbo.rpc.Protocol) name from url (" + url.toString() + ") use keys([protocol])");
} org.apache.dubbo.rpc.Protocol extension = (org.apache.dubbo.rpc.Protocol) ExtensionLoader .getExtensionLoader(org.apache.dubbo.rpc.Protocol.class).getExtension(extName);
return extension.refer(arg0, arg1);
}}
前面提到过，Protocol是一个比较特殊的接口，Adaptive注解里没有指定Key，因而没法通过URL携带的参数获取具体的实现类。从上面处理过后的内容来看，可以看到，对于Protocol接口直接使用的URL的protocol属性字段的值来进行判断的。
如下例子是在Adaptive里有提供key的实现处理过后的内容：
public java.lang.String sayHello(org.apache.dubbo.common.URL arg0) {
if (arg0 == null) {
throw new IllegalArgumentException("url == null");
} org.apache.dubbo.common.URL url = arg0; String extName = url.getParameter("keyA", "dobbo");
if (extName == null) {
throw new IllegalStateException("Failed to get extension (cn.demo.spi.Factory) name from url (" + url.toString() + ") use keys([keyA])");
} cn.demo.spi.Factory extension = (cn.demo.spi.Factory) ExtensionLoader.getExtensionLoader(cn.demo.spi.Factory.class).getExtension(extName);
return extension.sayHello(arg0);
}
可以发现这种情况直接使用的URL的getParameter方法从携带的参数中获取对应的值。
通过查看AdaptiveClassCodeGenerator的实现可以发现该类的generateExtNameAssignment里对protocol做了特殊的判断。AdaptiveClassCodeGenerator完成了代理类内容的创建，大概过程为：根据原接口定义(type)，包装出根据URL参数动态调用getExtension方法的实现类，然后将动作实际委托给了ExtensionLoader.getExtensionLoader(type).getExtension(extName);方法。其中extName为方法上的Adaptive注解指定的key的对应值，获取过程为：
- 如果Adaptive注解配置的key为空，则使用类名作为扩展名
- 如果扩展名为protocol，则从URL的protocol里获取对应的值
- 如果扩展名不为protocol，且方法参数里有org.apache.dubbo.rpc.Invocation，则从URL.getMethodParameter里获取
- 以上都没有则直接从URL.getParameter中获取。
Protocol接口由于没有在Adaptive注解里指定key，则会使用类名protocol作为默认的扩展名，从而命中第2条规则。
通过自适应扩展机制，Dubbo框架的各层的核心实现都是基于接口的，而将具体的实现下放到插件中。根据加载的插件不同，各层能够选择适合的实现而不会影响核心的逻辑流程。如Protocol接口，表示通信协议，可选的实现包括dubbo、rmi、http等。
