2、Dubbo 源码分析 —— 深入理解Dubbo 的增强SPI机制
我准备战斗到最后，不是因为我勇敢，是我想见证一切。 --双雪涛《猎人》 努力努力再努力xLg
2.1、Dubbo的SPI示例
3、getExtensionLoader
3.1、ExtensionLoader的源码解析
3.2、构造器
3.3 获取所有的拓展类
Thinking
一个技术，为什么要用它，解决了那些问题？ 如果不用会怎么样，有没有其它的解决方法？ 对比其它的解决方案，为什么最终选择了这种，都有何利弊？ 你觉得项目中还有那些地方可以用到，如果用了会带来那些问题？ 这些问题你又如何去解决的呢？
本文基于Dubbo 2.6.7-SNAPSHOT
在Dubbo官网的介绍中，Dubbo的整体架构基本都是基于SPI来实现的。至于DUBBO的SPI是针对于java本身提供的SPI增强实现的。那么首先看看Dubbo对此进行了哪些增强呢？
《Java SPI(Service Provider Interface)简介》
深入理解JDK的SPI机制
1、Dubbo SPI的增强
-
java自身的SPI比较生硬，只要在配置文件中指定的类，都会在程序启动时，全部初始化出来，并不会管后面系统是否用到这些类，这样做明显是非常消耗性能，且在启动时显然是非常耗时的。 -
如果扩展加载失败，连扩展点的名称都拿不到了。比如：JDK 标准的 ScriptEngine，通过 getName() 获取脚本类型的名称，但如果 RubyScriptEngine 因为所依赖的 jruby.jar 不存在，导致 RubyScriptEngine 类加载失败，这个失败原因被吃掉了，和 ruby 对应不起来，当用户执行 ruby 脚本时，会报不支持 ruby，而不是真正失败的原因。 -
Dubbo的SPI对java的SPI的扩展。增加了对IoC和AOP的支持，一个扩展点可以setter注入其他扩展点。
在上述的功能中，dubbo最大的增强就是对SPI的统一实现做了筛选，因为Dubbo的整个框架都是可拆分的组件化。都有非常明确的分层，比喻说对于RPC来说就有多种实现，Netty、protobft、WebService、REST、Redis等等实现。
加入上述的所有事件都一股脑的实现，不说浪费资源的问题了，连程序自己都不清楚要使用哪个了。
org.apache.dubbo.common.extension.SPI在Dubbo中是一个顶层的接口。
2、SPI注解
在该注解的java doc 中就提到，该接口解析的的SPI文件跟java中的是不一样的，它将dubbo中指定的单行文件名称换成了键值对的形式，这样就可以实现如果实现类不存在可以爆出对应的错误信息。
在上图中就可以看出，Dubbo对于java的SPI的改进
好处就是如果在引用第三类时，但是第三方类的jar又不存在的情况下。dubbo可以根据键找到对应的类，进行错误信息打印。而不是像以前以前找不到对应的应用的类。
2.1、Dubbo的SPI示例
代码详情
从上述代码使用debug来进一步调试源码
3、getExtensionLoader
org.apache.dubbo.common.extension.ExtensionLoader#getExtensionLoader
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 an interface!");
}
if (!withExtensionAnnotation(type)) { // 是否存在SPI注解
throw new IllegalArgumentException("Extension type (" + type +
") is not an extension, because it is NOT annotated with @" + SPI.class.getSimpleName() + "!");
}
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); // 这一步会将objectFactory设置成null，原因是容器中已经创建成功了，在下一步再进行一次赋值就可以了
}
return loader;
}
需要注意的是，该类是一个静态的方法，并且在调用过程中才初始化 ExtensionLoader，下面会说到该类唯一的构造方法。并且在每一个被SPI标注的扩展类都会对应这一个ExtensionLoader实例。在该方法中可以看到，在Dubbo的SPI中，针对的只能是接口，并且必须使用
SPI注解。
3、ExtensionLoader
在SPI统计目录下存在该类。从名称来看就是用来加载扩展类的加载器了
该类为dubbo的SPI核心类，与java中的SPI实现的
java.util.ServiceLoader定义类似。
3.1、ExtensionLoader的源码解析
private static final Logger logger = LoggerFactory.getLogger(ExtensionLoader.class);
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/";
private static final Pattern NAME_SEPARATOR = Pattern.compile("\\s*[,]+\\s*");
// ============================== 静态属性 ==============================
/**
* 拓展加载器集合
* key：拓展接口
*/
private static final ConcurrentMap<Class<?>, ExtensionLoader<?>> EXTENSION_LOADERS = new ConcurrentHashMap<>();
/**
*
* 拓展实现类集合
*
* key：拓展实现类
* value：拓展对象。
*
* 例如，key 为 Class<AccessLogFilter>
* value 为 AccessLogFilter 对象
*
*/
private static final ConcurrentMap<Class<?>, Object> EXTENSION_INSTANCES = new ConcurrentHashMap<>();
// ============================== 对象属性 ==============================
/**
* 拓展接口。
* 例如，Protocol register 等等 在配置文件中的所以拓展文件
*/
private final Class<?> type; // 拓展接口 Protocol
/**
* 对象工厂
*
* 用于调用 {@link #injectExtension(Object)} 方法，向拓展对象注入依赖属性。
*
* 例如，StubProxyFactoryWrapper 中有 `Protocol protocol` 属性。
*/
private final ExtensionFactory objectFactory;
/**
* 缓存的拓展名与拓展类的映射。
*
* 和 {@link #cachedClasses} 的 KV 对调。
* 通过 {@link #loadExtensionClasses} 加载
*/
private final ConcurrentMap<Class<?>, String> cachedNames = new ConcurrentHashMap<>(); // 缓存的拓展名与拓展类的映射
/**
* 缓存的拓展实现类集合。
* 不包含如下两种类型：
* 1. 自适应拓展实现类。例如 AdaptiveExtensionFactory
* 2. 带唯一参数为拓展接口的构造方法的实现类，或者说拓展 Wrapper 实现类。例如，ProtocolFilterWrapper 。
* 拓展 Wrapper 实现类，会添加到 {@link #cachedWrapperClasses} 中
*
* 通过 {@link #loadExtensionClasses} 加载
*/
private final Holder<Map<String, Class<?>>> cachedClasses = new Holder<>();
/**
* 拓展名与 @Activate 的映射
* 例如，AccessLogFilter。
* 用于 {@link #getActivateExtension(URL, String)}
*/
private final Map<String, Object> cachedActivates = new ConcurrentHashMap<>();
/**
*
* 缓存的拓展对象集合
*
* key：拓展名
* value：拓展对象
*
* 例如，Protocol 拓展
* key：dubbo value：DubboProtocol
* key：injvm value：InjvmProtocol
*
* 通过 {@link #loadExtensionClasses} 加载
*
*/
private final ConcurrentMap<String, Holder<Object>> cachedInstances = new ConcurrentHashMap<>();
/**
* 缓存的自适应( Adaptive )拓展对象
*/
private final Holder<Object> cachedAdaptiveInstance = new Holder<>();
/**
* 缓存的自适应拓展对象的类
*
* {@link #getAdaptiveExtensionClass()}
*/
private volatile Class<?> cachedAdaptiveClass = null;
/**
* 缓存的默认拓展名
*
* 通过 {@link SPI} 注解获得
*/
private String cachedDefaultName;
/**
* 创建 {@link #cachedAdaptiveInstance} 时发生的异常。
*
* 生异常后，不再创建，参见 {@link #createAdaptiveExtension()}
*/
private volatile Throwable createAdaptiveInstanceError;
/**
* 拓展 Wrapper 实现类集合
*
* 带唯一参数为拓展接口的构造方法的实现类
*
* 通过 {@link #loadExtensionClasses} 加载
*/
private Set<Class<?>> cachedWrapperClasses;
/**
* 拓展名 与 加载对应拓展类发生的异常 的 映射
*
* key：拓展名
* value：异常
*
*
*/
private Map<String, IllegalStateException> exceptions = new ConcurrentHashMap<>();
/**
* 加载三个配置类路径
*/
private static LoadingStrategy DUBBO_INTERNAL_STRATEGY = () -> DUBBO_INTERNAL_DIRECTORY;
private static LoadingStrategy DUBBO_STRATEGY = () -> DUBBO_DIRECTORY;
private static LoadingStrategy SERVICES_STRATEGY = () -> SERVICES_DIRECTORY;
3.2、构造器
private ExtensionLoader(Class<?> type) {
this.type = type;
objectFactory = (type == ExtensionFactory.class ? null : ExtensionLoader.getExtensionLoader(ExtensionFactory.class).getAdaptiveExtension());
}
可以看到在类初始化时，会判断调用该类的对象是否是该类的工厂类，如果是，则有工厂类执行初始化。如果不是则初始化该工厂类
从构造器可以看出，Dubbo 将SPI分为两步， 第一步是根据传入的type类型获取所有扩展加载程序（其中就包含了Dubbo的IoC和） 第二步是将
3.2.1、getExtensionLoader
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 an interface!");
}
if (!withExtensionAnnotation(type)) { // 是否存在SPI注解
throw new IllegalArgumentException("Extension type (" + type +
") is not an extension, because it is NOT annotated with @" + SPI.class.getSimpleName() + "!");
}
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); // 这一步会将objectFactory设置成null，原因是容器中已经创建成功了，在下一步再进行一次赋值就可以了
}
return loader;
}
上述可以看做是前驱知识，大致了解到，在Dubbo的SPI机制中，Dubbo竟可能的去加强了SPI的灵活性。
给SPI强化到不仅仅是单一的指定路径，Dubbo是支持三个路径下的全路径文件的。 Dubbo 还使用了键值对的方式，来增强传统SPI在启动阶段就要将SPI文件中所有的文件都加载出来。
Dubbo 则是用这种键值对的方式，将需要加载的拓展类全部缓存起来，等要使用的时候，通过键值对的方式查找，并且初始化的。 其中的初始化操作就涉及到了Dubbo的多次对ExtensionLoader的加载。并且其中还包含了Dubbo对这些类初始化的IoC和AOP的实现（Dubbo只支持 Setter注入） Dubbo还针对传统的SPI加强了动态加载的功能，Dubbo会根据拓展类是否使用了 @Adaptive注解，（该注解作用在接口方法上，Dubbo才会为此生成代理类或者方法）。因为Dubbo中对于自适应类是存在两种情况的，一种使用该注解的类，作用在类上，开始表明该类是用户自己定义的自适应类。在 Dubbo 中，仅有两个类被 Adaptive 注解了，分别是AdaptiveCompiler和AdaptiveExtensionFactory.更多时候，Adaptive 是注解在接口方法上的，表示拓展的加载逻辑需由框架自动生成
最主要的功能是，给拓展类动态的添加方法参数，这样就可以完美的实现，在多个接口的实现中，可以根据涌入传入的类型选择最终生成的类是需要传入某种参数。这种设计方法就完美的解决了在传统的SPI中，一股脑将所有的拓展类全部实现出来，并且如果有些拓展类初始化失败，在使用时才报错的问题。
3.3 获取所有的拓展类
我们在通过名称获取拓展类之前，首先需要根据配置文件解析出拓展项名称到拓展类的映射关系表（Map<名称, 拓展类>），之后再根据拓展项名称从映射关系表中取出相应的拓展类即可。相关过程的代码分析如下：
private Map<String, Class<?>> getExtensionClasses() {
// 从缓存中获取已加载的拓展类
Map<String, Class<?>> classes = cachedClasses.get();
// 双重检查
if (classes == null) {
synchronized (cachedClasses) {
classes = cachedClasses.get();
if (classes == null) {
// 加载拓展类
classes = loadExtensionClasses();
cachedClasses.set(classes);
}
}
}
return classes;
}
这里也是先检查缓存，若缓存未命中，则通过 synchronized 加锁。加锁后再次检查缓存，并判空。此时如果 classes 仍为 null，则通过 loadExtensionClasses 加载拓展类。下面分析 loadExtensionClasses 方法的逻辑。
private Map<String, Class<?>> loadExtensionClasses() {
// 获取 SPI 注解，这里的 type 变量是在调用 getExtensionLoader 方法时传入的
final SPI defaultAnnotation = type.getAnnotation(SPI.class);
if (defaultAnnotation != null) {
String value = defaultAnnotation.value();
if ((value = value.trim()).length() > 0) {
// 对 SPI 注解内容进行切分
String[] names = NAME_SEPARATOR.split(value);
// 检测 SPI 注解内容是否合法，不合法则抛出异常
if (names.length > 1) {
throw new IllegalStateException("more than 1 default extension name on extension...");
}
// 设置默认名称，参考 getDefaultExtension 方法
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;
}
loadExtensionClasses 方法总共做了两件事情，一是对 SPI 注解进行解析，二是调用 loadDirectory 方法加载指定文件夹配置文件。SPI 注解解析过程比较简单，无需多说。下面我们来看一下 loadDirectory 做了哪些事情。
private void loadDirectory(Map<String, Class<?>> extensionClasses, String dir) {
// fileName = 文件夹路径 + type 全限定名
String fileName = dir + type.getName();
try {
Enumeration<java.net.URL> urls;
ClassLoader classLoader = findClassLoader();
// 根据文件名加载所有的同名文件
if (classLoader != null) {
urls = classLoader.getResources(fileName);
} else {
urls = ClassLoader.getSystemResources(fileName);
}
if (urls != null) {
while (urls.hasMoreElements()) {
java.net.URL resourceURL = urls.nextElement();
// 加载资源
loadResource(extensionClasses, classLoader, resourceURL);
}
}
} catch (Throwable t) {
logger.error("...");
}
}
loadDirectory 方法先通过 classLoader 获取所有资源链接，然后再通过 loadResource 方法加载资源。我们继续跟下去，看一下 loadResource 方法的实现。
private void loadResource(Map<String, Class<?>> extensionClasses,
ClassLoader classLoader, java.net.URL resourceURL) {
try {
BufferedReader reader = new BufferedReader(
new InputStreamReader(resourceURL.openStream(), "utf-8"));
try {
String line;
// 按行读取配置内容
while ((line = reader.readLine()) != null) {
// 定位 # 字符
final int ci = line.indexOf('#');
if (ci >= 0) {
// 截取 # 之前的字符串，# 之后的内容为注释，需要忽略
line = line.substring(0, ci);
}
line = line.trim();
if (line.length() > 0) {
try {
String name = null;
int i = line.indexOf('=');
if (i > 0) {
// 以等于号 = 为界，截取键与值
name = line.substring(0, i).trim();
line = line.substring(i + 1).trim();
}
if (line.length() > 0) {
// 加载类，并通过 loadClass 方法对类进行缓存
loadClass(extensionClasses, resourceURL,
Class.forName(line, true, classLoader), name);
}
} catch (Throwable t) {
IllegalStateException e = new IllegalStateException("Failed to load extension class...");
}
}
}
} finally {
reader.close();
}
} catch (Throwable t) {
logger.error("Exception when load extension class...");
}
}
loadResource 方法用于读取和解析配置文件，并通过反射加载类，最后调用 loadClass 方法进行其他操作。loadClass 方法用于主要用于操作缓存，该方法的逻辑如下：
private void loadClass(Map<String, Class<?>> extensionClasses, java.net.URL resourceURL,
Class<?> clazz, String name) throws NoSuchMethodException {
if (!type.isAssignableFrom(clazz)) {
throw new IllegalStateException("...");
}
// 检测目标类上是否有 Adaptive 注解
if (clazz.isAnnotationPresent(Adaptive.class)) {
if (cachedAdaptiveClass == null) {
// 设置 cachedAdaptiveClass缓存
cachedAdaptiveClass = clazz;
} else if (!cachedAdaptiveClass.equals(clazz)) {
throw new IllegalStateException("...");
}
// 检测 clazz 是否是 Wrapper 类型
} else if (isWrapperClass(clazz)) {
Set<Class<?>> wrappers = cachedWrapperClasses;
if (wrappers == null) {
cachedWrapperClasses = new ConcurrentHashSet<Class<?>>();
wrappers = cachedWrapperClasses;
}
// 存储 clazz 到 cachedWrapperClasses 缓存中
wrappers.add(clazz);
// 程序进入此分支，表明 clazz 是一个普通的拓展类
} else {
// 检测 clazz 是否有默认的构造方法，如果没有，则抛出异常
clazz.getConstructor();
if (name == null || name.length() == 0) {
// 如果 name 为空，则尝试从 Extension 注解中获取 name，或使用小写的类名作为 name
name = findAnnotationName(clazz);
if (name.length() == 0) {
throw new IllegalStateException("...");
}
}
// 切分 name
String[] names = NAME_SEPARATOR.split(name);
if (names != null && names.length > 0) {
Activate activate = clazz.getAnnotation(Activate.class);
if (activate != null) {
// 如果类上有 Activate 注解，则使用 names 数组的第一个元素作为键，
// 存储 name 到 Activate 注解对象的映射关系
cachedActivates.put(names[0], activate);
}
for (String n : names) {
if (!cachedNames.containsKey(clazz)) {
// 存储 Class 到名称的映射关系
cachedNames.put(clazz, n);
}
Class<?> c = extensionClasses.get(n);
if (c == null) {
// 存储名称到 Class 的映射关系
extensionClasses.put(n, clazz);
} else if (c != clazz) {
throw new IllegalStateException("...");
}
}
}
}
}
如上，loadClass 方法操作了不同的缓存，比如 cachedAdaptiveClass、cachedWrapperClasses 和 cachedNames 等等。除此之外，该方法没有其他什么逻辑了。
到此，关于缓存类加载的过程就分析完了。整个过程没什么特别复杂的地方，大家按部就班的分析即可，不懂的地方可以调试一下。接下来，我们来聊聊 Dubbo IOC 方面的内容。
4、Dubbo的IoC和AOP
Dubbo IOC 是通过 setter 方法注入依赖。Dubbo 首先会通过反射获取到实例的所有方法，然后再遍历方法列表，检测方法名是否具有 setter 方法特征。若有，则通过 ObjectFactory 获取依赖对象，最后通过反射调用 setter 方法将依赖设置到目标对象中。整个过程对应的代码如下：
private T injectExtension(T instance) {
try {
if (objectFactory != null) {
// 遍历目标类的所有方法
for (Method method : instance.getClass().getMethods()) {
// 检测方法是否以 set 开头，且方法仅有一个参数，且方法访问级别为 public
if (method.getName().startsWith("set")
&& method.getParameterTypes().length == 1
&& Modifier.isPublic(method.getModifiers())) {
// 获取 setter 方法参数类型
Class<?> pt = method.getParameterTypes()[0];
try {
// 获取属性名，比如 setName 方法对应属性名 name
String property = method.getName().length() > 3 ?
method.getName().substring(3, 4).toLowerCase() +
method.getName().substring(4) : "";
// 从 ObjectFactory 中获取依赖对象
Object object = objectFactory.getExtension(pt, property);
if (object != null) {
// 通过反射调用 setter 方法设置依赖
method.invoke(instance, object);
}
} catch (Exception e) {
logger.error("fail to inject via method...");
}
}
}
}
} catch (Exception e) {
logger.error(e.getMessage(), e);
}
return instance;
}
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); //IoC 使用Setter 将属性注入
Set<Class<?>> wrapperClasses = cachedWrapperClasses;
if (CollectionUtils.isNotEmpty(wrapperClasses)) {
for (Class<?> wrapperClass : wrapperClasses) { // 将实例包装成包装类，实现dubbo的AOP
instance = injectExtension((T) wrapperClass.getConstructor(type).newInstance(instance));
}
}
initExtension(instance);
return instance;
} catch (Throwable t) {
throw new IllegalStateException("Extension instance (name: " + name + ", class: " +
type + ") couldn't be instantiated: " + t.getMessage(), t);
}
}
在上面代码中，objectFactory 变量的类型为 AdaptiveExtensionFactory，AdaptiveExtensionFactory 内部维护了一个 ExtensionFactory 列表，用于存储其他类型的 ExtensionFactory。Dubbo 目前提供了两种 ExtensionFactory，分别是 SpiExtensionFactory 和 SpringExtensionFactory。前者用于创建自适应的拓展，后者是用于从 Spring 的 IOC 容器中获取所需的拓展。
所以可以看出，Dubbo的加载拓展类中，是可以支持对Spring Bean的加载的
并且在Dubbo的SPI中会维护一个wrapper集合，这就是Dubbo的AOP的实现，他会将类的构造器中存在wrapper参数的类都进行包装。
5、Dubbo的自适应解析
Dubbo的自适应解析，看上去代码很多，其实基本都是一些代码的自动生成，其中比较重要的逻辑如下
首先判断拓展类是否存在方法使用 @Adaptive注解修饰
因为Dubbo对针对修饰和未修饰两种情况进行代码的生成， 未修饰的方法会直接生成一个抛出异常处理。 修饰的方法的生成中，最重要的是对于参数的动态加载。这就是Dubbo自适应接在的重点 大致核心问题我都在代码中标注了，也可以参照
这里值得一体的是，Dubbo使用的默认的代码编译生成器是
javassist.
其实其中有很多细节能够体现出一个成熟成功的框架的魅力。其中针对不同的类型，不同的阶段，做了非常多的缓存动作，这有点类似于spring 在启动时，加载bean过程中，使用到的三层缓存，其中也是使用这种缓存的一层层的映射关系，来完成校验，代码回溯，或者标记的作用。也是就此，才能实现Dubbo的SPI的强化。不去加载多余的拓展类，也可根据缓存的映射关系准确的定位到错误信息，也能动态根据初始化类进行动态的定义传参。
本文仅供笔者本人学习，一起进步！
加油！