探究Dubbo的ExtensionLoader

必定要对比JDK的SPI机制，才能更好的理解Dubbo的SPI实现！

扩展点：即接口
扩展：扩展点的实现，即接口的实现类

1. 获取扩展点的ServiceLoader实例

2. 经过扩展点的ServiceLoader实例，完成扩展的方法调用

package com.nucc;
​
import java.util.ServiceLoader;
​
/**
 * JDK SPI Sample.
 */
public class App {
    public static void main(String[] args) {
        ServiceLoader<Command> serviceLoader = ServiceLoader.load(Command.class);
​
        for (Command cmd : serviceLoader) {
            cmd.execute();
        }
    }
}

经过以上代码理解了JDK的SPI机制，那么DUBBO SPI机制该怎么实现？

1⃣ 获取扩展点的ExtensionLoader实例，但愿它是单例的，初始化后将它缓存起来(方便之后拿出来直接用)；

2⃣ 获取扩展的实例，为了不JDK SPI中一次所有加载带来的资源损耗问题，Dubbo SPI机制应在设计上应采用延迟加载机制，即只获取想要的扩展，而非将所有扩展进行加载。

深刻探究Dubbo的ExtensionLoader

1. getExtensionLoader(Class<?> type) : 单例模式，获取接口type的ExtensionLoader实例，扩展上必须添加@SPI注解，对于扩展点只会加载一次，生成一个ExtensionLoader实例，放入缓存中。

2. getAdaptiveExtension() ：获取扩展点的实现，dubbo框架在调用getAdaptiveExtension()中，将配置文件中的META-INF\dubbo\internal下全部的配置初始化加载到缓存中，这个方法会首先在扩展点接口的全部实现类中查找类上是否含有@Adaptive注解，若是有这个样的类注解返回该类的实例，若是没有则会查找扩展点接口的方法是否有@Adaptive注解，并动态编译一个类实现该接口并扩展这些含有@Adaptive注解的方法。默认将采用@SPI注解value指定的扩展。若是开发者选择使用其它扩展，则在dubbo的spring xml配置中指定。Dubbo使用“自适应”的扩展，在运行时经过URL中的配置参数决定采用哪个扩展的方案，解决了JDK SPI中一次所有加载带来的资源损耗问题。

   若是用@Adaptive标记一个类，表示该类是一个自适应的扩展点实现，目前系统只有两个：AdaptiveCompiler(整个框架仅支持Javassist和JdkCompiler)和AdaptiveExtensionFactory(整个框架仅支持2个objFactory,一个是spi,另外一个是spring)；

   若是用@Adaptive标记一个方法，则dubbo会动态生成一个扩展点的实现，例如Protocol$Adaptive（dubbo的动态代码生成与编译），该扩展点代码实现是经过javassit技术动态建立的类，并由dubbo编译加载。

   --> 面向对象设计的“开闭原则”，以及动态代理模式

   在上述流程中，生成一个扩展点的实例（适配器类）时，须要完成依赖的注入，Dubbo采用ExtensionFactory扩展点的实现来完成（SPI和Spring），即采用injectExtension方法为适配器的setter方法插入其它扩展点的实现或者Spring中的bean，此处为dubbo的Ioc设计。

3. getExtension(String name) ： 获取指定名字的扩展