Dubbo SPI 机制基本操作与源码深入理解

最新推荐文章于 2024-08-21 03:06:57 发布
最新推荐文章于 2024-08-21 03:06:57 发布
阅读量1.1w 收藏 4
点赞数
分类专栏： 框架 文章标签： java
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/wangxuelei036/article/details/106801915
版权

从上一篇文章java spi的原理中可以了解到，java的spi机制有着如下的弊端：

  • 只能遍历所有的实现，并全部实例化。
  • 配置文件中只是简单的列出了所有的扩展实现，而没有给他们命名。导致在程序中很难去准确的引用它们。
  • 扩展如果依赖其他的扩展，做不到自动注入和装配。
  • 扩展很难和其他的框架集成，比如扩展里面依赖了一个Spring bean，原生的Java SPI不支持。

想了解JAVA SPI 的基本思想和应用可以参考：

JAVA SPI机制深入详解

我们都是知道一个合格的开源框架对于扩展的支持都要是相当弹性的，Dubbo 也不例外。Dubbo采用了简单的扩展方式，基于SPI机制。但是自己另外实现了一套，对以下几点进行了改进

  • JDK 标准的 SPI 会一次性实例化扩展点所有实现，如果有扩展实现初始化很耗时，但如果没用上也加载，会很浪费资源。

  • 如果扩展点加载失败，连扩展点的名称都拿不到了。比如：JDK 标准的 ScriptEngine，通过 getName() 获取脚本类型的名称，但如果 RubyScriptEngine 因为所依赖的 jruby.jar 不存在，导致 RubyScriptEngine 类加载失败，这个失败原因被吃掉了，和 ruby 对应不起来，当用户执行 ruby 脚本时，会报不支持 ruby，而不是真正失败的原因。

  • 增加了对扩展点 IoC 和 AOP 的支持，一个扩展点可以直接 setter 注入其它扩展点。

基本上讲到这里大家对于SPI可能有个大致的认识，但是要真正理解Dubbo的SPI，还是要仔细看一下源码才可以。

在理解Dubbo的SPI之前，要明确几个核心概念

    （1）扩展点：一个接口。

Dubbo作用灵活的框架，并不会强制所有用户都一定使用Dubbo提供的某些架构。例如注册中心（Registry），Dubbo提供了zk和redis，但是如果我们更倾向于其他的注册中心的话，我们可以替换掉Dubbo提供的注册中心。针对这种可被替换的技术实现点我们称之为扩展点，类似的扩展点有很多，例如Protocol，Filter，Loadbalance等等。

    （2）扩展：扩展（接口）的实现。

Dubbo在加载某个接口的扩展类时候，如果某个实现中有一个拷贝类构造函数，那么该接口实现就是该接口的包装类，此时Dubbo会在真正的实现类上层包装上盖Wrapper。即这个时候从ExtensionLoader中返回的实际扩展类是被Wrapper包装的接口实现类

    （3）扩展自适应实例：其实就是一个Extension的代理

它实现了扩展点接口。在调用扩展点的接口方法时，会根据实际的参数来决定要使用哪个扩展。dubbo会根据接口中的参数，自动地决定选择哪个实现。

    （4）@SPI:该注解作用于扩展点的接口上，表明该接口是一个扩展点。

    （5）@Adaptive：@Adaptive注解用在扩展接口的方法上。

表示该方法是一个自适应方法。Dubbo在为扩展点生成自适应实例时，如果方法有@Adaptive注解，会为该方法生成对应的代码。

这个自适应的扩展点比较难理解，所以这里直接以一个例子来讲解：在RegistryProtocol中有一个属性为Cluster，其中Protocol和Cluster都是Dubbo提供的扩展点，所以这时候当我们真正在操作中使用cluster的时候究竟使用的哪一个cluster的实现类呢？是FailbackCluster还是FailoverCluster？Dubbo在加载一个扩展点的时候如果发现其成员变量也是一个扩展点并且有相关的set方法，就会在这时候将该扩展点设置为一个自适应的扩展点，自适应扩展点（Adaptive）会在真正使用的时候从URL中获取相关参数，来调用真正的扩展点实现类。具体的实现会在下面的源码中详细解释。对于Adaptive的理解其实个人推荐的是Dubbo开发者指南，指南中有对于Adaptive的明确介绍。

     （6）Activate 官网的叫法是自激活，其实这个更合适的叫法个人认为是条件激活。

Activate的作用主要是：提供一种选择性激活的条件，可以是我们通过相关的配置来确定激活哪些功能。

     （7）ExtensionLoader，是dubbo的SPI机制的查找服务实现的工具类，类似与Java的ServiceLoader，可做类比。dubbo约定扩展点配置文件放在classpath下的/META-INF/dubbo，/META-INF/dubbo/internal，/META-INF/services目录下，配置文件名为接口的全限定名，配置文件内容为配置名=扩展实现类的全限定名。

说了这么多，我们简单先操作一把，看下代码如果写

pom文件中包依赖

<!-- https://mvnrepository.com/artifact/com.alibaba/dubbo -->
    <dependency>
      <groupId>com.alibaba</groupId>
      <artifactId>dubbo</artifactId>
      <version>2.6.8</version>
    </dependency>

接口

package org.alexsotob.dubbo.SPI;

import com.alibaba.dubbo.common.extension.SPI;

@SPI
public interface Animal {

    String getName();

}

实现类Dog

package org.alexsotob.dubbo.SPI.impl;

import org.alexsotob.dubbo.SPI.Animal;

public class Dog implements Animal {
    public Dog() {
        System.out.println("dog init !!!");
    }

    @Override
    public String getName() {
        return "I am dog";
    }
}

实现类cat

package org.alexsotob.dubbo.SPI.impl;

import org.alexsotob.dubbo.SPI.Animal;

public class Cat implements Animal {
    public Cat() {
        System.out.println("cat init !!!");
    }

    @Override
    public String getName() {
        return "I am cat";
    }
}

重要的一步，ExtensionLoader，是dubbo的SPI机制的查找服务实现的工具类，类似与Java的ServiceLoader，可做类比。dubbo约定扩展点配置文件放在classpath下的/META-INF/dubbo，/META-INF/dubbo/internal，/META-INF/services目录下，配置文件名为接口的全限定名，配置文件内容为配置名=扩展实现类的全限定名。

配置的格式与java原生的不一样，类似于property文件的格式： 

cat=org.alexsotob.dubbo.SPI.impl.Cat
dog=org.alexsotob.dubbo.SPI.impl.Dog

编写测试类 入口为ExtensionLoader

package org.alexsotob.dubbo.SPI;

import com.alibaba.dubbo.common.extension.ExtensionLoader;

public class DubboSPITest {

    public static void main(String[] args) {
        ExtensionLoader<Animal> carExtensionLoader = ExtensionLoader.getExtensionLoader(Animal.class);        //按需获取实现类对象
        Animal animal = carExtensionLoader.getExtension("cat");
        System.out.println(animal.getName());
    }

}

这里只是一个简单的本地Demo，用于介绍dubbo SPI思想,dubbo还实现了与Spring IOC 进行兼容的等其他功能

基本流程如下，记住它，后面源码分析思路才能比较清晰：

下面将进行源码分析： 

在dubbo SPI示例方法中，我们首先通过 ExtensionLoader的  getExtensionLoader 方法获取一个接口的  ExtensionLoader 实例，然后再通过  ExtensionLoader 的  getExtension 方法获取拓展类对象，源码如下，首先是 getExtensionLoader 方法：

 /**
     * 扩展类加载器缓存，就是扩展点ExtendsLoader实例缓存； key=扩展接口 value=扩展类加载器
     */
    private static final ConcurrentMap<Class<?>, ExtensionLoader<?>> EXTENSION_LOADERS = new ConcurrentHashMap<>();

    public static <T> ExtensionLoader<T> getExtensionLoader(Class<T> type) {        
        //校验传进的type类是否为空
        if (type == null) {
            throw new IllegalArgumentException("Extension type == null");
        }        
        //校验传进的type类是否为接口
        if (!type.isInterface()) {
            throw new IllegalArgumentException("Extension type (" + type + ") is not an interface!");
        }        
        //校验传进的type类是否有@SPI注解
        if (!withExtensionAnnotation(type)) {
            throw new IllegalArgumentException("Extension type (" + type + ") is not an extension, because it is NOT annotated with @" + SPI.class.getSimpleName() + "!");
        }        
        //从ExtensionLoader缓存中查询是否已经存在对应类型的ExtensionLoader实例
        ExtensionLoader<T> loader = (ExtensionLoader<T>) EXTENSION_LOADERS.get(type);
        if (loader == null) {            //没有就new一个ExtensionLoader实例，并存入本地缓存
            EXTENSION_LOADERS.putIfAbsent(type, new ExtensionLoader<T>(type));
            loader = (ExtensionLoader<T>) EXTENSION_LOADERS.get(type);
        }
        return loader;
    }

getExtensionLoader会对传进的接口进行校验，其中包括是否有 @SPI注解校验，这也是在接口上需加 @SPI的原因。然后从 EXTENSION_LOADERS缓存中获取该接口类型的 ExtensionLoader,如果获取不到，则创建一个该接口类型的 ExtensionLoader放入到缓存中，并返回该 ExtensionLoader。

注意这里创建 ExtensionLoader对象的构造方法如下：ExtensionLoader.getExtensionLoader获取ExtensionFactory接口的拓展类，再通过 getAdaptiveExtension从拓展类中获取目标拓展类。它会设置该接口对应的  objectFactory常量为 AdaptiveExtensionFactory。因为 AdaptiveExtensionFactory类上加了@Adaptive注解，为什么是 AdaptiveExtensionFactory原因在之后的文章会解释，且 objectFactory也会在后面用到。

private ExtensionLoader(Class<?> type) {
        this.type = type;        
        //type通常不为ExtensionFactory类，
        // 则objectFactory为ExtensionFactory接口的默认扩展类AdaptiveExtensionFactory
        objectFactory = (type == ExtensionFactory.class ? null : ExtensionLoader.getExtensionLoader(ExtensionFactory.class).getAdaptiveExtension());
    }

 当通过 ExtensionLoader.getExtensionLoader取到接口的加载器Loader之后，在通过 getExtension方法获取需要拓展类对象。

 /**
     * 扩展点实例缓存 key=扩展点名称，value=扩展实例的Holder实例
     */
    private final ConcurrentMap<String, Holder<Object>> cachedInstances = new ConcurrentHashMap<>();

    /**
     * 获取接口拓展类实例
     * 1.检查缓存中是否存在
     * 2.创建并返回拓展类实例
     *
     * @param name 需要获取的配置文件中拓展类的key
     * @return
     */
    public T getExtension(String name) {
        if (StringUtils.isEmpty(name)) {
            throw new IllegalArgumentException("Extension name == null");
        }
        if ("true".equals(name)) {            
            // 获取默认的拓展实现类,即@SPI注解上的默认实现类, 如@SPI("benz")
            return getDefaultExtension();
        }        
        // Holder，顾名思义，用于持有目标对象，从缓存中拿，没有则创建
        final Holder<Object> holder = getOrCreateHolder(name);
        Object instance = holder.get();        // 双重检查
        if (instance == null) {
            synchronized (holder) {
                instance = holder.get();
                if (instance == null) {                   
                    // 创建拓展实例
                    instance = createExtension(name);                    
                    // 设置实例到 holder 中
                    holder.set(instance);
                }
            }
        }
        return (T) instance;
    }

    /**
     * 获取或者创建一个Holder对象
     */
    private Holder<Object> getOrCreateHolder(String name) {        
        // 首先通过扩展名从扩展实例缓存中获取Holder对象
        Holder<Object> holder = cachedInstances.get(name);
        if (holder == null) {            
            //如果没有获取到就new一个空的Holder实例存入缓存
            cachedInstances.putIfAbsent(name, new Holder<>());
            holder = cachedInstances.get(name);
        }
        return holder;
    }

上面代码的逻辑比较简单，首先检查缓存，缓存未命中则创建拓展对象。dubbo中包含了大量的扩展点缓存。这个就是典型的使用空间换时间的做法。也是Dubbo性能强劲的原因之一，包括

  1. 扩展点Class缓存 ，Dubbo SPI在获取扩展点时，会优先从缓存中读取，如果缓存中不存在则加载配置文件，根据配置将Class缓存到内存中，并不会直接初始化。
  2. 扩展点实例缓存 ，Dubbo不仅会缓存Class,还会缓存Class的实例。每次取实例的时候会优先从缓存中取，取不到则从配置中加载，实例化并缓存到内存中。

下面我们来看一下创建拓展对象的过程

/**
     * 扩展实例存入内存中缓存起来； key=扩展类 ； value=扩展类实例
     */
    private static final ConcurrentMap<Class<?>, Object> EXTENSION_INSTANCES = new ConcurrentHashMap<>();

    /**
     * 创建拓展类实例，包含如下步骤
     * 1. 通过 getExtensionClasses 获取所有的拓展类，从配置文件加载获取拓展类的map映射
     * 2. 通过反射创建拓展对象
     * 3. 向拓展对象中注入依赖（IOC）
     * 4. 将拓展对象包裹在相应的 Wrapper 对象中(AOP)
     *
     * @param name 需要获取的配置文件中拓展类的key
     * @return 拓展类实例
     */
    private T createExtension(String name) {       
        // 从配置文件中加载所有的拓展类，可得到“配置项名称”到“配置类”的map，
        // 再根据拓展项名称从map中取出相应的拓展类即可
        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);
            }            
            // 向实例中注入依赖,通过setter方法自动注入对应的属性实例
            injectExtension(instance);            
            //从缓存中取出所有的包装类，形成包装链
            Set<Class<?>> wrapperClasses = cachedWrapperClasses;
            if (CollectionUtils.isNotEmpty(wrapperClasses)) {               
                // 循环创建 Wrapper 实例,形成Wrapper包装链
                for (Class<?> wrapperClass : wrapperClasses) {
                    instance = injectExtension((T) wrapperClass.getConstructor(type).newInstance(instance));
                }
            }            
            //初始化实例并返回
            initExtension(instance);
            return instance;
        } catch (Throwable t) {
            throw new IllegalStateException(".....");
        }
    }

创建拓展类对象步骤分别为：

  1. 通过 getExtensionClasses 从配置文件中加载所有的拓展类，再通过名称获取目标拓展类
  2. 通过反射创建拓展对象
  3. 向拓展对象中注入依赖
  4. 将拓展对象包裹在相应的 Wrapper 对象中

第三和第四个步骤是 Dubbo IOC 与 AOP 的具体实现。我们先重点分析getExtensionClasses 方法的逻辑 getExtensionClasses 方法的逻辑。

从配置文件中加载所有的拓展类

  • 在通过name获取拓展类之前，首先需要根据配置文件解析出拓展项名称与拓展类的映射map，之后再根据拓展项名称从map中取出相应的拓展类即可。 getExtensionClasses 方法源码如下 

/**
     * 扩展点Class缓存 key=扩展名 ，value=对应的class对象
     */
    private final Holder<Map<String, Class<?>>> cachedClasses = new Holder<>();

    /**
     * 解析配置文件中接口的拓展项名称与拓展类的映射表map
     *
     * @return
     */
    private Map<String, Class<?>> getExtensionClasses() {
        // 从缓存中获取已加载的拓展点class
        Map<String, Class<?>> classes = cachedClasses.get();
        //双重检查
        if (classes == null) {
            synchronized (cachedClasses) {
                classes = cachedClasses.get();
                if (classes == null) {
                    // 加载拓展类
                    classes = loadExtensionClasses();
                    cachedClasses.set(classes);
                }
            }
        }
        return classes;
    }

这里也是先检查缓存，若缓存未命中,则通过 loadExtensionClasses 加载拓展类，缓存避免了多次读取配置文件的耗时。下面分析 loadExtensionClasses方法加载配置文件的逻辑

/**
     * 三个dubbo SPI默认扫描的路径
     */
    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 Map<String, Class<?>> loadExtensionClasses() {      
        //获取并缓存接口的@SPI注解上的默认实现类,@SPI("value")中的value
        cacheDefaultExtensionName();
        Map<String, Class<?>> extensionClasses = new HashMap<>();      
        // 加载指定文件夹下的配置文件,常量包含META-INF/dubbo/internal/，META-INF/dubbo/，META-INF/services/三个文件夹
        loadDirectory(extensionClasses, DUBBO_INTERNAL_DIRECTORY, type.getName(), true);      
        //兼容历史版本
        loadDirectory(extensionClasses, DUBBO_INTERNAL_DIRECTORY, type.getName().replace("org.apache", "com.alibaba"), true);
        loadDirectory(extensionClasses, DUBBO_DIRECTORY, type.getName());
        loadDirectory(extensionClasses, DUBBO_DIRECTORY, type.getName().replace("org.apache", "com.alibaba"));
        loadDirectory(extensionClasses, SERVICES_DIRECTORY, type.getName());
        loadDirectory(extensionClasses, SERVICES_DIRECTORY, type.getName().replace("org.apache", "com.alibaba"));
        return extensionClasses;
    }

loadExtensionClasses 方法总共做了两件事情。首先该方法调用 cacheDefaultExtensionName对 SPI 注解进行解析，获取并缓存接口的 @SPI注解上的默认拓展类在 cachedDefaultName。再调用  loadDirectory 方法加载指定文件夹配置文件。

SPI 注解解析过程比较简单,源码如下。只允许一个默认拓展类。

 private void cacheDefaultExtensionName() {        
        // 获取 SPI 注解，这里的 type 变量是在调用 getExtensionLoader 方法时传入，代表接口类
        final SPI defaultAnnotation = type.getAnnotation(SPI.class);
        if (defaultAnnotation == null) {
            return;
        }
        String value = defaultAnnotation.value();
        if ((value = value.trim()).length() > 0) {
            String[] names = NAME_SEPARATOR.split(value);            
            // 检测 SPI 注解内容是否合法（至多一个默认实现类），不合法则抛出异常
            if (names.length > 1) {
                throw new IllegalStateException("...");
            }            
            // 设置默认拓展类名称
            if (names.length == 1) {
                cachedDefaultName = names[0];
            }
        }
    }

 从源码中可以看出 loadExtensionClasses方法加载配置文件的路径有3个，分别为 META-INF/dubbo/internal/， META-INF/dubbo/， META-INF/services/三个文件夹。方法源码如下： 

private void loadDirectory(Map<String, Class<?>> extensionClasses, String dir, String type) {
        loadDirectory(extensionClasses, dir, type, false);
    }

    /**
     * 加载配置文件内容
     *
     * @param extensionClasses                拓展类map
     * @param dir                             文件夹路径
     * @param type                            接口名称
     * @param extensionLoaderClassLoaderFirst 是否先加载ExtensionLoader的ClassLoader
     */
    private void loadDirectory(Map<String, Class<?>> extensionClasses, String dir, String type, boolean extensionLoaderClassLoaderFirst) {       
        // fileName = 文件夹路径 + type 全限定名
        String fileName = dir + type;
        try {
            Enumeration<java.net.URL> urls = null;
            //获取当前线程的类加载器
            ClassLoader classLoader = findClassLoader();
            // try to load from ExtensionLoader's ClassLoader first
            if (extensionLoaderClassLoaderFirst) {
                //获取加载ExtensionLoader.class这个类的类加载器
                ClassLoader extensionLoaderClassLoader = ExtensionLoader.class.getClassLoader(); 
                //如果extensionLoaderClassLoaderFirst=true时，且这两个类加载器不同，就优先使用 extensionLoaderClassLoader
                if (ClassLoader.getSystemClassLoader() != extensionLoaderClassLoader) {
                    urls = extensionLoaderClassLoader.getResources(fileName);
                }
            }
            // 根据文件名加载所有的同名文件
            if (urls == null || !urls.hasMoreElements()) {
                if (classLoader != null) {
                    urls = classLoader.getResources(fileName);
                } else {
                    urls = ClassLoader.getSystemResources(fileName);
                }
            }
            if (urls != null) {
                while (urls.hasMoreElements()) {
                    java.net.URL resourceURL = urls.nextElement();
                    // 解析并加载配置文件中配置的实现类到extensionClasses中去
                    loadResource(extensionClasses, classLoader, resourceURL);
                }
            }
        } catch (Throwable t) {
            logger.error(""). ", t);
        }
    }

首先找到文件夹下的配置文件，文件名需为接口全限定名。利用类加载器获取文件资源链接，再解析配置文件中配置的实现类添加到 extensionClasses中。我们继续看loadResource是如何加载资源的。

 private void loadResource(Map<String, Class<?>> extensionClasses, ClassLoader classLoader, java.net.URL resourceURL) {
        try {
            try (BufferedReader reader = new BufferedReader(new InputStreamReader(resourceURL.openStream(), StandardCharsets.UTF_8))) {
                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) {
                            .....
                        }
                    }
                }
            }
        } catch (Throwable t) {
            logger.error(....);
        }
    }

loadResource 方法用于读取和解析配置文件，按行读取配置文件，每行以等于号 = 为界，截取键与值，并通过反射加载类,最后通过 loadClass方法加载扩展点实现类的class到map中，并对加载到的class进行分类缓存。 loadClass方法实现如下

/**
     * 加载扩展点实现类的class到map中，并对加载到的class进行分类缓存
     * 比如 cachedAdaptiveClass、cachedWrapperClasses 和 cachedNames 等等
     *
     * @param extensionClasses 装载配置文件类的容器
     * @param resourceURL      配置文件资源URL
     * @param clazz            扩展点实现类的class
     * @param name             扩展点实现类的名称，配置文件一行中的key
     * @throws NoSuchMethodException
     */
    private void loadClass(Map<String, Class<?>> extensionClasses, java.net.URL resourceURL, Class<?> clazz, String name) throws NoSuchMethodException {
        //判断配置的实现类是否是实现了type接口
        if (!type.isAssignableFrom(clazz)) {
            throw new IllegalStateException("...");
        }
        //根据配置中实现类的类型来分类缓存起来
        // 检测目标类上是否有 Adaptive 注解，表示这个类就是一个自适应实现类，缓存到cachedAdaptiveClass
        if (clazz.isAnnotationPresent(Adaptive.class)) {
            cacheAdaptiveClass(clazz);
            // 检测 clazz 是否是 Wrapper 类型，判断依据是是否有参数为该接口类的构造方法，缓存到cachedWrapperClasses
        } else if (isWrapperClass(clazz)) {
            cacheWrapperClass(clazz);
        } else {
            // 检测 clazz 是否有默认的构造方法，如果没有，则抛出异常
            clazz.getConstructor();
            // 如果配置文件中key的name 为空，则尝试从Extension注解中获取 name，或使用小写的类名作为name。
            // 已经弃用，就不在讨论这种方式
            if (StringUtils.isEmpty(name)) {
                name = findAnnotationName(clazz);
                if (name.length() == 0) {
                    throw new IllegalStateException("...");
                }
            }
            //使用逗号将name分割为字符串数组
            String[] names = NAME_SEPARATOR.split(name);
            if (ArrayUtils.isNotEmpty(names)) {
                //如果扩展点配置的实现类使用了@Activate注解，就将对应的注解信息缓存起来
                cacheActivateClass(clazz, names[0]);
                for (String n : names) {
                    //缓存扩展点实现类class和扩展点名称的对应关系
                    cacheName(clazz, n);
                    //最后将class存入extensionClasses
                    saveInExtensionClass(extensionClasses, clazz, n);
                }
            }
        }
    }

loadClass方法实现了扩展点的分类缓存功能，如包装类，自适应扩展点实现类，普通扩展点实现类等分别进行缓存。需要注意的是自适应扩展点实现类@Adaptive注解，该注解源码如下

/**
 * For example, given <code>String[] {"key1", "key2"}</code>:
 * <ol>
 * <li>find parameter 'key1' in URL, use its value as the extension's name</li>
 * <li>try 'key2' for extension's name if 'key1' is not found (or its value is empty) in URL</li>
 * <li>use default extension if 'key2' doesn't exist either</li>
 * <li>otherwise, throw {@link IllegalStateException}</li>
 *
 * @return
 */
@Documented
@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.TYPE, ElementType.METHOD})
public @interface Adaptive {
    String[] value() default {};
}

该注解的作用是决定哪个自适应拓展类被注入，该目标拓展类是由URL中的参数决定，URL中参数key由该注解的value给出，该key的value作为目标拓展类名称。

  • 如果注解中有多个值，则根据下标从小到大去URL中查找有无对应的key，一旦找到就用该key的value作为目标拓展类名称。
  • 如果这些值在url中都没有对应的key，使用spi上的默认值。

@Adaptive注解可以作用的类上与方法上， 绝大部分情况下，该注解是作用在方法上，当 Adaptive 注解在类上时，Dubbo 不会为该类生成代理类。注解在方法（接口方法）上时， Dubbo 则会为该方法生成代理类。 Adaptive 注解在接口方法上，表示拓展的加载逻辑需由框架自动生成。注解在类上，表示拓展的加载逻辑由人工编码完成。

上述的 loadClass扫描的是作用在类上。在 Dubbo 中，仅有两个类被@Adaptive注解了，分别是  AdaptiveCompiler 和  AdaptiveExtensionFactory。
loadClass方法设置缓存 cacheAdaptiveClass会导致接口的 cacheAdaptiveClass不为空，后面都会默认用这个拓展类，优先级最高。

回到主线，当执行完 loadClass方法，配置文件中的所有拓展类已经被加载到map中，到此，关于缓存类加载的过程就分析完了。

Dubbo IOC

当 getExtensionClasses()方法执行流程完成后，再根据拓展项name从map中取出相应的拓展类即可获取扩展类Class,通过反射创建实例，并通过 injectExtension(instance);方法向实例中注入依赖 ，将后面总结

DUBBO AOP

当执行完 injectExtension(T instance)方法，在 createExtension(String name)就开始执行 wrapper的包装，类似于spring中的AOP，dubbo运用了装饰器模式。

 Set<Class<?>> wrapperClasses = cachedWrapperClasses;        
    if(CollectionUtils.isNotEmpty(wrapperClasses)){            // 循环创建 Wrapper 实例,形成Wrapper包装链
        for (Class<?> wrapperClass : wrapperClasses) {
            instance = injectExtension((T) wrapperClass.getConstructor(type).newInstance(instance));
        }
    }

这里的 cachedWrapperClasses通过前面的分析已经知道，就是在解析配置文件时判断是否是 Wrapper类型的拓展类，++判断依据为构造方法中是否有参数为该接口类++，则缓存到cachedWrapperClasses。

执行 wrapperClass.getConstructor(type).newInstance(instance)将获取包装类的构造方法，方法的参数就是该接口类型，并通过反射生成一个包含该拓展类实例的包装对象，再通过 injectExtension注入包装对象的依赖。如此循环，得到成Wrapper包装链。这里需注意的是， 配置文件中内容靠后的包装类会包装在相对外层。下面是DUBBO AOP的例子，我们继续使用上面的接口与实现类，同时新增一个实现类，代码如下

package org.alexsotob.dubbo.SPI.wrapper;

import org.alexsotob.dubbo.SPI.Animal;

public class AnimalWrapper implements Animal {
    private Animal animal;
    public AnimalWrapper(Animal animal) {
        this.animal = animal;
    }

    @Override
    public String getName() {
        System.out.println("数据校验");
        String result = animal.getName();
        System.out.println("日志记录");
        return result;
    }
}

 META-INF/dubbo 文件内容修改:

cat=org.alexsotob.dubbo.SPI.impl.Cat
dog=org.alexsotob.dubbo.SPI.impl.Dog
org.alexsotob.dubbo.SPI.wrapper.AnimalWrapper #包装类

 使用之前的测试类测试，结果如下

 与我们预想的一致，实现了Wrapper类的切面功能

如果有什么不正确的地方，希望能够得到大家的纠正

本文参考了博客（注：大量的copy了别人的东西，因为该博主写得很优秀）

http://blog.itpub.net/31559758/viewspace-2678246/

 

 

妖四灵.Shuen
关注
专栏目录
dubbo源码分析
07-27
公司同事分享的dubbo源码分析，非常好非常好非常好非常好非常好！
dubbo原理
weixin_36936504的博客
05-11 744
一、什么是dubbo Dubbo是Alibaba开源的分布式服务框架，它最大的特点是按照分层的方式来架构，使用这种方式可以使各个层之间解耦合（或者最大限度地松耦合）。从服务模型的角度来看， Dubbo采用的是一种非常简单的模型，要么是提供方提供服务，要么是消费方消费服务，所以基于这一点可以抽象出服务提供方（Provider）和服务消费方（Consumer）两个角色。关于注册中心、协议支持、服务监控等内容，详见后面描述。 Webservice也是一种服务框架，但是webservice并不是分布式的服务框架，
Dubbo源码深度解析(一)
weixin_41338970的博客
07-31 1069
本博客讲的是Dubbo源码，将分为几篇，本篇主要聊的是Dubbo如何跟SpringBoot整合，以及Dubbo中提供的一些注解的作用，还包括相关配置信息的读取以及绑定等。
dubbo深入理解
u014645192的博客
09-11 491
dubbo是什么？ Dubbo是阿里巴巴开源的，一个基于Java语言的高性能分布式RPC框架，现在已经成为apache的顶级项目。 1.NIO单一长连接——dubbo通信模型实现 https://www.jianshu.com/p/13bef2795c44 2.dubbo角色： provider:服务提供者 cotainer:dubbo自带容器 register：服务注册中心 consummer：...
【中间件】深入理解dubbo
阿杰
08-15 515
随着互联网的发展，单一架构、垂直应用架构已经无法满足需求，分布式服务架构势在必行，但是分布式服务自身存在的问题要求有一个分布式治理系统来管理 需求 当服务越来越多时，服务 URL 配置管理变得非常困难，F5 硬件负载均衡器的单点压力也越来越大，就需要一个服务注册中心来管理这些服务，推荐使用zookeeper 架构 生产者启动之后将自己注册到注册中心，然后消费者去注册中心订阅服务，将服务列表缓存在本地缓存中，每次注册中心的服务更新时会通知消费者更新本地缓存，同时Monitor检测消费者和生产者的变化，消
dubbo原理深入剖析
drhrht的博客
04-01 406
一.dubbo架构 节点角色说明： Provider: 暴露服务的服务提供方。 Consumer: 调用远程服务的服务消费方。 Registry: 服务注册与发现的注册中心。 Monitor: 统计服务的调用次调和调用时间的监控中心。 Container: 服务运行容器。 调用关系说明： 0. 服务容器负责启动，加载，运行服务提供者。 1. 服务提供者在启动时，向注册中心注册自己提供的服务。 2. 服务消费者在启动时，向注册中心订阅自己所需的服务。 3. 注册中心返回服务提供者地址列表给消费者，如果有变更
dubbo spi可扩展机制源码解析
12-24
下面我们将深入剖析Dubbo SPI的源码，了解其实现原理。 首先，我们要理解SPI的核心概念：接口、实现类和服务发现。在Java世界中，SPI允许开发者定义一个接口，然后提供多个实现该接口的类，系统在运行时会自动发现...
Dubbo SPI 机制 代码实现，dubbo-2.6.0 源码
03-14
dubbo-2.6.0 源码
深度解析Dubbo的可扩展机制SPI源码：从理论到实践，打造高效、稳定的分布式服务框架
01-11
了解了Dubbo SPI的基本原理后，我们可以通过实际案例来加深理解。比如，我们可以定义一个自定义的协议扩展，编写对应的实现类，然后在配置文件中注册。在运行时，Dubbo会自动发现并使用这个新的协议。 总的来说，...
Dubbo源码分析之SPI
01-31
SPI，全称Service Provider Interface，是Java提供的...在深入研究`dubbo-spi`和`java-spi`这两个文件夹中的源码，我们可以更深入地了解这两套SPI机制的实现细节和差异，这对于提升我们的Java和Dubbo开发技能大有裨益。
Dubbo SPI机制
Rylynn_plus的博客
01-14 292
简述Dubbo SPI机制
dubbo的深入学习（2）
枕着猫咪睡觉的王子
09-12 1252
dubbo,soa,异步调用，NIO,序列化,
深入理解dubbo之服务发布源码分析
XuNeely的博客
12-15 235
dubbo 是阿里开源的一个分布式服务框架，它的最大特点是按照分层的方式来架构，使各层之间充分解耦，并且它是无侵入性的，dubbo可以无缝与spring整合，更重要的是dubbo还提供了强大的容错和监控功能。 对于业务方来说，dubbo使用上手足够简单，调用过程对业务方透明，对开发人员友好。 分析它？那么多模块6-7个人一起开发，要一篇文章就能看懂，这纯属开玩笑啊！直接看视频教程，一看全懂！！！...
dubbo源码深度分析：62个文档+中文注释+流程图+思维导图
田维常
10-10 587
你好，我是田哥为满足群里大部分同学的需求，国庆期间，我重新对Dubbo源码进行梳理，一共7个内容：1、Dubbo核心知识总结2、Dubbo源码分析指南3、Dubbo服务发布流程4、Dubbo服务调用流程5、Dubbo中文版注释6、共62节Dubbo文档7、看Dubbo源码必备的知识点咱们话不多说，直接看内容。Dubbo核心知识总结Dubbo源码分析指南Dubbo服务发布流程Dubbo服务调用流程D...
dubbo源码深度解析_SpringBoot源码深度解析
weixin_39834984的博客
11-25 187
Spring开源框架，解决企业级开发的复杂性的问题，简化开发AOP， IOCSpring 配置越来多，配置不方便管理！Javaweb---Servlet+tomcat + Struct2 SpringMVC SPRINGboot.....所有的技术框架：从一个复杂的场景慢慢的衍生出来一种规范！简单的配置！==SpringBoot ：自动配置！==Springboot怎么自动配置，核心...
深度解析dubbo源码系列
热门推荐
猿上生活
07-27 1万+
以下文章均基于dubbo v2.6.1 持续更新中… dubbo spi 扩展技术，框架基石 《深度解析dubbo扩展技术dubbo spi(注解)》 《深度解析dubbo扩展技术dubbo spi(实现二)》 《深度解析dubbo扩展技术dubbo spi(自适应实现)》 《深度解析dubbo扩展技术dubbo spi(自动激活实现)》 服务暴露 《深度解析dubbo服务本地暴露(injvm)》 《深度解析dubbo服务远程暴露(一)》 《深度解析dubbo服务远程暴露(二)》 《深度解析dubbo
Dubbo源码深度解析(四)
weixin_41338970的博客
08-12 630
因此，调用PROXY_FACTORY#getInvoker()方法，实际上是调用ProxyFactory$Adaptive#getInvoker()方法，如果传入的url中，proxy属性(可以在@DubboService注解上指定)不为空，则获取属性值，如果为空，则用默认的值"javassist"，最终调用。这块就是Netty Server启动的核心，也是固定写法，任何一个框架，使用Netty作为其通讯框架，大概都是这样写，没什么好讲的，如果对 Netty框架感兴趣，不妨看我写的这篇博客《
Dubbo源码深度解析(七)
最新发布
weixin_41338970的博客
08-21 669
核心就是ReferenceAnnotationBeanPostProcessor类，最终会生成一个对应的ReferenceBean对象，并放入Spring容器，当然最终给属性进行依赖注入的并非ReferenceBean对象，而是它的 ref属性，如果该属性为空，就需要调用Protocol#refer()方法(Dubbo的SPI机制找到Protocol接口的实现类，调用实现类的ref()方法)创建Invoker，最终生成代理对象还没讲到，这篇博客会讲到。到这里为止，生成Invoker对象的逻辑讲完了。
Dubbo源码探索：SPI机制与Netty粘包拆包解析
在深入解析Dubbo源码之前，我们先了解一下Dubbo的基本概念。Dubbo是一个高性能、轻量级的开源Java RPC框架，它提供了丰富的服务治理功能，包括服务注册、服务发现、负载均衡、熔断降级等。其设计目标是使服务更易于...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值