面向接口编程的设计中，我们在使用一个service时，通常是从接口的层面来使用，通俗的说，即声明service实例时使用接口名来声明，而非使用具体实现。这么做的原因是我们的代码不会依赖具体实现（依赖的是接口），后期具体实现的修改或者替换，对既有代码的影响相对比较小,如果是使用Spring IOC来注入，基本上不需要修改调用方的代码；如果调用方是new ServiceImpl()的方式引入对象，只修改这一行即可创建为新的实现类即可。好处不言而喻。
如果我们的project因为某些变更，需要替换掉某个外部的jar包，该怎么约束这个变更来减少影响呢。
因为面向接口编程的原则如此重要，所以在引用外部jar的service，一样也采用了这个原则。通过接口的约束，我们同样能够在替换jar的时候，只需要变动很少的代码来拥抱变化。继续使用容器的依赖注入帮我们注入实现类，或者手动修改service的创建逻辑。但是这样，似乎并不优雅。
于是有了SPI的机制，即service provider interface。这个不是什么新鲜的东西，只是面向接口编程的一个约束，主要用在module之间（比如jar的引用），它通过读配置文件来获取某个接口的实现类，然后使用。说白了就是通过一个配置文件来解耦接口和具体实现（无论是jar之间的接口--实现还是jar内部的接口--实现，都可以通过这个方式解耦）。透明地实现的具体实现的切换，达到插件的效果，即插即用，不插没有。
看一下SPI的使用规范。
- 配置文件：在实现类所在module的根目录（classpath）下面的
META-INF/services目录下，创建一个文件，以接口全限定类名作为文件名，接口实现类的全限定类名作为文件的内容，每个实现类名占一行，注意文件编码必须是UTF-8。 - 查找逻辑：使用jdk的
ServiceLoader.load(xxx.class)方法查找对应接口的provider实现。注意这个查找是可以跨jar包的。
SPI的常见使用有：
- 数据库驱动加载
- 日志门面实现类的选用
- Spring MVC利用Servlet 3.0的SPI机制启动容器，参考这篇
SPI示例
module结构
三个module，一个接口门面searchfacede，一个provider实现simplesearch，还有一个是调用方spidemo。
- searchfacede,此module中只有一个接口
demo.spi.facede.SearchService - simplesearch,此module依赖searchfacede，并且提供了实现类，定义了spi配置文件
- spidemo，依赖上面两个module，提供SPI查找SearchService的实现，并使用。
- searchfacede中
public interface SearchService {
String search(String name);
}
- simplesearch中
import demo.spi.facede.SearchService;
public class SimpleSearchService implements SearchService{
@Override
public String search(String name) {
return name + " from " + this.getClass().getSimpleName();
}
}
SPI配置文件：maven工程结构下
文件：resources/META-INF/services/demo.spi.facede.SearchService
内容：spi.provider.SimpleSearchService
- spidemo
import demo.spi.facede.SearchService;
public class Main {
public static void main(String[] args) {
ServiceLoader<SearchService> serviceServiceLoader = ServiceLoader.load(SearchService.class);
for (Iterator<SearchService> iterator = serviceServiceLoader.iterator(); iterator.hasNext(); ) {
SearchService next = iterator.next();
System.out.println(next);
System.out.println(next.search("a"));
}
}
}
