一、SPI机制：

SPI 全称为 Service Provider Interface，是一种服务发现机制。SPI 的本质是将接口实现类的全限定名配置在文件中，并由服务加载器读取配置文件，加载实现类。这样可以在运行时，动态为接口替换实现类。正因此特性，我们可以很容易的通过 SPI 机制为我们的程序提供拓展功能。SPI 机制在第三方框架中也有所应用，比如 Dubbo 就是通过 SPI 机制加载所有的组件。不过，Dubbo 并未使用 Java 原生的 SPI 机制，而是对其进行了增强，使其能够更好的满足需求。在 Dubbo 中，SPI 是一个非常重要的模块。基于 SPI，我们可以很容易的对 Dubbo 进行拓展。如果大家想要学习 Dubbo 的源码，SPI 机制务必弄懂。

package com.example;

public interface Spi {

    boolean isSupport(String name);

    String sayHello();

}

ServiceLoader 会遍历所有 jar 查找 META-INF/services/com.example.Spi 文件

A 厂商提供实现

package com.a.example;

public class SpiAImpl implements Spi {

    public boolean isSupport(String name) {

    return "SPIA".equalsIgnoreCase(name.trim());

}

public String syaHello() {

    return “hello 我是厂商 A”;

}

} 

A 厂商提供的 jar 包中的 META-INF/services/com.example.Spi 文件内容为：

com.a.example.SpiAImpl #厂商 A 的 spi 实现全路径类名

B 厂商提供实现

package com.b.example;

public class SpiBImpl implements Spi {

    public boolean isSupport(String name) {

    return "SPIB".equalsIgnoreCase(name.trim());

} 

public String syaHello() {

    return “hello 我是厂商 B”;

}

} 

B 厂商提供的 jar 包中的 META-INF/services/com.example.Spi 文件内容为：

com.b.example.SpiBImpl #厂商 B 的 spi 实现全路径类名

ServiceLoader.load(Spi.class) 读 取 厂 商 A 、 B 提 供 jar 包 中 的 文 件 ，ServiceLoader 实现了 Iterable 接口可通过 while for 循环语句遍历出所有实现。

一个接口多种实现，就如策略模式一样提供了策略的实现，但是没有提供策略的选择， 使用方可以根据 isSupport 方法根据业务传入厂商名来选择具体的厂商。

public class SpiFactory {

    //读取配置获取所有实现

    private static ServiceLoader spiLoader = ServiceLoader.load(Spi.class);

    //根据名字选取对应实现

    public static Spi getSpi(String name) {

        for (Spi spi : spiLoader) {

            if (spi.isSupport(name) ) {

                return spi;

            }

        }

    return null;

}}

二、dubbo实现的SPI机制：

1.标记哪些接口支持SPI 机制：Dubbo 提供一个注解 ，通过该注解标记的接口支持SPI功能。

2.SPI接口实现类的信息从哪里读取？

3.SPI接口实现类加载流程：

1、首选获取SPI接口的ExtensionLoader 类，每个接口会缓存ExtensionLoader 类，ExtensionLoader 类相当于ServiceLoader 

2.通过ExtensionLoader 类加载接口的实现类

a) 先读取 SPI 注解的 value 值，有值作为默认扩展实现的 key

b) 依次读取路径的文件

    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

逐行读取对应的实现类并通过反射构造实现类。

4.SPI接口实现类加载好了，n个实现类用那个?

dubbo 提供SPI 接口的决策类：适配器类。

为什么要创建设配类，一个接口多种实现， SPI 机制也是如此，这是策略模式，但是我们在代码执行过程中选择哪种具体的策略呢。 Dubbo 采用统一数据模式 com.alibaba.dubbo.common.URL( 它是 dubbo 定义的数据模型不是 jdk 的类)，它会穿插于系统的整个执行过程， URL 中定义的协 议 类 型 字 段 protocol ， 会 根 据 具 体 业 务 设 置 不 同 的 协 议 。url.getProtocol()值可以是 dubbo 也是可以 webservice， 可以是zookeeper 也可以是 redis。

dubbo有两种适配类的实现方式：

1、静态@Adaptive

2、动态生成适配器代码：

获取对应的策略适配器类：

1） 生成 Adaptive 代码 code

2） 利用 dubbo 的 spi 扩展机制获取 compiler 的设配类

3） 编译生成的 adaptive 代码

策略适配器类决策逻辑：更加URL 信息

SPI实现类依赖其他类怎么办？IOC

IOC 大 家 所 熟 知 的 ioc 是 spring 的 三 大 基 础 功 能 之 一 ， dubbo 的ExtensionLoader 在加载扩展实现的时候内部实现了个简单的 ioc 机制来实现对扩展实现所依赖的参数的注入， dubbo 对扩展实现中公有的 set 方法且入参个数为一个的方法，尝试从对象工厂 ObjectFactory 获取值注入到扩展点实现中去。

1、Dubbo的容器工厂是怎样的？

dubbo 的容器工厂也是采用SPI 支持扩展。

它 跟 Compiler 接 口 一 样 设 配 类 注 解 @Adaptive 是 打 在 类AdaptiveExtensionFactory 上的不是通过 javassist 编译生成的。AdaptiveExtensionFactory 持有所有 ExtensionFactory 对象的集合， dubbo内 部 默 认 实 现 的 对 象 工 厂 是SpiExtensionFactory 和SpringExtensionFactory，他们经过 TreeMap 排好序的查找顺序是优先先从SpiExtensionFactory 获取，如果返回空在从 SpringExtensionFactory 获取。

工厂适配器类：

静态适配器类查找容器的SPI实现放入List<ExtensionFactory> factories

1） SpiExtensionFactory 工厂获取要被注入的对象，就是要获取 dubbo spi扩展的实现，所以传入的参数类型必须是接口类型并且接口上打上了@SPI 注解，返回的是一个设配类对象。

2） SpringExtensionFactory， Dubbo 利用 spring 的扩展机制跟 spring 做了很好的融合。在发布或者去引用一个服务的时候，会把 spring 的容器添加到 SpringExtensionFactory 工厂集合中去， 当 SpiExtensionFactory没有获取到对象的时候会遍历SpringExtensionFactory 中的 spring 容器来获取要注入的对象