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

微信关注公众号(Lambda在线)

第一时间推送最新技术资料

我准备战斗到最后,不是因为我勇敢,是我想见证一切。   --双雪涛《猎人》 努力努力再努力xLg


  • 2.1、Dubbo的SPI示例

  • 3、getExtensionLoader

    • 3.1、ExtensionLoader的源码解析

    • 3.2、构造器

    • 3.3 获取所有的拓展类


Thinking

  1. 一个技术,为什么要用它,解决了那些问题?
  2. 如果不用会怎么样,有没有其它的解决方法?
  3. 对比其它的解决方案,为什么最终选择了这种,都有何利弊?
  4. 你觉得项目中还有那些地方可以用到,如果用了会带来那些问题?
  5. 这些问题你又如何去解决的呢?

本文基于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的增强

  1. java自身的SPI比较生硬,只要在配置文件中指定的类,都会在程序启动时,全部初始化出来,并不会管后面系统是否用到这些类,这样做明显是非常消耗性能,且在启动时显然是非常耗时的。
  2. 如果扩展加载失败,连扩展点的名称都拿不到了。比如:JDK 标准的 ScriptEngine,通过 getName() 获取脚本类型的名称,但如果 RubyScriptEngine 因为所依赖的 jruby.jar 不存在,导致 RubyScriptEngine 类加载失败,这个失败原因被吃掉了,和 ruby 对应不起来,当用户执行 ruby 脚本时,会报不支持 ruby,而不是真正失败的原因。
  3. 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
2、Dubbo 源码分析 —— 深入理解Dubbo 的增强SPI机制
image-20201120215907973

在上图中就可以看出,Dubbo对于java的SPI的改进

好处就是如果在引用第三类时,但是第三方类的jar又不存在的情况下。dubbo可以根据键找到对应的类,进行错误信息打印。而不是像以前以前找不到对应的应用的类。

2.1、Dubbo的SPI示例

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

代码详情

从上述代码使用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统计目录下存在该类。从名称来看就是用来加载扩展类的加载器了

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

该类为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;
2、Dubbo 源码分析 —— 深入理解Dubbo 的增强SPI机制
image-20201120223217054

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的灵活性。

  1. 给SPI强化到不仅仅是单一的指定路径,Dubbo是支持三个路径下的全路径文件的。
  2. Dubbo 还使用了键值对的方式,来增强传统SPI在启动阶段就要将SPI文件中所有的文件都加载出来。
    1. Dubbo 则是用这种键值对的方式,将需要加载的拓展类全部缓存起来,等要使用的时候,通过键值对的方式查找,并且初始化的。
    2. 其中的初始化操作就涉及到了Dubbo的多次对ExtensionLoader的加载。并且其中还包含了Dubbo对这些类初始化的IoC和AOP的实现(Dubbo只支持 Setter注入)
  3. Dubbo还针对传统的SPI加强了动态加载的功能,Dubbo会根据拓展类是否使用了 @Adaptive注解,(该注解作用在接口方法上,Dubbo才会为此生成代理类或者方法)。因为Dubbo中对于自适应类是存在两种情况的,一种使用该注解的类,作用在类上,开始表明该类是用户自己定义的自适应类。在 Dubbo 中,仅有两个类被 Adaptive 注解了,分别是 AdaptiveCompilerAdaptiveExtensionFactory.更多时候,Adaptive 是注解在接口方法上的,表示拓展的加载逻辑需由框架自动生成
    1. 最主要的功能是,给拓展类动态的添加方法参数,这样就可以完美的实现,在多个接口的实现中,可以根据涌入传入的类型选择最终生成的类是需要传入某种参数。这种设计方法就完美的解决了在传统的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(34).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的自适应解析,看上去代码很多,其实基本都是一些代码的自动生成,其中比较重要的逻辑如下

  1. 首先判断拓展类是否存在方法使用 @Adaptive注解修饰
    1. 因为Dubbo对针对修饰和未修饰两种情况进行代码的生成,
    2. 未修饰的方法会直接生成一个抛出异常处理。
    3. 修饰的方法的生成中,最重要的是对于参数的动态加载。这就是Dubbo自适应接在的重点
  2. 大致核心问题我都在代码中标注了,也可以参照
image-20201121170557134

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

javassist.


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

本文仅供笔者本人学习,一起进步!

加油!


版权申明:本站内容全部来自于腾讯微信公众号,属第三方自助提交推荐。《2、Dubbo 源码分析 —— 深入理解Dubbo 的增强SPI机制》的版权归原作者「努力努力再努力xLg」所有, 文章言论观点不代表Lambda在线的观点, Lambda在线不承担任何法律责任。如需删除可联系QQ:516101458

文章来源: 阅读原文

努力努力再努力xLg

努力努力再努力xLg

Java

猜你喜欢