本文将介绍两种方式来实现功能插件化：
- Java SPI
- Spring factories
在整个插件化的方案中，会涉及到如下 3 个组成部分：
-
插件定义（即将插件定义为一个接口）
-
插件实现（即对插件接口的实现）
这里对同一个插件定义，有两个不同的实现，即 2 个插件：cab5-charging-policy-general 和 cab5-charging-policy-vip，实现了不同的扣款策略。 -
支持插件插拔的平台（因为不知道叫啥，姑且先叫「主项目」吧）
1、Java SPI
SPI 全称 Service Provider Interface，中文译为「服务提供者接口」，JDK 提供的一种服务发现机制，即为某个接口寻找具体的实现。
让我们结合开篇提到的插件化方案所涉及 3 个组成部分，来说明下如何用 SPI 来实现插件化。
-
我们要将插件化的功能用接口来进行定义，并接口打成一个 jar 包。
-
实现【步骤1】中定义的接口，并将该实现打成一个 jar 包。此时插件就已包装完成，下一步就是「主项目」引入该 jar 包（即插件）。
这里有一个问题：
随便一个 jar 包就能成为一个插件吗？
答案当然是否定的。那问题又来了：
是通过什么来标识 jar 包是一个插件的呢？
我们需要在该 jar 包中 META-INF 目录下创建 services 子目录，同时，在该子目录下创建一个以接口（插件定义中的接口）名为文件名的文件，且文件中的内容为接口实现类的全限定名，如下：
-
主项目引入插件并使用插件
首先我们在「主项目」中需要引入「插件定义」以及相关的「插件实现（即插件）」，如下：
最后我们再来说下，如何在「主项目」中使用插件，如下图：
从图中我们可以看到，Java SPI 通过 java.util.ServiceLoader 将插件接口（即 cab5-charging-policy jar 中的 CharginigPolicyPluging）的实现类全部（即 cab5-charging-policy-general jar 中的 ChargingPolicyGeneral 和 cab5-charging-policy-vip jar 中的 ChargingPolicyVip）加载，并通过该类的 iterator 方法将实现插件接口（即 cab5-charging-policy jar 中的 CharginigPolicyPluging）的插件进行遍历（也就是分别调用了 cab5-charging-policy-general jar 中的 ChargingPolicyGeneral 和 cab5-charging-policy-vip jar 中的 ChargingPolicyVip 的 charging 方法）。
这里又有一个问题：ServiceLoader 是如何找到「插件接口」的实现类的呢？
ServiceLoader 通过扫描「插件实现」的 jar 包中 META-INF/services 目录下的文件，从而得知接口与实现的对应关系，进而找到了接口的所有实现类。
2、Spring factories
Spring factories 是 Spring Boot 一种解耦的扩展机制，它仿照了 Java 的 SPI。采用 Spring factories 来实现功能插件化的过程与 Java SPI 非常类似。主要有以下 2 点不同：
-
将 jar 包标识为插件的方式不同
Spring factories 需要我们在该 jar 包中的 META-INF 目录下创建 spring.factories 文件，文件内容为：接口=实现类的全限定名，如下：
-
「主项目」加载使用插件的方式不同
我们需要使用 spring-core 包里的 org.springframework.core.io.support.SpringFactoriesLoader 来加载插件，如下图：
与 SPI 一样，这里也进一步说明下 SpringFactoriesLoader 是如何找到「插件接口」的实现类的：factories 是通过扫描「插件实现」的 jar 包中 META-INF/spring.factories 文件，从而得知接口与实现的对应关系，进而找到了接口的所有实现类。
3、示例代码
本文的上方有提供对应的示例代码。
