目录：
关于 Java SPI
实现 Java SPI 需要遵循的标准
Java SPI 的实际应用
Java SPI 的缺点
实现 Dubbo SPI 需要遵循的标准
Dubbo SPI小例子--自定义协议
Dubbo 的扩展点原理
Dubbo 的扩展点分类
关于 Java SPI
了解 Dubbo 里面的 SPI 机制之前，我们先了解下 Java 提供的 SPI（service provider interface）机制，SPI 是 JDK 内置的一种服务提供发现机制。目前市面上有很多框架都是用它来做服务的扩展发现。简单来说，它是一种动态替换发现的机制。举个简单的例子，我们想在运行时动态给它添加实现，你只需要添加一个实现，然后把新的实现描述给 JDK 知道就行了。大家耳熟能详的如 JDBC、日志框架都有用到。
实现 Java SPI 需要遵循的标准
我们如何去实现一个标准的 SPI 发现机制呢？其实很简单，只需要满足以下提交就行了
- 需要在 classpath 下创建一个目录，该目录命名必须是：META-INF/service
- 在该目录下创建一个 properties 文件，该文件需要满足以下几个条件
2.1 文件名必须是扩展的接口的全路径名称
2.2 文件内部描述的是该扩展接口的所有实现类
2.3 文件的编码格式是 UTF-8 - 通过 java.util.ServiceLoader 的加载机制来发现
Java SPI 的实际应用
例：JDBC驱动，jdk提供了java.sql.Driver接口，没有提供实现，实现由数据库厂商实现，如mysql、oracle
(1)定义api：
public interface DataBaseDriver{
String connect(String host);
}
(2)定义实现：
public class MysqlDriver implements DataBaseDriver {
@Override
public String connect(String s) {
return "mysql connection";
}
}
(3)在应用中依赖
<dependency>
<groupId>com.itcast</groupId>
<artifactId>DataBaseDriver</artifactId>
<version>1.0-SNAPSHOT</version>
</dependency>
<dependency>
<groupId>com.itcast</groupId>
<artifactId>MysqlDriver</artifactId>
<version>1.0-SNAPSHOT</version>
</dependency>
public class DataBaseConnection {
public static void main(String[] args) {
ServiceLoader<DataBaseDriver> load = ServiceLoader.load(DataBaseDriver.class);
for (DataBaseDriver driver : load){
System.out.println(driver.connect("locahost"));
}
}
}
Java SPI 的缺点
- JDK 标准的 SPI 会一次性加载实例化扩展点的所有实现，什么意思呢？就是如果你在 META-INF/service 下的文件里面加了 N个实现类，那么 JDK 启动的时候都会一次性全部加载。那么如果有的扩展点实现初始化很耗时或者如果有些实现类并没有用到，那么会很浪费资源
- 如果扩展点加载失败，会导致调用方报错，而且这个错误很难定位到是这个原因
实现 Dubbo SPI 需要遵循的标准
- 需要在 resource 目录下配置 META-INF/dubbo 或者 META-INF/dubbo/internal 或者 META-INF/services，并基于 SPI 接口去创建一个文件
- 文件名称和接口名称保持一致，文件内容和 SPI 有差异，内容是 KEY 对应 Value
Dubbo 针对的扩展点非常多，可以针对协议、拦截、集群、路由、负载均衡、序列化、容器… 几乎里面用到的所有功能，都可以实现自己的扩展，我觉得这个是 dubbo 比较强大的一点。
Dubbo SPI小例子--自定义协议
-
创建如下结构，添加 META-INF.dubbo 文件。类名和 Dubbo 提供的协议扩展点接口保持一致
image.png -
创建 MyProtocol 协议类
可以实现自己的协议，我们为了模拟协议产生了作用，修改一个端口
image.png - 在调用处执行如下代码
Protocol protocol=ExtensionLoader.getExtensionLoader(Protocol.class).getExtension("myProtocol");
System.out.print(protocol.getDefaultPort) - 输出结果，可以看到运行结果，是执行的自定义的协议扩展点。
总结：总的来说，思路和 SPI 是差不多。都是基于约定的路径下制定配置文件。目的，通过配置的方式轻松实现功能的扩展。
Dubbo 的扩展点原理
Protocol protocol=ExtensionLoader.getExtensionLoader(Protocol.class).getExtension("myProtocol");
1.解析配置文件
2.创建实例放入map，key=name(对应 protocol 文件中配置的 myprotocol), value=对
应配置的类的实例
3.依赖注入，如果被加载的实例中，有成员属性本身也是一个扩展点，则会通过 set 方法进行注入。
扩展点的分类
1.静态扩展点
Protocol protocol=ExtensionLoader.getExtensionLoader(Protocol.class).getExtension("myProtocol");
通过getExtension()方法，直接传参数(如myProtocol)，获得需要的扩展点
2.自适应扩展点
Protocol protocol =ExtensionLoader.getExtensionLoader(Protocol.class).getAdaptiveExtension();
注解@Adaptive：自适应扩展点的标识，它可以修饰在类上，也可以修饰在方法上面。这两者有什么区别呢？
简单来说，放在类上，说明当前类是一个确定的自适应扩展点的类。如果是放在方法级别，那么需要生成一个动态字节码，来进行转发。
比如拿 Protocol 这个接口来说，它里面定义了 export 和 refer 两个抽象方法，这两个方法分别带有@Adaptive 的标识，标识是一个自适应方法。
我们知道 Protocol 是一个通信协议的接口，具体有多种实现，那么这个时候选择哪一种呢？ 取决于我们在使用 dubbo 的时候所配置的协议名称。而这里的方法层面的 Adaptive 就决定了当前这个方法会采用何种协议来发布服务。
Protocol扩展点的获得过程：
1.动态生成一个代理类 Protocol$Adaptive
2.默认加载的是扩展点接口的@SPI 注解对应的名字
3.若配置文件中配置了协议名，则加载配置的协议
图形理解
简单来说，上面的基于方法层面的@Adaptive，基本实现原理的图形大概是这样
3.自动激活扩展点
自动激活扩展点，有点类似我们讲 springboot 的时候用到的 conditional，根据条件进行自动激活。但是这里设计的初衷是，对于一个类会加载多个扩展点的实现，这个时候可以通过自动激活扩展点进行动态加载， 从而简化配置我们的配置工@Activate 提供了一些配置来允许我们配置加载条件，比如 group 过滤，比如 key 过滤。
举个例子，我们可以看看 org.apache.dubbo.Filter 这个类，它有非常多的实现，比如说 CacheFilter，这个缓存过滤器，配置信息如下
group 表示客户端和和服务端都会加载，value 表示 url 中有 cache_key 的时候
@Activate(group = {CONSUMER, PROVIDER}, value = CACHE_KEY)
public class CacheFilter implements Filter {
通过下面这段代码，演示关于 Filter 的自动激活扩展点的效果。没有添加“红色部分的代码”时，list 的结果是 10，添加之后 list
的结果是 11. 会自动把 cacheFilter 加载进来
public static void main(String[] args) {
ExtensionLoader<Filter> loader=ExtensionLoader.getExtensionLoader(Filter.class);
URL url=new URL("","",0);
// url=url.addParameter("cache","cache"); 有和没有的区别
List<Filter> filters=loader.getActivateExtension(url,"cache");
System.out.println(filters.size());
}
