SPI 全称为 Service Provider Interface，是一种服务发现机制。具体解释参考Dubbo官方文档的Dubbo SPI，这里面对JAVA SPI和Dubbo自己的SPI讲解非常清楚。这边谈一谈Dubbo初始化时的一些细节。
dubbo有哪些扩展类？
找到源码包中的/META-INF/dubbo/internal目录，会看到一堆SPI的配置。具体可以逐个翻开看看。
com.alibaba.dubbo.cache.CacheFactory
com.alibaba.dubbo.common.compiler.Compiler
com.alibaba.dubbo.common.extension.ExtensionFactory
com.alibaba.dubbo.common.logger.LoggerAdapter
com.alibaba.dubbo.common.serialize.Serialization
com.alibaba.dubbo.common.status.StatusChecker
com.alibaba.dubbo.common.store.DataStore
com.alibaba.dubbo.common.threadpool.ThreadPool
com.alibaba.dubbo.container.Container
com.alibaba.dubbo.monitor.MonitorFactory
com.alibaba.dubbo.qos.command.BaseCommand
com.alibaba.dubbo.registry.RegistryFactory
com.alibaba.dubbo.remoting.Codec2
com.alibaba.dubbo.remoting.Dispatcher
com.alibaba.dubbo.remoting.exchange.Exchanger
com.alibaba.dubbo.remoting.http.HttpBinder
com.alibaba.dubbo.remoting.p2p.Networker
com.alibaba.dubbo.remoting.telnet.TelnetHandler
com.alibaba.dubbo.remoting.Transporter
com.alibaba.dubbo.remoting.zookeeper.ZookeeperTransporter
com.alibaba.dubbo.rpc.cluster.Cluster
com.alibaba.dubbo.rpc.cluster.ConfiguratorFactory
com.alibaba.dubbo.rpc.cluster.LoadBalance
com.alibaba.dubbo.rpc.cluster.Merger
com.alibaba.dubbo.rpc.cluster.RouterFactory
com.alibaba.dubbo.rpc.Filter
com.alibaba.dubbo.rpc.InvokerListener
com.alibaba.dubbo.rpc.Protocol
com.alibaba.dubbo.rpc.protocol.thrift.ClassNameGenerator
com.alibaba.dubbo.rpc.ProxyFactory
com.alibaba.dubbo.validation.Validation
翻开后会发现一个奇怪的问题，每种类型的KV都配置的3遍。我也很好奇这是为啥？
ExtensionLoader对象中存储了啥？
我把ExtensionLoader类中总览性的一些代码贴出来详细说明。并且配上详细的注释。
public class ExtensionLoader<T> {
// 放置自定义扩展的配置目录
private static final String SERVICES_DIRECTORY = "META-INF/services/";
// 放置自定义扩展的配置目录
private static final String DUBBO_DIRECTORY = "META-INF/dubbo/";
// 放置内定扩展的配置目录
private static final String DUBBO_INTERNAL_DIRECTORY = DUBBO_DIRECTORY + "internal/";
// key:扩展类的抽象类型的class（接口），value:扩展类型对应的扩展类加载器
// 比如：（Protocol.class, ExtensionLoader实例）
private static final ConcurrentMap<Class<?>, ExtensionLoader<?>> EXTENSION_LOADERS = new ConcurrentHashMap<Class<?>, ExtensionLoader<?>>();
// key:扩展类的class（非接口），value:扩展类型对应的具体实例
// 比如：（RegistryProtocol.class, RegistryProtocol实例）
private static final ConcurrentMap<Class<?>, Object> EXTENSION_INSTANCES = new ConcurrentHashMap<Class<?>, Object>();
// ==============注意：上面全是静态的，所有对象共享，下面都是非静态的，对象私有================
// 扩展类的抽象类型的class（接口）
// 比如：Protocol.class
private final Class<?> type;
// 扩展类工厂，为创建的类做字段注入时，会用到。
private final ExtensionFactory objectFactory;
// key:扩展类的class（非接口），扩展类名字
// 比如：（RegistryProtocol.class, registry）
private final ConcurrentMap<Class<?>, String> cachedNames = new ConcurrentHashMap<Class<?>, String>();
// key:扩展类名字，扩展类的class（非接口）
// 比如：（registry, RegistryProtocol.class）
private final Holder<Map<String, Class<?>>> cachedClasses = new Holder<Map<String, Class<?>>>();
// 被@Activate标注的缓存
private final Map<String, Activate> cachedActivates = new ConcurrentHashMap<String, Activate>();
// key:扩展类名字，value:扩展类型对应的具体实例
// 比如：（registry, RegistryProtocol实例）
// 会发现EXTENSION_LOADERS也存储了相同的value，不同的是，EXTENSION_LOADERS是全局的，而cachedInstances是本对象的。EXTENSION_LOADERS是为了防止某个类实现了不同类型的扩展导致加载时，全局产生这个类的两个instance。
private final ConcurrentMap<String, Holder<Object>> cachedInstances = new ConcurrentHashMap<String, Holder<Object>>();
// 缓存当前这个扩展类型下，适配器类型的instance
// 比如：AdaptiveExtensionFactory,AdaptiveCompiler(只有这2个)
private final Holder<Object> cachedAdaptiveInstance = new Holder<Object>();
// 缓存当前这个扩展类型下的适配器类型
// 比如：AdaptiveExtensionFactory,AdaptiveCompiler(只有这2个)
private volatile Class<?> cachedAdaptiveClass = null;
// 缓存当前这个扩展类型的默认名字，也就是框架的默认实现
// 比如 @SPI("dubbo") public interface Protocol
private String cachedDefaultName;
// 缓存当前这个扩展类型的包装器集合类型
// 比如：ProtocolFilterWrapper
private Set<Class<?>> cachedWrapperClasses;
// 私有构造方法
// 从这边可以看出，每个ExtensionLoader都是跟type绑定的
private ExtensionLoader(Class<?> type) {
this.type = type;
// 每个ExtensionLoader实例（除了ExtensionFactory本身）都持有ExtensionFactory的委托
// 实际上是持有单例AdaptiveExtensionFactory
objectFactory = (type == ExtensionFactory.class ? null : ExtensionLoader.getExtensionLoader(ExtensionFactory.class).getAdaptiveExtension());
}
// 根据type类型来获取ExtensionLoader对象
// 如果还未加载，则new ExtensionLoader<T>(type)
public static <T> ExtensionLoader<T> getExtensionLoader(Class<T> type) {
if (type == null)
throw new IllegalArgumentException("Extension type == null");
if (!type.isInterface()) {
throw new IllegalArgumentException("Extension type(" + type + ") is not interface!");
}
if (!withExtensionAnnotation(type)) {
throw new IllegalArgumentException("Extension type(" + type +
") is not extension, because WITHOUT @" + SPI.class.getSimpleName() + " Annotation!");
}
ExtensionLoader<T> loader = (ExtensionLoader<T>) EXTENSION_LOADERS.get(type);
if (loader == null) {
EXTENSION_LOADERS.putIfAbsent(type, new ExtensionLoader<T>(type));
loader = (ExtensionLoader<T>) EXTENSION_LOADERS.get(type);
}
return loader;
}
}
从上面的代码，可以看到几个信息
1.每个可扩展SPI类型，都会对应一个ExtensionLoader实例，并且被全局缓存
2.每个ExtensionLoader实例中会缓存一些信息
① 这个SPI下面所有配置的实现类（只加载，并不初始化）
② 默认使用哪个实现类
③ 适配器类型RegistryProtocol.class, RegistryProtocol，可以参考SPI 自适应扩展
几类SPI的加载顺序
1.ExtensionFactory（扩展类工厂）
从ExtensionLoader的构造方法，可以看出各种SPI类型都会依赖ExtensionFactory
2.Compiler（编译器）
Dubbo中有很多地方需要动态生成java代码片段，就需要编译器。
3.各种普通扩展类
看下ExtensionFactory的结构
结构比较简单，值得注意的是AdaptiveExtensionFactory，看下它的实现。
@Adaptive
public class AdaptiveExtensionFactory implements ExtensionFactory {
// 持有一个ExtensionFactory类型的集合
private final List<ExtensionFactory> factories;
// 初始化的时候会加载ExtensionFactory这个SPI类型下的所有实现，并且放入集合
public AdaptiveExtensionFactory() {
ExtensionLoader<ExtensionFactory> loader = ExtensionLoader.getExtensionLoader(ExtensionFactory.class);
List<ExtensionFactory> list = new ArrayList<ExtensionFactory>();
for (String name : loader.getSupportedExtensions()) {
list.add(loader.getExtension(name));
}
factories = Collections.unmodifiableList(list);
}
// 以下的for循环可以看出，循环从2个工厂获取扩展实例
@Override
public <T> T getExtension(Class<T> type, String name) {
for (ExtensionFactory factory : factories) {
T extension = factory.getExtension(type, name);
if (extension != null) {
return extension;
}
}
return null;
}
}
典型的适配器模式，SPI中找不到就去Spring工厂。
注意：factories中的所有实现不包括AdaptiveExtensionFactory。可以跟踪下代码loader.getSupportedExtensions方法。跟踪到ExtensionLoader.loadClass，仔细看下那几个if。就会明白在缓存的时候，Adaptive标注的跟普通的实现已经区分开了。
在源码中会大量出现ExtensionLoader.getExtensionLoader(XxxType.class).getAdaptiveExtension()类似这样的代码。这是在加载XxxType类型的自适应拓展，关于自适应拓展的详细介绍，可以参考自适应拓展。简单理解，就是在初始的时候，不加载XxxType类型的实际对象，而是加载动态生成出来的一个对象。要动态加载类，首先得编译。
追踪下ExtensionLoader.getAdaptiveExtension方法会到追到ExtensionLoader.createAdaptiveExtensionClass
具体追踪过程在自适应拓展中有非常详细描述，如果对这部分不熟悉，请务必去看下，非常重要。
private Class<?> createAdaptiveExtensionClass() {
// 动态生成适配代码
String code = createAdaptiveExtensionClassCode();
ClassLoader classLoader = findClassLoader();
// 动态获取编译器
com.alibaba.dubbo.common.compiler.Compiler compiler = ExtensionLoader.getExtensionLoader(com.alibaba.dubbo.common.compiler.Compiler.class).getAdaptiveExtension();
// 编译，并且返回编译后的class
return compiler.compile(code, classLoader);
}
createAdaptiveExtensionClassCode这个方法，看着有点费劲。主要还是学习思想。个人建议，在debug的时候在createAdaptiveExtensionClassCode的地方打上断点。把生成的code贴出来看看涨啥样。
这边贴一段关于Protocol类型的适配代码。其他类型的结构类似。
package com.alibaba.dubbo.rpc;
import com.alibaba.dubbo.common.extension.ExtensionLoader;
public class Protocol$Adaptive implements com.alibaba.dubbo.rpc.Protocol {
public void destroy() {
throw new UnsupportedOperationException("method public abstract void com.alibaba.dubbo.rpc.Protocol.destroy() of interface com.alibaba.dubbo.rpc.Protocol is not adaptive method!");
}
public int getDefaultPort() {
throw new UnsupportedOperationException("method public abstract int com.alibaba.dubbo.rpc.Protocol.getDefaultPort() of interface com.alibaba.dubbo.rpc.Protocol is not adaptive method!");
}
public com.alibaba.dubbo.rpc.Exporter export(com.alibaba.dubbo.rpc.Invoker arg0) throws com.alibaba.dubbo.rpc.RpcException {
if (arg0 == null) throw new IllegalArgumentException("com.alibaba.dubbo.rpc.Invoker argument == null");
if (arg0.getUrl() == null)
throw new IllegalArgumentException("com.alibaba.dubbo.rpc.Invoker argument getUrl() == null");
com.alibaba.dubbo.common.URL url = arg0.getUrl();
// extName根据URL得到
String extName = (url.getProtocol() == null ? "dubbo" : url.getProtocol());
if (extName == null)
throw new IllegalStateException("Fail to get extension(com.alibaba.dubbo.rpc.Protocol) name from url(" + url.toString() + ") use keys([protocol])");
// 根据extName动态获取真实的Protocol的实现
com.alibaba.dubbo.rpc.Protocol extension = (com.alibaba.dubbo.rpc.Protocol) ExtensionLoader.getExtensionLoader(com.alibaba.dubbo.rpc.Protocol.class).getExtension(extName);
return extension.export(arg0);
}
public com.alibaba.dubbo.rpc.Invoker refer(java.lang.Class arg0, com.alibaba.dubbo.common.URL arg1) throws com.alibaba.dubbo.rpc.RpcException {
if (arg1 == null) throw new IllegalArgumentException("url == null");
com.alibaba.dubbo.common.URL url = arg1;
// extName根据URL得到
String extName = (url.getProtocol() == null ? "dubbo" : url.getProtocol());
if (extName == null)
throw new IllegalStateException("Fail to get extension(com.alibaba.dubbo.rpc.Protocol) name from url(" + url.toString() + ") use keys([protocol])");
// 根据extName动态获取真实的Protocol的实现
com.alibaba.dubbo.rpc.Protocol extension = (com.alibaba.dubbo.rpc.Protocol) ExtensionLoader.getExtensionLoader(com.alibaba.dubbo.rpc.Protocol.class).getExtension(extName);
return extension.refer(arg0, arg1);
}
}
自适应拓展机制，实际上是在实现可供开发者动态扩展的策略模式。
看下Compiler的结构
跟ExtensionFactory很类似，只是在JavassistCompiler和JdkCompiler上面多了个抽象类。看下AdaptiveCompiler的代码。
public Class<?> compile(String code, ClassLoader classLoader) {
Compiler compiler;
ExtensionLoader<Compiler> loader = ExtensionLoader.getExtensionLoader(Compiler.class);
String name = DEFAULT_COMPILER; // copy reference
// 这边就是看看用Javassis来编译还是用Jdk本身
if (name != null && name.length() > 0) {
compiler = loader.getExtension(name);
} else {
compiler = loader.getDefaultExtension();
}
return compiler.compile(code, classLoader);
}
这边就是判断下用Javassis来编译还是用Jdk本身，默认是Javassis，追踪下setDefaultCompiler就会发现，这个用户可以设置。
各种普通扩展类，每个扩展类都有个name。在使用dubbo时，会配置的就是这些name，比如cluster，protocol等等。配置了哪个，在runtime时用到哪个，哪个就会被初始化。其他文章中再细说这部分。
值得关注的一些细节
1.包装类型（filter机制就是用包装类型实现的，dubbo的filter 有详细介绍）
private T createExtension(String name) {
Class<?> clazz = getExtensionClasses().get(name);
if (clazz == null) {
throw findException(name);
}
try {
T instance = (T) EXTENSION_INSTANCES.get(clazz);
if (instance == null) {
EXTENSION_INSTANCES.putIfAbsent(clazz, clazz.newInstance());
instance = (T) EXTENSION_INSTANCES.get(clazz);
}
injectExtension(instance);
// -----------------------重点关注-------------------------
// 循环当前这个扩展类型下的所有包装类型逐个包装并且初始化
Set<Class<?>> wrapperClasses = cachedWrapperClasses;
if (wrapperClasses != null && !wrapperClasses.isEmpty()) {
for (Class<?> wrapperClass : wrapperClasses) {
instance = injectExtension((T) wrapperClass.getConstructor(type).newInstance(instance));
}
}
// -----------------------重点关注-------------------------
return instance;
} catch (Throwable t) {
throw new IllegalStateException("Extension instance(name: " + name + ", class: " +
type + ") could not be instantiated: " + t.getMessage(), t);
}
}
上面注释中标注重点关注的代码，循环当前这个扩展类型下的所有包装类型逐个包装并且初始化。
比如：Protocol类型的扩展，有3个包装类，分别是ProtocolFilterWrapper，ProtocolListenerWrapper，QosProtocolWrapper
filter=com.alibaba.dubbo.rpc.protocol.ProtocolFilterWrapper
listener=com.alibaba.dubbo.rpc.protocol.ProtocolListenerWrapper
mock=com.alibaba.dubbo.rpc.support.MockProtocol
dubbo=com.alibaba.dubbo.rpc.protocol.dubbo.DubboProtocol
injvm=com.alibaba.dubbo.rpc.protocol.injvm.InjvmProtocol
rmi=com.alibaba.dubbo.rpc.protocol.rmi.RmiProtocol
hessian=com.alibaba.dubbo.rpc.protocol.hessian.HessianProtocol
com.alibaba.dubbo.rpc.protocol.http.HttpProtocol
com.alibaba.dubbo.rpc.protocol.webservice.WebServiceProtocol
thrift=com.alibaba.dubbo.rpc.protocol.thrift.ThriftProtocol
memcached=com.alibaba.dubbo.rpc.protocol.memcached.MemcachedProtocol
redis=com.alibaba.dubbo.rpc.protocol.redis.RedisProtocol
rest=com.alibaba.dubbo.rpc.protocol.rest.RestProtocol
registry=com.alibaba.dubbo.registry.integration.RegistryProtocol
qos=com.alibaba.dubbo.qos.protocol.QosProtocolWrapper
RegistryProtocol，DubboProtocol在初始化的时候，就会被这3个包装类逐个包装。
看下Protocol模块的类图
上图类有点多，不过结果很清晰。看下Protocol的5个子类，分别是
AbstractProtocol（具体协议实现类都在这个分支上）
ProtocolFilterWrapper，ProtocolListenerWrapper，QosProtocolWrapper（三个包装类）
RegistryProtocol（这个比较特殊，它算是协议模块的适配器，dubbo服务导出和引入里面有详细说明）
仔细分析结构之后会发现，Protocol模块并不复杂。
2.开发者自定义的扩展应该是可以写到META-INF/services/或者META-INF/dubbo/的任意目录下的。
private Map<String, Class<?>> loadExtensionClasses() {
final SPI defaultAnnotation = type.getAnnotation(SPI.class);
if (defaultAnnotation != null) {
String value = defaultAnnotation.value();
if ((value = value.trim()).length() > 0) {
String[] names = NAME_SEPARATOR.split(value);
if (names.length > 1) {
throw new IllegalStateException("more than 1 default extension name on extension " + type.getName()
+ ": " + Arrays.toString(names));
}
if (names.length == 1) cachedDefaultName = names[0];
}
}
Map<String, Class<?>> extensionClasses = new HashMap<String, Class<?>>();
loadDirectory(extensionClasses, DUBBO_INTERNAL_DIRECTORY);
loadDirectory(extensionClasses, DUBBO_DIRECTORY);
loadDirectory(extensionClasses, SERVICES_DIRECTORY);
return extensionClasses;
}
从这边可以看到loadDirectory的过程，对这3个目录有优先级区分，但没有任何区别对待。
总结
ExtensionLoader是Dubbo的核心，算是地基。
Adaptive自适应扩展机制非常重要。分为类的适配器和方法适配器，ExtensionFactory和Compiler属于类的适配器。其他的@Adaptive都加在了接口的方法上。只要某个接口的一个方法上加了@Adaptive注解，在注入时就会被注入一个动态生成的类。在runtime运行时会根据URL当时的配置信息，抽取出对应的name，然后通过ExtensionLoader.getExtension方法动态获取对应的具体实现。实际上就是策略模式的运用。文中已经重点强调，这部分非常重要。重要的事情要说三遍。。。
重点关注下Protocol上的export和refer
