Dubbo SPI

Dubbo 在设计之初，为了架构的灵活性，在它架构中的每层为每个功能点都提供了一个 SPI 扩展接口（Dubbo 增强 SPI），Dubbo 框架在使用扩展点功能的时候是对接口进行依赖，而一个扩展接口对应了一系列的扩展实现类，那么如何选择具体的实现类呢？让我们来看看源码吧！

我们以 Protocol 接口为例：

可以看到 SPI 注解中的值为 dubbo，Dubbo 在运行过程中会使用动态编译技术为接口 Protocol 生成一个适配器类 Protocol$Adaptive 的实例，而这个实例的实现就对应 SPI 注解中所配置的 dubbo 对应的类的实现（具体是在 META-INFO/dubbo、META-INFO/dubbo/internal、META-INFO/services 这三个文件夹下的配置中配置的实现类），下面让我们看看 Dubbo 到底是怎么生成这个 Adaptive 的实例的吧！

@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();

    default List<ProtocolServer> getServers() {
        return Collections.emptyList();
    }
}
​

在 Provider 方我们会用到一个类叫 ServiceConfig，而在 ServiceConfig 中维护了一个静态内部常量 protocol，它使用了 ExtensionLoader.getExtensionLoader(Protocol.class).getAdaptiveExtension() 来获取是配置对象。

我们进入 getExtensionLoader 方法中可以看到这是一个静态方法，并且它为每一个 Dubbo 扩展接口都维护了一个 ExtensionLoader 实例，通过这个方法可以拿到对应 Dubbo 扩展接口的 ExtensionLoader。

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!");
    }
    if (!withExtensionAnnotation(type)) {
        throw new IllegalArgumentException("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) {
        // 根据扩展接口的class来获取loader
        EXTENSION_LOADERS.putIfAbsent(type, new ExtensionLoader<T>(type));
        loader = (ExtensionLoader<T>) EXTENSION_LOADERS.get(type);
    }
    return loader;
}
​

然后通过调用 ExtensionLoader 的实例方法 getAdaptiveExtension() 来获取适配器实例，这里的调用链比较长。

首先 ExtensionLoader 中维护了一个实例的缓存 cachedAdaptiveInstance，先判断缓存中是否存在，如果存在直接返回，然后通过双重校验的方式保证只会实例化一次，通过调用 createAdaptiveExtension() 方法来创建实例。

public T getAdaptiveExtension() {
    // 缓存
    Object instance = cachedAdaptiveInstance.get();
    if (instance == null) {
        if (createAdaptiveInstanceError == null) {
            synchronized (cachedAdaptiveInstance) {
                instance = cachedAdaptiveInstance.get();
                if (instance == null) {
                    try {
                        // 获取实例
                        instance = createAdaptiveExtension();
                        cachedAdaptiveInstance.set(instance);
                    } catch (Throwable t) {
                        createAdaptiveInstanceError = t;
                        throw new IllegalStateException("Failed to create adaptive instance: " + t.toString(), t);
                    }
                }
            }
        } else {
            throw new IllegalStateException("Failed to create adaptive instance: " + createAdaptiveInstanceError.toString(), createAdaptiveInstanceError);
        }
    }

    return (T) instance;
}
​

进入到 createAdaptiveExtension() 方法，这里的 injectExtension 方法主要是为 Extension$Adaptive 实例注入依赖，而构建实例的方法是 getAdaptiveExtensionClass().newInstance()，其中 getAdaptiveExtensionClass() 是生成动态编译的类，将该类注入到对应的 ClassLoader 中，而生成实例则是调用 newInstance() 方法。

private T createAdaptiveExtension() {
    try {
        return injectExtension((T) getAdaptiveExtensionClass().newInstance());
    } catch (Exception e) {
        throw new IllegalStateException("Can't create adaptive extension " + type + ", cause: " + e.getMessage(), e);
    }
}
​

接下来进入到 getAdaptiveExtensionClass() 方法中，看看动态编译的类是怎么生成的。
可以看到 Dubbo 会先从 META-INF 路径下读取配置文件并加载 class 文件，在这里面会读取扩展接口上的 @SPI 的值，这里有个不一样的地方，大家知道这个适配器是为了选择自己想要的扩展，但是 Dubbo 将实现这个功能中的 Compiler（动态编译）也弄成了一个扩展，如果按照之前设计的走向，那么就会变成套娃无限循环，就是选择 Compiler 的一个实例需要一个 Compiler 实例去动态编译它，所以 Dubbo 又扩展了一个注解 @Adaptive，也就是这里的第二步，Adaptive 注解的作用用通俗的说法就是适配器的适配器，拿 Compiler 举例，@SPI 的适配器并不会选择最终的 Compiler 去实例化，而是会选择打上了 Adaptive 注解的 Compiler 去实例化，而这个打上了 Adaptive 注解的类会去实例化我们最终选择的 Compiler 类，可以在 dubbo-common 项目的 META-INFO/dubbo.internal 文件夹中找到它，而这个 AdaptiveCompiler 的 compile 方法会再去获取一次 SPI 注解上配置的 Compiler，然后用这个 Compiler 进行动态编译。

// ExtensionLoader.java
private Class<?> getAdaptiveExtensionClass() {
    // 1 从META-INF路径下的文件中读取定义的class文件
    // 这里会从几个固定的路径去读取配置文件信息
    getExtensionClasses();
    // 2 如果存在@Adaptive注解的类，则优先使用这个类
    if (cachedAdaptiveClass != null) {
        return cachedAdaptiveClass;
    }
    // 3 通过扩展接口上的注解配置名称来创建Adaptive的Class对象
    return cachedAdaptiveClass = createAdaptiveExtensionClass();
}
​

private Class<?> createAdaptiveExtensionClass() {
    String code = new AdaptiveClassCodeGenerator(type, cachedDefaultName).generate();
    ClassLoader classLoader = findClassLoader();
    // 获取Compiler，如果没有Compiler则会先初始化Compiler
    org.apache.dubbo.common.compiler.Compiler compiler = ExtensionLoader.getExtensionLoader(org.apache.dubbo.common.compiler.Compiler.class).getAdaptiveExtension();
    return compiler.compile(code, classLoader);
}
​

// ExtensionLoader.java
private Map<String, Class<?>> loadExtensionClasses() {
    // 获取SPI注解上的扩展名
    cacheDefaultExtensionName();

    Map<String, Class<?>> extensionClasses = new HashMap<>();
    // 从固定的几个路径中读取配置的class
    // loadDirectory中会处理Adaptive注解的class，会将其缓存到cachedAdaptiveClass变量中
    loadDirectory(extensionClasses, DUBBO_INTERNAL_DIRECTORY, type.getName());
    loadDirectory(extensionClasses, DUBBO_INTERNAL_DIRECTORY, type.getName().replace("org.apache", "com.alibaba"));
    loadDirectory(extensionClasses, DUBBO_DIRECTORY, type.getName());
    loadDirectory(extensionClasses, DUBBO_DIRECTORY, type.getName().replace("org.apache", "com.alibaba"));
    loadDirectory(extensionClasses, SERVICES_DIRECTORY, type.getName());
    loadDirectory(extensionClasses, SERVICES_DIRECTORY, type.getName().replace("org.apache", "com.alibaba"));
    return extensionClasses;
}
​

// AdaptiveCompiler.java
public Class<?> compile(String code, ClassLoader classLoader) {
    Compiler compiler;
    ExtensionLoader<Compiler> loader = ExtensionLoader.getExtensionLoader(Compiler.class);
    String name = DEFAULT_COMPILER; // copy reference
    if (name != null && name.length() > 0) {
        compiler = loader.getExtension(name);
    } else {
        // 这里获取@SPI上配置的Compiler
        compiler = loader.getDefaultExtension();
    }
    return compiler.compile(code, classLoader);
}
​

所以可以看到，在第一次获取 SPI 的实例对象的时候，预加载完 class 文件后，如果没有找到对应的 Adaptive 类则会进行 class 的构建，而第一次构建的时候 Compiler 并没有被初始化，这个时候会先走一遍 Compiler 的初始化，将 AdaptiveCompiler 作为 Compiler 的对应实例，然后通过 AdaptiveCompiler 去初始化 Compiler 接口 SPI 注解中的对应实例，最后通过 Compiler 对需要的实例类进行初始化，最后通过 newInstance 获取实例。

ok，源码到这里就分析结束了，谢谢~