2Dubbo 源码分析 —— 深入理解Dubbo 的增强SPI机制

Posted 2021-04-05 努力努力再努力xLg

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了2Dubbo 源码分析 —— 深入理解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机制

image-20201120215233203

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中指定的单行文件名称换成了键值对的形式，这样就可以实现如果实现类不存在可以爆出对应的错误信息。

2、Dubbo 源码分析 —— 深入理解Dubbo 的增强SPI机制 — image-20201120215539540

在上图中就可以看出，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自适应接在的重点

大致核心问题我都在代码中标注了，也可以参照

image-20201121170557134

这里值得一体的是，Dubbo使用的默认的代码编译生成器是

javassist.

其实其中有很多细节能够体现出一个成熟成功的框架的魅力。其中针对不同的类型，不同的阶段，做了非常多的缓存动作，这有点类似于spring 在启动时，加载bean过程中，使用到的三层缓存，其中也是使用这种缓存的一层层的映射关系，来完成校验，代码回溯，或者标记的作用。也是就此，才能实现Dubbo的SPI的强化。不去加载多余的拓展类，也可根据缓存的映射关系准确的定位到错误信息，也能动态根据初始化类进行动态的定义传参。

本文仅供笔者本人学习，一起进步！

加油！

以上是关于2Dubbo 源码分析 —— 深入理解Dubbo 的增强SPI机制的主要内容，如果未能解决你的问题，请参考以下文章

Dubbo SPI 源码深入分析

dubbo专题-深入分析zookeeper创建节点过程(高清大图无水印版)

Dubbo 源码分析 - 集群容错之 Directory

8.如何自己设计一个类似 Dubbo 的 RPC 框架？

dubbo service启动流程源码分析

源码分析Dubbo专栏