dubbo的SPI机制类似与Java的SPI，Java的SPI会一次性的实例化所有扩展点的实现，有点显得浪费资源。
dubbo的扩展机制可以方便的获取某一个想要的扩展实现，每个实现都有自己的name，可以通过name找到具体的实现。
每个扩展点都有一个@Adaptive实例，用来注入到依赖这个扩展点的某些类中，运行时通过url参数去动态判断最终选择哪个Extension实例用。
dubbo的SPI扩展机制增加了对扩展点自动装配（类似IOC）和自动包装（类似AOP）的支持。
标注了@Activate的扩展点实现类，可以通过getActivateExtension方法获取，可以根据条件加载一些自动激活的扩展点。 扩展点自动装配（IOC）功能：
1
接口A，实现类A1，A2
扩展点自动包装（AOP）功能：
其实是对扩展点采用装饰器模式进行增强。
1
接口A还有另外一个实现者：AWrapper1，此实现者有如下构造器：
当我们再获取接口A的实现类的时候，就已经被AWrapper1包装过了，我们得到的就是包装过得类。
定义
@SPI注解被此注解标记的接口，就是可扩展的接口。
@Adaptive注解@Adaptive有两种注解方式：一种是注解在类上，一种是注解在方法上。
注解在类上
注解在类上，而且是注解在实现类上，目前dubbo只有AdaptiveCompiler和AdaptiveExtensionFactory类上标注了此注解，这是些特殊的类，ExtensionLoader需要依赖他们工作，所以得使用此方式。
注解在方法上
注解在接口的方法上，除了上面两个类之外，所有的都是注解在方法上。ExtensionLoader根据接口定义动态的生成适配器代码，并实例化这个生成的动态类。被Adaptive注解的方法会生成具体的方法实现。没有注解的方法生成的实现都是抛不支持的操作异常UnsupportedOperationException。被注解的方法在生成的动态类中，会根据url里的参数信息，来决定实际调用哪个扩展。
比如说这段代码：
1
private static final Protocol refprotocol = ExtensionLoader.getExtensionLoader(Protocol.class).getAdaptiveExtension();
当上面代码执行的时候，我们其实还不知道要真正使用的Protocol是什么，可能是具体的实现DubboProtocol，也可能是其他的具体实现的Protocol，那么这时候refprotocol到底是什么呢？refprotocol其实是在调用getAdaptiveExtension()方法时候，自动生成的一个类，代码如下：
1
import com.alibaba.dubbo.common.extension.ExtensionLoader;
可以看到被@Adaptive注解的方法都生成了具体的实现，并且实现逻辑都相同。而没有被注解的方法直接抛出不支持操作的异常。
当我们使用refprotocol调用方法的时候，其实是调用生成的类Protocol$Adpative中的方法，这里面的方法根据url中的参数配置来找到具体的实现类，找具体实现类的方式还是通过dubbo的扩展机制。比如url中可能会有protocol=dubbo，此时就可以根据这个dubbo来确定我们要找的类是DubboProtocol。可以查看下生成的代码中getExtension(extName)这里是根据具体的名字去查找实现类。
@Activate注解此注解需要注解在类上或者方法上，并注明被激活的条件，以及所有的被激活实现类中的排序信息。
ExtensionLoader
ExtensionLoader是dubbo的SPI机制的查找服务实现的工具类，类似与Java的ServiceLoader，可做类比。dubbo约定扩展点配置文件放在classpath下的/META-INF/dubbo，/META-INF/dubbo/internal，/META-INF/services目录下，配置文件名为接口的全限定名，配置文件内容为配置名=扩展实现类的全限定名。
重点解析下ExtensionLoader这个类。dubbo的扩展点使用单一实例去加载，缓存在ExtensionLoader中。每一个ExtensionLoader实例仅负责加载特定SPI扩展的实现，想要获得某个扩展的实现，首先要获得该扩展对应的ExtensionLoader实例。
以Protocol为例进行分析扩展点的加载：
1
//这样使用，加载Protocol扩展点
第一步，getExtensionLoader(Protocol.class)，根据要加载的接口Protocol，创建出一个ExtensionLoader实例，加载完的实例会被缓存起来：
1
public static <T> ExtensionLoader<T> getExtensionLoader(Class<T> type) {
上面代码返回一个ExtensionLoader，getExtensionLoader(Protocol.class)这一步没有进行任何的加载工作，只是获得了一个ExtensionLoader的实例。加载是在调用getAdaptiveExtension()方法中进行的：
1
getAdaptiveExtension()-->
先看下getAdaptiveExtension()方法，用来获取一个扩展的自适应实现类，最后返回的自适应实现类是一个类名为Protocol$Adaptive，并且这个类实现了Protocol接口：
1
public T getAdaptiveExtension() {
接着看下createAdaptiveExtension()方法，用来创建自适应扩展类的实例：
1
private T createAdaptiveExtension() {
接着查看getAdaptiveExtensionClass()方法，用来获取一个自适应扩展的Class，这个Class将会在下一步被实例化：
1
private Class<?> getAdaptiveExtensionClass() {
先看下getExtensionClasses()这个方法，加载所有的扩展类的实现：
1
private Map<String, Class<?>> getExtensionClasses() {
看下loadExtensionClasses()方法，这个方法中加载扩展点的实现类：
1
private Map<String, Class<?>> loadExtensionClasses() {
从各个位置的配置文件中加载实现类，对于Protocol来说加载的文件是以com.alibaba.dubbo.rpc.Protocol为名称的文件，文件的内容是（有好几个同名的配置文件，这里直接把内容全部写在了一起）：
1
registry=com.alibaba.dubbo.registry.integration.RegistryProtocol
看下loadFile()方法：
1
private void loadFile(Map<String, Class<?>> extensionClasses, String dir) {
到这里加载当前Extension的所有实现就已经完成了，继续返回getAdaptiveExtensionClass中，在调用完getExtensionClasses()之后，会首先检查是不是已经有@Adaptive注解的类被解析并加入到缓存中了，如果有就直接返回，这里的cachedAdaptiveClass中现在只能是AdaptiveExtensionFactory或者AdaptiveCompiler中的一个，如果没有，说明是一个普通扩展点，就动态创建一个，比如会创建一个Protocol$Adaptive。
看下createAdaptiveExtensionClass()这个方法，用来动态的创建自适应扩展类：
1
private Class<?> createAdaptiveExtensionClass() {
接着看下createAdaptiveExtensionClassCode()方法，用来组装自适应扩展类的代码（拼写源码，代码比较长不在列出），这里列出生成的Protocol$Adaptive：
1
import com.alibaba.dubbo.common.extension.ExtensionLoader;
其他具体的扩展点的生成也类似。在生成完代码之后，是找到ClassLoader，然后获取到Compiler的自适应实现，这里得到的就是AdaptiveCompiler，最后调用compiler.compile(code, classLoader);来编译上面生成的类并返回，先进入AdaptiveCompiler的compile方法：
1
public Class<?> compile(String code, ClassLoader classLoader) {
先看下根据具体的名字来获取扩展的实现类loader.getExtension(name);，loader是ExtensionLoader<Compiler>类型的。这里就是比Java的SPI要方便的地方，Java的SPI只能通过遍历所有的实现类来查找，而dubbo能够指定一个名字查找。代码如下：
1
public T getExtension(String name) {
创建扩展实例，createExtension(name);：
1
private T createExtension(String name) {
有关属性注入和Wrapper的包装，下面再讲。到这里Compiler就能获得到一个指定name的具体实现类的实例了，然后就是调用实例的compile()方法对生成的代码进行编译。
如果在AdaptiveCompiler中没有找到指定的名字，就会找默认的扩展实现loader.getDefaultExtension();：
1
public T getDefaultExtension() {
关于javassist编译Class的过程暂先不说明。我们接着流程看：
1
private T createAdaptiveExtension() {
接下来就是有关扩展点的注入的问题了，injectExtension，关于注入的解释查看最上面扩展点自动装配（IOC）的说明，injectExtension方法：
1
//这里的实例是Xxxx$Adaptive
有关AdaptiveExtensionFactory中获取Extension的过程，会首先在实例化的时候得到ExtensionFactory的具体实现类，然后遍历每个ExtensionFactory的实现类，分别在每个ExtensionFactory的实现类中获取Extension。
这里使用SpiExtensionFactory的获取扩展的方法为例，getExtension，也是先判断给定类是否是注解了@SPI的接口，然后根据类去获取ExtensionLoader，在使用得到的ExtensionLoader去加载自适应扩展。
objectFactory的来路，在ExtensionLoader中有个私有构造器：
1
//当我们调用getExtensionLoader这个静态方法的时候，会触发ExtensionLoader类的实例化，会先初始化静态变量和静态块，然后是构造代码块，最后是构造器的初始化
到此为止createAdaptiveExtension方法解析完成，接着返回上层getAdaptiveExtension()方法中，发现创建完自适应扩展实例之后，就会加入到cachedAdaptiveInstance缓存起来，然后就会返回给调用的地方一个Xxx$Adaptive实例。
走到这里，下面的代码就解析完了：
1
private static final Protocol refprotocol = ExtensionLoader.getExtensionLoader(Protocol.class).getAdaptiveExtension();
我们的到了一个Protocol$Adaptive实例，接着就是调用了，比如说我们要调用refprotocol.refer(Class<T> type, URL url))方法，由于这里refprotocol是一个Protocol$Adaptive实例，所以就先调用这个实例的refer方法，这里的实例的代码在最上面：
1
//这里为了好看，代码做了精简，包名都去掉了
可以看到这里首先根据url中的参数获取扩展名字，如果url中没有就使用默认的扩展名，然后根据扩展名去获取具体的实现。关于getExtension(String name)上面已经解析过一次，这里再次列出：
1
public T getExtension(String name) {
创建扩展实例，createExtension(name);：
1
private T createExtension(String name) {
获取的Extension是经过层层包装的扩展实现，然后就是调用经过包装的refer方法了，这就到了具体的实现中的方法了。
到此为止调用refprotocol.refer(Class<T> type, URL url))方法的过程也解析完了。
关于getActivateExtension方法的解析，等下再添加。
