阅读dubbo代码的困惑
在阅读dubbo源码的过程中，最初带给我最大的困惑就是在多实现的接口中，如何查找当前上下文中的接口实现。例如：
在dubbo源码中这样格式的代码大量存在，所以在学习dubbo代码前，一定要了解dubbo spi机制。这样对于dubbo的学习，会有事半功倍的效果。
dubbo SPI简介
dubbo采用微内核+插件的设计原则，即dubbo的所有的功能点都可以被用户自定义的插件覆盖。这种设计原是通过service provider interface(SPI)的方式实现的，就是厂商定义了服务标准，用户去实现。jdk中也实现了这点，至于dubbo为什么没有采用jdk标准的spi，而是自己重新实现了，官方给出的即解释是jdk会一次实例化所有的插件，即使有的插件用不到。dubbo的开发者认为这是一种资源浪费，dubbo想要的是只有在用到某种扩展插件的时候，再去实例化。
例如，dubbo默认支持了ConsistentHashLoadBalance(一致性hash)、LeastActiveLoadBalance(最小活跃调用数)、RandomLoadBalance(按权重设置随机概率)、RoundRobinLoadBalance(按公约后的轮训设置权重比例)四种负载均衡策略。用户可以再此基础上扩展自己的负载均衡策略，并在consumer端指定自定义的负载策略。
dubbo SPI文件声明
SPI扩展文件存储在以下三个路径
dubbo支持的各种扩展实现都存储在第一个目录中了，但是dubbo在加载插件时仍然会扫描这三个目录。在每个spi文件中，格式定义为：扩展名=扩展实现类路径。如下：
spi文件名称格式：接口的全路径名称，如下：
com.alibaba.dubbo.rpc.cluster.LoadBalance
Protocol加载过程
下面以Protocol为实例，具体分析下dubbo加载Protocol实例的过程
Protocol protocol = ExtensionLoader.getExtensionLoader(Protocol.class).getAdaptiveExtension();
看下com.alibaba.dubbo.rpc.Protocol这个接口声明，发现了两个注解@SPI、@Adaptive。
1、@SPI: 指定接口的默认实现策略名称，这里LoadBalance默认的实现策略是RandomLoadBalance 2、@Adaptive: 可以标记在SPI扩展实现类上，也可以标记在SPI接口的方法上。如果标记在扩展类上，SPI获取的实例是Adaptive+接口名称.class,如AdaptiveExtensionFactory、AdaptiveCompiler；如果标记在接口方法上，SPI对应的实例是动态代理类, 如LoadBalance$Adpative.class。
ExtensionLoader初始化
在getExtensionLoader的过程中，这里使用单例的模式，每个加载的type类型返回一个new ExtensionLoader(type)实例。看一下这个构造函数：
private ExtensionLoader(Class<?> type) {
this.type = type;
objectFactory = (type == ExtensionFactory.class ? null :
ExtensionLoader.getExtensionLoader(ExtensionFactory.class).getAdaptiveExtension());
}
objectFactory这个对象工厂是用于加载Protocol实例中的成员变量，例如RegistryProtocol实例中的cluster、protocol、registryFactory等，如果type类型等于ExtensionFactory则返回空，具体加载过程下文中会说到。另外，注意ExtensionFactory这个扩展工厂接口，就是上文说到的@Adaptive标记在扩展实现类上的，默认返回实例AdaptiveExtensionFactory。
getAdaptiveExtension()
这里获取一个Protocol接口的实现，由于Protocol接口中的@Adaptive注解是标记在方法上的，所有这里应该返回一个Protocol$Adpative.class的动态实例，具体过程如下：
private T createAdaptiveExtension() {
try {
return injectExtension((T) getAdaptiveExtensionClass().newInstance());
} catch (Exception e) {
throw new IllegalStateException("Can not create adaptive extenstion " + type + ", cause: " + e.getMessage(), e);
}
}
getAdaptiveExtensionClass().newInstance()返回Protocol$Adpative.class的动态实例。注意下injectExtension这个函数，用上文说到的objectFactory对象工厂，在入参Protocol$Adpative.class的情况时，objectFactory并不会working，因为没有set开头的method。接下来我们看下Protocol$Adpative.class的创建过程，揭开Protocol$Adpative.class的神秘面纱。
# getAdaptiveExtensionClass()
private Class<?> getAdaptiveExtensionClass() {
getExtensionClasses();
if (cachedAdaptiveClass != null) {
return cachedAdaptiveClass;
}
return cachedAdaptiveClass = createAdaptiveExtensionClass();
}
1、首先getExtensionClasses(),顾名思义是加载所有的扩展类。翻代码跟进去loadFile函数，就是遍历上文说到的SPI扩展文件存储的三个路径，利用class.forName将文件中的扩展类加载到内存中，并以缓存起来。在加载的过程中，会判断当前class是否有标记在类上的@Adaptive注解，如果有赋值给cachedAdaptiveClass
if (clazz.isAnnotationPresent(Adaptive.class)) {
if(cachedAdaptiveClass == null) {
cachedAdaptiveClass = clazz;
} else if (! cachedAdaptiveClass.equals(clazz)) {
throw new IllegalStateException("More than 1 adaptive class found: "
+ cachedAdaptiveClass.getClass().getName()
+ ", " + clazz.getClass().getName());
}
}
这里要强调下的是，大家是不还记得前文提到的dubbo之所以没有采用jdk标准的spi，而是自己重写了。只有在用到的时候才去加载扩展资源类。
2、能走进这个if分支的，应该是@Adaptive注解标记在扩展类上的，目前有AdaptiveCompiler、AdaptiveExtensionFactory等，Protocol接口没有@Adaptive注解标记在扩展类上的实现。
if (cachedAdaptiveClass != null) {
return cachedAdaptiveClass;
}
3、 createAdaptiveExtensionClass()动态创建Protocol$Adpative.class实例
private Class<?> createAdaptiveExtensionClass() {
String code = createAdaptiveExtensionClassCode();
ClassLoader classLoader = findClassLoader();
com.alibaba.dubbo.common.compiler.Compiler compiler = ExtensionLoader.getExtensionLoader(com.alibaba.dubbo.common.compiler.Compiler.class).getAdaptiveExtension();
return compiler.compile(code, classLoader);
}
分析第一行代码createAdaptiveExtensionClassCode(),这个函数很长有200多行，大家读到这里不要慌，函数的目的很简单，就是字符串拼接，并且校验Protocol接口中是否有标记在method上的@Adaptive注解。如果没有则抛出异常。拼接的结果如下：
这个就是Protocol$Adpative代理类的样子，这么拼接好处是性能很高，缺点是拼接过程很繁琐。接下来的编译过程，dubbo默认交给了javassist来完成。这样就完成了在当前classloader中创建一个Protocol$Adpative的动态代理类。
Protocol实例调用
在完成Protocol$Adpative的动态代理类在classloader中的创建后，我们看下这个代理类是如何完成具体接口调用的。例如：
Exporter<?> exporter = protocol.export(invoker);
这里看下上文Protocol$Adpative中的export函数，通过url参数中的getProtocol()方法，给extName变量赋值，extName默认等于dubbo。然后再次调用ExtensionLoader中的getExtension方法，返回具体的Protocol接口实现类。介绍下这里的extName变量，其实就是spi配置文件中的key。extName默认等于dubbo，那么Protocol接口默认的实现就是DubboProtocol。
