为什么要使用Java SPI机制
Java SPI（Service Provider Interface）最早是在Java SE 6中被引入的，作为一种标准的、用于在运行时发现和加载服务提供者插件的标准机制。以前的程序猿实现JDBC连接数据库都会自己写工具类加载不同厂商的驱动来实现数据库操作，但是随着JDBC4.0之后采用了Java SPI机制，这部分工作就变的轻松了，程序猿甚至不需要Driver的具体实现是什么，路径在哪里，会自动注册，直接使用即可。随着Java的版本升级，SPI机制的实现方式也有着一些变化，比如Java9开始，SPI的配置文件可以写在module-info.java文件中，但是之前的META-INF/services/目录下的仍然受支持。
万变不离其宗，其核心思想，和它的出现要解决某些问题的目标始终是一致的。包括经常使用的开源框架如Spring、Dubbo、Hibernate、Nacos、SLF4J等使用SPI机制来实现框架的可扩展性和插件化能力。原理是一样的，实现上各有千秋，开源框架的实现可能考虑的更加全面，更加灵活。
Oracle文档对于JAVA SPI的相关描述以及简单的Demo：https://docs.oracle.com/javase/tutorial/ext/basics/spi.html
相关例子和Demo类，此处不提供，参透JDBC在各个厂商的实现和配置，以及Spring中spring.factories用法，就能知道SPI是如何工作、如何使用的。
- SPI不是一个框架，更不是一个具体实现，更偏向于是一种机制、规约。使用这种机制，遵循这种既定的规约，就可以提高系统的灵活性、可扩展性、模块化程度等。
- 只要按照这个规约来实现，就能提供服务自动发现的能力。
服务提供方只需要按照规范提供Metadata，SPI自动查找和加载对应的服务实现。也就是说客户端和服务端并不需要知道具体的实现累路径。比如自己在客户端使用Class.forName("cc.oo.tt.XX")来加载，那么每次是不是都要知道具体的实现的全路径名称。有了SPI就不需要知道，自动发现和加载。就像是一个策略模式的实现，不过具体的实现由扩展（三方）处理，同时按照服务规范在自己的jar中指定具体实现，而服务不需要知道。
-
采用这种机制，我们可以更灵活的按需编码不同的实现，提供额外的扩展而不需要改原有的代码，从而提升了系统的稳定性。
- 依据具体的场景，合适的时机来引入这种机制，而不是‘手里拿着锤子看什么都像钉子’，见了扩展就开始套用它。技术是为业务服务的，不是用来强行炫技的。
比如我们项目中有个模块是搜索点位信息，刚开始项目内置是采用数据库检索，后来是有很多三方也想集成进来，各自有自己的流程和处理方式，但是我们作为平台有自己标准的流程和标准的接口方式；那我们只需要讲接口定义提供给对方，让他们自己实现了接口的相关服务，并在提供给我们的jar中配置好具体实现类；我们项目中有专门扫描处理标准接口的函数，会依据不同项目加载不同的jar从而使用到三房提供的服务实现。
比如假设我门实现一个简单天气组件，目的就是查看各城市当天和未来天气，那提供天气的三方服务有很多，而实际上每次只需要一个服务可用就行，这时候就可以考虑采用Java SPI机制，将各个三方的服务按需集成，而不是全部混合到一起。
