dubbo源码解读——SPI机制
先来了解一下java中的spi机制
jdk中的spi
SPI简介
一种策略模式，通过在META-INF/services/包下定义接口命名的文件，来决定使用哪个实现
调用过程
public class Main {
public static void main(String[] args) {
System.out.println("---加载接口--");
ServiceLoader<SpiService> serviceLoader = ServiceLoader.load(Log.class);
Iterator<SpiService > iterator = serviceLoader.iterator();
//上面只声明了两个接口，所以这里会分别调用rmi和rest的实现类的sayhello方法
while (iterator.hasNext()) {
SpiService s1= iterator.next();
s1.sayHello
}
System.out.println("---运行结束---");
}
}
spi 全称为(Service Provider Interface),是JDK内置的一种服务提供机制。
这个是针对厂商或者插件的。
一般来说对于未知的实现或者对扩展开放的系统，通常会把一些东西抽象出来，抽象的各个模块往往有很多不同的实现方案,例如：日志模块、xml解析模块、jdbc模块等。
SPI约定
当服务的提供者，提供了服务接口的一种实现之后，在jar包中META-INF/services目录里同时创建一个以服务接口命名的文件。
该文件里就是实现该服务接口的具体实现类（全称）。
而当外部程序装配这个模块的时候，就能通过该jar包META-INF/services/里的配置文件找到具体的实现类名，并装载实例化，完成模块的注入。
在日志实现中可以使用
dubbo中的spi实现
dubbo中的spi实现更加人性化，可以支持自定义标签中的指定属性决定实现类的读取
比如这个如在均衡的策略
dubbo中的api的使用流程
凡是dubbo中， 接口上有 @SPI标注的，都表明此接口支持扩展，能以标签中属性的方式进行配置扩展
类似这个负载的接口
@SPI("random")
public interface LoadBalance {
@Adaptive({
"loadbalance"})
<T> Invoker<T> select(List<Invoker<T>> var1, URL var2, Invocation var3) throws RpcException;
}
下面我们自己来写一个负载的扩展类
1、引入jar依赖
<dependency>
<groupId>com.alibabagroupId>
<artifactId>dubboartifactId>
<version>2.5.7version>
<scope>providedscope>
dependency>
2、编写实现类
3、resource下新建类全路径名文件，为每个实现分配一个key
4、在消费端，便可使用上面步骤中定的实现策略（以key指代）
dubbo中SPI机制源码解读
在运行的时候会通过一个叫做ExtensionLoader的加载器来进行dubbo的扩展点加载
拿消费端的Reference标签举例，
通过看dubbo解析自定义标签的源码
this.registerBeanDefinitionParser("reference", new DubboBeanDefinitionParser(ReferenceBean.class, false));
我们知道dubbo是将reference标签的内容封装到ReferenceBean里的，打开ReferenceBean
public class ReferenceBean<T> extends ReferenceConfig<T> implements FactoryBean, ApplicationContextAware, InitializingBean, DisposableBean {
}
打开父类ReferenceConfig，可以看到创建代理对象时的这一句核心代码
this.invoker = refprotocol.refer(this.interfaceClass, (URL)this.urls.get(0));
而这个refprotocol则是个ReferenceConfig的静态变量
（也许您会好奇，每一个reference标签对应一个ReferenceConfig对象，那在这里的协议使用类变量，会不会导致每个对象只有一个协议呢？这里就牵扯到dubbo的ExtensionLoader加载器了）
//getExtensionLoader获取加载器 getAdaptiveExtension获取代理类
private static final Protocol refprotocol = (Protocol)ExtensionLoader.getExtensionLoader(Protocol.class).getAdaptiveExtension();
getExtensionLoader(Protocol.class)为protocol接口生成一个加载器
getAdaptiveExtension()，使用加载器生成一个代理对象---- protocol接口对象
代理对象执行时，根据参数（扩展名extName）选择实际对象
最后的效果：
每个接口扩展点----- 对应一个ExtensionLoader加载器，内部是一个currenthashmap 如：
protocol -------------- ExtensionLoader实例< protocol>
filter -------------- ExtensionLoader实例< filter >
loadbalance -------------- ExtensionLoader实例< loadbalance >
代理对象是实时生成的，包括class文件，当然只生成接口中有@Adaptive注解的方法
a、dubbo启动加载实现类时，以 key-实例 方式map缓存各个实现类
b、实际调用时，通过key --取实现需要那个实现
c、调用的发生，由生成的代理对象的来发起，最终是从URL总线中，找出extName值，
extName做为key，在缓存map中取出正确的实现实现类