也就是说，SPI是JDK的构建 - 服务发现机制，可用于启用框架扩展和替换组件。它可以使不同的制造商在统一接口上编写不同的实现
SPI实际上是“接口+策略模式+配置文件”的动态加载机制。在系统设计中，该模块通常基于接口编程，并且未直接显示指定的实现类。代码，不能在不修改代码的情况下将其替换为其他实现。为了实现动态插入的效果，Java提供了SPI来实现服务发现。
SPI机制有许多应用程序场景。我们更常用于JDBC，Dubbo等。
在谈论Dubbo的SPI机制之前，我们需要了解Java本机SPI机制
文件中的内容是实现类的完整限制名称
可以通过测试代码看到我们已成功的两个类别已成功加载并运行相关方法。但是我们没有创建代码中显示的实现类，我们可以立即通过该形式实例化我们想要的对象。插件-in配置文件.deciplab程序将程序的决定在配置文件中
但是Java的本地SPI也有其缺点：
为了响应上述缺陷，我们可以选择Dubbo的SPI机制来避免不足
Dubbo没有使用Java SPI，而是重新实现了一个更有功能的SPI机制。Dubbo SPI的相关逻辑被封装在ExtensionLoader类中。通过ExtensionLoader，我们可以加载指定的实现类。
此外，Dubbo是由钥匙值对配置的，我们可以直接获得要通过key加载的实体类。Dubbo的默认配置文件路径降低了
写测试方法：
更改配置文件
运行测试：
从代码可以看出，Dubbo的SPI机制可以直接通过键获得我们想要的对象实例，这比本机Java SPI更有利。此外，Dubbo还在设计中使用了大量的全局缓存，从而改善了我们的实例。同时，对象的效率也支持诸如默认实现，AOP，IOC和其他功能之类的功能
以下是模仿Dubbo的源代码的SPI机制的代码，该代码来自指南的开源RPC项目。尽管与源代码存在一些差异，但Dubbo没有函数，但核心想法仍然是相同
从上面可以看出，必须根据注释来实现Dubbo的SPI机制，以在接口上进行标记，因此我们首先自定义注释以标记要扩展的接口。
顾名思义，持有人是一个对象，该对象容纳了由Extensionloader加载的实例化对象
Dubbo SPI机制的核心类别使用它来从文件中读取配置，并通过反射实例化对象