什么是SPI
SPI(Service Provider Interface),服务发现机制，在JDK中，它通过在ClassPath路径下的META-INF/services文件夹查找文件，自动加载文件里所定义的类。
作用
SPI 是一种将服务接口与服务实现分离以达到解耦、大大提升了程序可扩展性的机制。引入服务提供者就是引入了 spi 接口的实现者，通过本地的注册发现获取到具体的实现类，轻松可插拔。
JAVA SPI
在JDK中是支持SPI机制的，新建了一个Car接口，BlackCar类和RedCar类均实现Car接口
META-INF资源文件配置了两个实现类
SPI调用代码
ServiceLoader<Car> cars = ServiceLoader.load(Car.class);
Iterator<Car> iterator = cars.iterator();
while (iterator.hasNext()){
Car car = iterator.next();
car.sayHell();
}
结果打印，从结果可以看出，两个配置的实现类均被实例化了，这就是JAVA 中的SPI机制，根据配置随时插拔
Connected to the target VM, address: '127.0.0.1:51418', transport: 'socket'
redcar sayhell
blackcar sayhell
JAVA SPI应用
JAVA SPI在jdbc中有体现，如jdbc支持连接oracle、mysql等数据源连接，例如mysql厂商就提供了一个mysql的连接包，在META-INF/services下有一个java.sql.Driver的配置文件， 里面配置了com.mysql.jdbc.Driver驱动，这样运用SPI机制，就可以进行驱动的实例化，可以进行灵活切换，比如切换oracle，oracle厂商应该也是按照此规范来提供驱动包的
JAVA SPI缺点
从上图测试结果看出，JAVA SPI会将配置文件中配置的所有实现类都实例化，这显然可以更优化，比如有100个实现类，我在用的时候只想取其中的一个，JAVA SPI需要遍历这100的实例才能拿到我们想要的，在dubbo中，有很多组件是需要抽象成接口，比如协议组件，支持多种协议如dubbo、http，经常需要使用到这些实例，为了更加方便和性能更高，dubbo的SPI机制就应运而生，说到底dubbo的SPI机制也是对bean的管理升华的一种体现
dubbo SPI基础应用
dubbo SPI比JAVA SPI更加灵活，性能更高，首先看看他的使用，基本类还是和上面的一样，只是多了一个配置文件，META-INF/dubbo/com.mo.Car，配置了两个实现类。
调用：从这里看出，我只想只用blackCar,在参数中指定black即可，这样就可以拿到我们想要的对象
ExtensionLoader<Car> extensionLoader = ExtensionLoader.getExtensionLoader(Car.class);
Car c = extensionLoader.getExtension("black");
c.sayHell();
调用结果
blackcar sayhell
dubbo SPI在dubbo源码中的应用
JAVA SPI高级应用-自动注入和代理
上面只是SPI机制的一个helloWorld接口，假设有这样一个应用场景，有一个Person接口，BlackPerson实现了Person接口，并且BlackPerson持有Car接口，还有一个CarWrapper的Car包装类，作用后面再说
特殊点：
这里和上面有些不同，因为在Person类中持有了一个Car接口，但是car具体是哪个对象，我们现在是不知道的，是需要调用者指名我们才知道，所有我们先在car中加了@SPI注解，在getCarName方法上加了一个@Adaptive加了一个代理、适配的注解，参数也有所不同，有一个URL的参数，这个参数是dubbo spi规范定义的，如果没有后面调用会报错。
@SPI
public interface Car {
@Adaptive
String getCarName(URL url);
String sayHell();
}
public class BlackCar implements Car {
@Override
public String getCarName(URL url) {
return "black";
}
@Override
public String sayHell() {
return null;
}
}
public class BlackPerson implements Person {
private Car car; // Adaptive(代理)
public void setCar(Car car) {
this.car = car;
}
@Override
public Car getCar() {
return car;
}
}
public class CarWrapper implements Car {
private Car car;
public CarWrapper(Car car) {
this.car = car;
}
@Override
public String getCarName(URL url) {
System.out.println("wrapper...");
return car.getCarName(url);
}
@Override
public String sayHell() {
return null;
}
}
配置文件，注意这里最后一行，多了一个CarWrapper，并且没有等号前面的key。
red=com.mo.RedCar
black=com.mo.BlackCar
com.mo.CarWrapper
调用方式1:这里在getExtension传入了black参数，表示希望得到一个BlackPerson对象，后面传入了一个URL，参数是black，表示调用者希望BlackPerson中持有的car接口实现类为BlackCar，然后调用了car.getCarName方法
ExtensionLoader<Person> extensionLoader = ExtensionLoader.getExtensionLoader(Person.class);
Person person = extensionLoader.getExtension("black"); // BlackPerson
URL url = new URL("x", "localhost", 8080);
url = url.addParameter("car", "black");
Car car = person.getCar();
String carName = car.getCarName(url);
System.out.println(carName); //
调用结果1：
wrapper...
black
从结果看出，可以得出以下结论：
1.car被实例化了，并且我们在整个过程中是没有进行car=new BlackCar()，SPI内部帮我们实现了blackCar的实例化，这里就是上面说的依赖注入
2.getCarName方法最终调用了CarWrapper的getCarName方法，这里就是上面说的代理对象，有点像AOP
原理实现下节会进行源码分析
总结
1.SPI机制说到底就是对bean更加灵活的管理，调用者能随时插板对象
2.dubbo spi中实现了类似spring中bean的依赖注入和AOP功能。
