上一节简单的对dubbo的外围知识进行了简单的打探，下面开始真正进入dubbo。开启dubbo的源码探索之旅。
JDK自带的SPI正因为有在上一节提到的缺点，因此在dubbo中对其进行了扩展。这节重点来看看dubbo是怎么扩展JDK的SPI。
dubbo中定义了注解：
@Documented
@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.TYPE})
public @interface SPI {
/**
* 缺省扩展点名。
*/
String value() default "";
}
在dubbo中只有在接口打了@SPI注解的接口，它的实现类才会被当成扩展点的实现进行查找。
例如：接口：Protocol 被SPI注解标注，默认扩展点的名字为dubbo
@SPI("dubbo")
public interface Protocol {
//省
}
此接口的实现类（相关类）：
dubbo中RPC模块默认协议(Protocol )的实现是：DubboProtocol，key:dubbo
这里插一句：dubbo加载扩展点的地方：
1）META-INF/dubbo/internal/ //dubbo内部实现的各种扩展都放在了这个目录了
2）META-INF/dubbo/
3）META-INF/services/
因此定义DubboProtocol的文件在：
查看com.alibaba.dubbo.rpc.protocol文件中的内容：
dubbo=com.alibaba.dubbo.rpc.protocol.dubbo.DubboProtocol。Protocol的其中一个扩展点就在此定义。
在文件中定义了接口的扩展点之后，最重要的就是读取配置文件中的信息，并且按需加载相应的扩展点的实现。在dubbo中ExtensionLoader类负责加载扩展点的实现。
下面来重点看看ExtensionLoader类
首先对ExtensionLoader说明一下：
1）每一个ExtensionLoader实例仅负责加载被SPI注解扩展的实现
2）每一个ExtensionLoader实例只负责加载一个特定扩展点实现
3）每一个扩展点(一个被SPI注解的接口)对应最多只有一个ExtensionLoader实例
4）每一个扩展点对应最多只有一个ExtensionLoader实例
5）对于每一个扩展点的每一个实现类，只会有一个实例。
下面介绍一下ExtensionLoader类中的几个重点方法：
1，ExtensionLoader.getExtensionLoader(Protocol.class)
根据接口类型创建一个ExtensionLoader并且放入缓存中：EXTENSION_LOADERS(一个静态对象)，如果已经存在了该接口类型的ExtensionLoader实例，就直接返回。
2，loadExtensionClasses():
读取扩展点中的实现类
1）先读取SPI注解的value值，如果有作为默认扩展实现类的key。
2）依次读取路径的文件
META-INF/dubbo/internal/com.alibaba.dubbo.rpc.Protocol
META-INF/dubbo/com.alibaba.dubbo.rpc.Protocol
META-INF/services/com.alibaba.dubbo.rpc.Protocol
3，loadFile():
逐行读取com.alibaba.dubbo.rpc.Protocol文件中的内容，每行内容以key/value形式存储。
1）判断实现类上有没有被@Adaptive注解：
11）如果被@Adaptive的注解，将此实现类作为Protocol的适配类缓存起来，赋值给cachedAdaptiveClass属性,(只能有一个@Adaptive实现类,出现第二个就会报错了)。
12）如果没有被@Adaptive注解，
121）判断实现类是否存在入参为接口的构造器，如果存在作为包装类缓存到Set<Class<?>> cachedWrapperClasses中(装饰模式)
122）如果不是适配类不是包装类，就是扩展点的具体实现对象。将实现类缓存到cachedClasses属性中。
4，创建或获取适配对象getAdaptiveExtension
1）如果cachedAdaptiveClass有值，说明有且仅有一个实现类打了@Adaptive。
Object instance = cachedAdaptiveInstance.get();
2）如果cachedAdaptiveClass为空， 创建适配类字节码
为什么要创建适配类？一个接口多种实现，SPI机制也是如此，这是策略模式。但是我们在代码执行过程中选择哪种具体的策略呢？Dubbo采用统一数据模式com.alibaba.dubbo.common.URL(它是dubbo定义的数据模型不是jdk的类)，它会穿插于系统的整个执行过程，URL中定义的协议类型字段protocol，会根据具体业务设置不同的协议。url.getProtocol()值可以是dubbo也是可以webservice。
适配类的作用是根据url.getProtocol()的值extName，去ExtensionLoader. getExtension( extName)选取具体的扩展点实现。
插一句：
能够利用javasist生成适配类的条件
1）接口方法中必须至少有一个方法打上了@Adaptive注解
2）打上了@Adaptive注解的方法参数必须有URL类型参数或者有参数中存在getURL()方法。
5，通过createAdaptiveExtensionClassCode()会生成Protocol接口的适配类的java源码代码。如果生成的适配类源码要被java虚拟机加载执行的话，那必须编译成字节码。dubbo提供两种方式去执行代码的编译1）利用JDK工具类编译2）利用javassit根据源代码生成字节码。
后面会专门探索一下dubbo中的compiler接口。
@Adaptive注解在实现类上和在接口方法上的区别：
1）在实现类上：通过获取扩展文件的时候遇到注解@Adaptive，就把这个类作为适配类缓存在ExtensionLoader中，调用的时候直接返回。
2）在接口上：首先生成JAVA代码。在通过编译器编译成class加载。
6，自动Wrap上扩展点的Wrap类
我们还是拿protocol来说，ProtocolFilterWrapper, ProtocolListenerWrapper这个两个类是装饰对象实现protocol，用来增强其他扩展点实现的功能。ProtocolFilterWrapper功能主要是在refer 引用远程服务的中透明的设置一系列的过滤器链用来记录日志，处理超时，权限控制等等功能；ProtocolListenerWrapper在provider的exporter,unporter服务和consumer的refer服务，destory调用时添加监听器，dubbo提供了扩展但是没有默认实现哪些监听器。
Dubbo是如何自动的给扩展点wrap上装饰对象的呢？
1）在ExtensionLoader.loadFile加载扩展点配置文件的时候
对扩展点类有接口类型为参数的构造器就是包转对象，缓存到集合中去
2）在调ExtensionLoader的createExtension(name)根据扩展点key创建扩展的时候， 先实例化扩展点的实现， 在判断时候有此扩展时候有包装类缓存，有的话利用包转器增强这个扩展点实现的功能。
private T createExtension(String name) {
Class<?> clazz = getExtensionClasses().get(name);//获取name对应的扩展类型
if (clazz == null) {
throw findException(name);
}
try {
T instance = (T) EXTENSION_INSTANCES.get(clazz);
if (instance == null) {
EXTENSION_INSTANCES.putIfAbsent(clazz, (T) clazz.newInstance());
instance = (T) EXTENSION_INSTANCES.get(clazz);
}
injectExtension(instance);//扩展点注入
Set<Class<?>> wrapperClasses = cachedWrapperClasses;
if (wrapperClasses != null && wrapperClasses.size() > 0) {
for (Class<?> wrapperClass : wrapperClasses) {
//循环遍历所有wrapper实现，实例化wrapper并进行扩展点注入
instance = injectExtension((T) wrapperClass.getConstructor(type).newInstance(instance));
}
}
return instance;
} catch (Throwable t) {
throw new IllegalStateException("Extension instance(name: " + name + ", class: " +
type + ") could not be instantiated: " + t.getMessage(), t);
}
}
7. dubbo的ExtensionLoader在加载扩展实现的时候内部实现了个简单的ioc机制来实现对扩展实现所依赖的参数的注入，dubbo对扩展实现中公有的set方法且入参个数为一个的方法，尝试从对象工厂ObjectFactory获取值注入到扩展点实现中去。
/**
* 扩展点参数的自动注入
* @param instance
* @return
*/
private T injectExtension(T instance) {
try {
if (objectFactory != null) {
for (Method method : instance.getClass().getMethods()) {
if (method.getName().startsWith("set")
&& method.getParameterTypes().length == 1
&& Modifier.isPublic(method.getModifiers())) {// 处理所有set方法
Class<?> pt = method.getParameterTypes()[0];// 获取set方法参数类型
try {
// 获取setter对应的property名称
String property = method.getName().length() > 3 ? method.getName().substring(3, 4).toLowerCase() + method.getName().substring(4) : "";
Object object = objectFactory.getExtension(pt, property);// 根据类型，名称信息从ExtensionFactory获取
if (object != null) {
method.invoke(instance, object);
// 如果不为空，说set方法的参数是扩展点类型
// instance对象调用method方法，参数为object
// 这样来实现动态注入
}
} catch (Exception e) {
logger.error("fail to inject via method " + method.getName()
+ " of interface " + type.getName() + ": " + e.getMessage(), e);
}
}
}
}
} catch (Exception e) {
logger.error(e.getMessage(), e);
}
return instance;
}
AdaptiveExtensionFactory持有所有ExtensionFactory对象的集合，dubbo内部默认实现的对象工厂是SpiExtensionFactory和SpringExtensionFactory，他们存放在ArrayList对象中，getExtension(Class<T> type, String name)遍历获取Extension对象，如果遍历完集合中没有找到扩展对象，就返回NULL。
1）SpiExtensionFactory工厂获取要被注入的对象，就是要获取dubbo spi扩展的实现，所以传入的参数类型必须是接口类型并且接口上打上了@SPI注解，返回的是一个适配类对象。
2） SpringExtensionFactory，Dubbo利用spring的扩展机制跟spring做了很好的融合。在发布或者去引用一个服务的时候，会把spring的容器添加到SpringExtensionFactory工厂集合中去， 当SpiExtensionFactory没有获取到对象的时候会遍历SpringExtensionFactory中的spring容器来获取要注入的对象。
最后附上一个活动图(参照斩秋博主的所画)：
总结：
ExtensionLoader加载扩展点的各种类型的实现类
适配类：每个扩展点只会有一个适配实现类出现。如果没有找到适配类，会使用JDK动态代理或者是javasist动态生成一个。
装饰类：实现类是否存在入参为接口的构造函数，如果有就是装饰类。可以多个
实现类：如果不是适配类不是包装类，就是扩展点的具体实现对象
以上是我个人的对dubbo的一些见解，欢迎大家一起讨论！
下一节，我想看看ExtensionFactory