dubbo-dubbo spi详解

已于 2022-09-27 22:43:49 修改
阅读量1.2k 收藏 4
点赞数 1
分类专栏： dubbo 文章标签： dubbo
于 2022-09-27 22:40:48 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/tdt008/article/details/127067171
版权

1. dubbo spi介绍

Dubbo 按照 SPI 配置文件的用途，将spi配置文件目录分成了三类目录：

  1. META-INF/services/ 目录：该目录下的 SPI 配置文件用来兼容 JDK SPI
  2. META-INF/dubbo/ 目录：该目录用于存放用户自定义 SPI 配置文件
  3. META-INF/dubbo/internal/ 目录：该目录用于存放 Dubbo 内部使用的 SPI 配置文件。

然后Dubbo 将 SPI 配置文件改成了 KV 格式，例如:

dubbo=org.apache.dubbo.rpc.protocol.dubbo.DubboProtocol

中 key 被称为扩展名（也就是 ExtensionName），当我们在为一个接口查找具体实现类时，可以指定扩展名来选择相应的扩展实现。例如接口org.apache.dubbo.rpc.Protocol有几个实类，这里指定扩展名为 dubbo，Dubbo SPI 就知道我们要使用：org.apache.dubbo.rpc.protocol.dubbo.DubboProtocol 这个扩展实现类，只实例化这一个扩展实现即可，无须实例化 SPI 配置文件中的其他扩展实现类。使用 KV 格式的 SPI 配置文件的另一个好处是：让我们更容易定位到问题。假设我们使用的一个扩展实现类所在的 jar 包没有引入到项目中，那么 Dubbo SPI 在抛出异常的时候，会携带该扩展名信息，而不是简单地提示扩展实现类无法加载。这些更加准确的异常信息降低了排查问题的难度，提高了排查问题的效率。

2. @SPI注解

dubbo 中某个接口被 @SPI注解修饰时，就表示该接口是扩展接口，如：

@SPI(value = "dubbo", scope = ExtensionScope.FRAMEWORK)
public interface Protocol {
}

相应配置文件为：

dubbo=org.apache.dubbo.rpc.protocol.dubbo.DubboProtocol

@SPI 注解的 value 值指定了默认的扩展名称，例如，在通过 Dubbo SPI 加载 Protocol 接口实现类时，如果SPI配置文件目录下org.apache.dubbo.rpc.Protocol文件中没有明确指定扩展名，则默认会将接口org.apache.dubbo.rpc.Protocol上 @SPI 注解的 value 值作为扩展名．以上为例即加载 dubbo 这个扩展名对应的 org.apache.dubbo.rpc.protocol.dubbo.DubboProtocol 这个扩展实现类。

dubbo　spi应用示例（配置文件和前面的一模一样，省略）：

ExtensionLoader<Protocol> extensionLoader = ApplicationModel.defaultModel()
	.getDefaultModule().getExtensionLoader(Protocol.class);
Protocol protocol = extensionLoader.getExtension("dubbo");

ExtensionLoader的核心字段：

public class ExtensionLoader<T> {
	 /**
     * 缓存了扩展实现类与其实例对象的映射关系。在前文示例中，Key 为 Class，Value为接口实例对象
     * 如果： key： class org.apache.dubbo.rpc.protocol.dubbo.DubboProtocol
     *      value为DubboProtocol实例对象
     *
     */
    private final ConcurrentMap<Class<?>, Object> extensionInstances = new ConcurrentHashMap<>(64);
    /**
     * 当前ExtensionLoader实例负责加载的扩展spi接口class
     */
    private final Class<?> type;
    /**
     * 缓存了该ExtensionLoader实例对象加载的spi接口的所有的扩展实现类与扩展名之间的映射关系：
     * 如：   key                                                                 value
     *      {Class@1826} "class org.apache.dubbo.rpc.protocol.rest.RestProtocol" -> rest
     *      {Class@1835} "class org.apache.dubbo.rpc.protocol.injvm.InjvmProtocol" -> injvm
     *      {Class@1828} "class org.apache.dubbo.registry.integration.InterfaceCompatibleRegistryProtocol" -> registry
     *      {Class@1832} "class org.apache.dubbo.rpc.support.MockProtocol" -> mock
     *      {Class@1827} "class org.apache.dubbo.registry.integration.RegistryProtocol" -> service-discovery-registry
     *      {Class@1829} "class org.apache.dubbo.rpc.protocol.dubbo.DubboProtocol" -> dubbo
     */
    private final ConcurrentMap<Class<?>, String> cachedNames = new ConcurrentHashMap<>();
    /**
     * 缓存了该 ExtensionLoader 加载的扩展名与扩展实现类之间的映射关系。cachedNames 集合的反向关系缓存
     */
    private final Holder<Map<String, Class<?>>> cachedClasses = new Holder<>();
     /**
     * 缓存了该ExtensionLoader加载的扩展名与扩展实现对象Holder之间的映射关系：
     *  这里如： key                    value
     *          dubbo                  Holder实例对象（ProtocolSerializationWrapper<ProtocolFilterWrapper<ProtocolListenerWrapper<DubboProtocol>>>）
     */
    private final ConcurrentMap<String, Holder<Object>> cachedInstances = new ConcurrentHashMap<>();
    private final Holder<Object> cachedAdaptiveInstance = new Holder<>();
    private volatile Class<?> cachedAdaptiveClass = null;
    /**
     * spi接口上@SPI注解的value值，也就是默认扩展名
     */
    private String cachedDefaultName;
     /**
     * LoadingStrategy接口有三个实现类都通过JDK SPI的方式加载，在dubbo-common项目的META_INF/services目录下创建了该接口的spi配置文件，
     * 文件中列出了实现的接口类，有如下三个：
     * org.apache.dubbo.common.extension.DubboInternalLoadingStrategy 加载META-INF/dubbo/internal/目录下的spi配置文件
     * org.apache.dubbo.common.extension.DubboLoadingStrategy   加载META-INF/dubbo/目录下的spi配置文件
     * org.apache.dubbo.common.extension.ServicesLoadingStrategy 兼容jdk，加载META-INF/services/目录下的配置文件
     */
    private static volatile LoadingStrategy[] strategies = loadLoadingStrategies();
}

ExtensionDirector#getExtensionLoader方法分析：

public <T> ExtensionLoader<T> getExtensionLoader(Class<T> type) {
        checkDestroyed();
   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)) {
       throw new IllegalArgumentException("Extension type (" + type +
           ") is not an extension, because it is NOT annotated with @" + SPI.class.getSimpleName() + "!");
   }
    // 1. find in local cache
    ExtensionLoader<T> loader = (ExtensionLoader<T>) extensionLoadersMap.get(type);
    ExtensionScope scope = extensionScopeMap.get(type);
    if (scope == null) {
        SPI annotation = type.getAnnotation(SPI.class);
        scope = annotation.scope();
        extensionScopeMap.put(type, scope);
    }
    if (loader == null && scope == ExtensionScope.SELF) {
         // create an instance in self scope
         loader = createExtensionLoader0(type);
     }
     // 2. find in parent
     if (loader == null) {
         if (this.parent != null) {
             loader = this.parent.getExtensionLoader(type);
         }
     }
     // 3. create it
     if (loader == null) {
         loader = createExtensionLoader(type);
     }
     return loader;
 }
 private <T> ExtensionLoader<T> createExtensionLoader(Class<T> type) {
     ExtensionLoader<T> loader = null;
      if (isScopeMatched(type)) {
          // if scope is matched, just create it
          loader = createExtensionLoader0(type);
      }
      return loader;
  }
// 创建ExtensionLoader
private <T> ExtensionLoader<T> createExtensionLoader0(Class<T> type) {
        checkDestroyed();
    ExtensionLoader<T> loader;
    //　实例化ExtensionLoader，并放入map暂存
    extensionLoadersMap.putIfAbsent(type, new ExtensionLoader<T>(type, this, scopeModel));
    loader = (ExtensionLoader<T>) extensionLoadersMap.get(type);
    return loader;
}
//　构造方法
ExtensionLoader(Class<?> type, ExtensionDirector extensionDirector, ScopeModel scopeModel) {
    this.type = type;
    this.extensionDirector = extensionDirector;
    this.extensionPostProcessors = extensionDirector.getExtensionPostProcessors();
    initInstantiationStrategy();
    this.injector = (type == ExtensionInjector.class ? null : extensionDirector.getExtensionLoader(ExtensionInjector.class)
        .getAdaptiveExtension());
    this.activateComparator = new ActivateComparator(extensionDirector);
    this.scopeModel = scopeModel;
}

得到接口对应的 ExtensionLoader 对象之后会调用其 getExtension() 方法，根据传入的扩展名称返回相应的实例对象，　ExtensionLoader＃getExtension()：

public T getExtension(String name) {
	//　核心方法
    T extension = getExtension(name, true);
    if (extension == null) {
        throw new IllegalArgumentException("Not find extension: " + name);
    }
    return extension;
}

public T getExtension(String name, boolean wrap) {
    checkDestroyed();
    if (StringUtils.isEmpty(name)) {
        throw new IllegalArgumentException("Extension name == null");
    }
    if ("true".equals(name)) {
        return getDefaultExtension();
    }
    String cacheKey = name;
    if (!wrap) {
        cacheKey += "_origin";
    }
    //　实例对象封装在了Holder里面
    final Holder<Object> holder = getOrCreateHolder(cacheKey);
    Object instance = holder.get();
    if (instance == null) {
        synchronized (holder) {
            instance = holder.get();
            if (instance == null) {
            	//　执行创建扩展实例
                instance = createExtension(name, wrap);
                holder.set(instance);
            }
        }
    }
    return (T) instance;
}

private T createExtension(String name, boolean wrap) {
     // 获取 cachedClasses 缓存，根据扩展名从cachedClasses缓存中获取扩展实现类Class
     // 如果 cachedClasses 未初始化，则会扫描前面介绍的三个 SPI 目录获取查找相应的 SPI 配置文件，然后加载其中的扩展实现类，
     // 最后将扩展名和扩展实现类的映射关系记录到 cachedClasses 缓存中。这部分逻辑在 loadExtensionClasses() 和 loadDirectory() 方法中。
     Class<?> clazz = getExtensionClasses().get(name);
     if (clazz == null || unacceptableExceptions.contains(name)) {
         throw findException(name);
     }
     try {
         // 从extensionInstances里查找
         T instance = (T) extensionInstances.get(clazz);
         // 查找失败
         if (instance == null) {
             // 根据反射创建
             extensionInstances.putIfAbsent(clazz, createExtensionInstance(clazz));
             instance = (T) extensionInstances.get(clazz);
             instance = postProcessBeforeInitialization(instance, name);
             injectExtension(instance);
             instance = postProcessAfterInitialization(instance, name);
         }

         // 自动包装
         if (wrap) {
             List<Class<?>> wrapperClassesList = new ArrayList<>();
             if (cachedWrapperClasses != null) {
                 wrapperClassesList.addAll(cachedWrapperClasses);
                 wrapperClassesList.sort(WrapperComparator.COMPARATOR);
                 Collections.reverse(wrapperClassesList);
             }

             if (CollectionUtils.isNotEmpty(wrapperClassesList)) {
                 for (Class<?> wrapperClass : wrapperClassesList) {
                     Wrapper wrapper = wrapperClass.getAnnotation(Wrapper.class);
                     boolean match = (wrapper == null) ||
                         ((ArrayUtils.isEmpty(wrapper.matches()) || ArrayUtils.contains(wrapper.matches(), name)) &&
                             !ArrayUtils.contains(wrapper.mismatches(), name));
                     if (match) {
                         instance = injectExtension((T) wrapperClass.getConstructor(type).newInstance(instance));
                         instance = postProcessAfterInitialization(instance, name);
                     }
                 }
             }
         }

         // Warning: After an instance of Lifecycle is wrapped by cachedWrapperClasses, it may not still be Lifecycle instance, this application may not invoke the lifecycle.initialize hook.
         initExtension(instance);
         return instance;
     } catch (Throwable t) {
         throw new IllegalStateException("Extension instance (name: " + name + ", class: " +
             type + ") couldn't be instantiated: " + t.getMessage(), t);
     }
 }

3. JDK SPI 、dubbo spi 、spring spi的比较

JDK SPI: 每个扩展点单独一个文件;只能通过ServiceLoader的迭代器遍历获取扩展实现类，同时也会加载所有实现类，这样就会把用不到的类也会进行实例化，浪费一定资源；是java自带实现，不需要引入第三方依赖可直接使用．

dubbo spi:每个扩展点一个配置文件，文件名为接口的全限定名．支持别名的概念，可以通过别名获取某个具体扩展点的实现．配置文件的内容为key=value形式，key是别名，value是实现类的全限定名．

spring spi: spring指定配置文件为classpath下的META-INF/spring.factories, 所有的扩展点配置都放到这个文件中．配置文件内容为key=value的形式，key为接口的全限定名，value为实现类的全限定名，可以为多个．

代码羊羊
关注
  • 1
    点赞
  • 踩
  • 4
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
Dubbo-SPI
justimkiss的专栏
11-06 455
SPI1. 定义 SPI即Service Provider Interface，服务提供接口。 ​ 系统中抽象的各个模块，往往有很多不同的实现方案，比如日志模块，xml解析模块，jdbc模块的方案等。面向对象的设计里，我们一般推荐模块之间基于接口编程，模块之间不对实现类进行硬编码。一旦代码里设计具体的实现类，就违反了可插拔的原则，如果需要替换一种实现，就需要修改代码。​ 为了实现在模块装
dubbo-demo
03-16
7. **SPI（Service Provider Interface）扩展机制**：Dubbo使用Java的SPI机制，允许用户自定义并扩展Dubbo的各种组件和服务行为，增强了框架的灵活性。 8. **QoS（服务质量）管理**：Dubbo提供了QoS参数设置，如...
Dubbo源码学习(九) 详解Dubbo里的SPI
Dream_it_possible！的博客
11-02 1170
SPI是中间件设计不可缺少的一项，SPI能提高应用的可插拔性，SPI的英文全称: Service Provider Implementation, 我们可以在META-INF目录里配置SPI， ServiceLoader会根据配置来找到接口的实现,那Dubbo里的@SPI又是什么呢？Dubbo的Common模块里，定义了一个@SPI注解，该注解在extension包里，作用是标记一个接口为可扩展性的接口，具体的用法在下文里演示，被@SPI标记的接口默认的作用范围ExtensionScope是应用级别的。
Dubbo之SPI、Adaptive机制详解
最新发布
一步一步走
07-11 881
分析了JDK\Spring\Dubbo的SPI机制，并详细分析了Dubbo的 自适应机制的原理和实现
dubbo的SPI详解【很详细***】
weixin_41323270的博客
02-03 833
https://www.cnblogs.com/heart-king/p/5632524.html
【Dubbo的那些SPI接口】
d1451545368的博客
04-22 693
Dubbo中有 @SPI @Adaptive @Activate 三个跟SPI相关的注解@SPI标记这是一个SPI接口@Adaptive作用在SPI接口的成员方法，调用SPI接口方法时根据这个方法的入参字段来决定使用哪个SPI接口实现类@Activate自动激活的实现类。
Dubbo SPI机制详解
weixin_39082432的博客
05-09 1895
什么是SPI？ 扩展点 Dubbo作用灵活的框架，并不会强制所有用户都一定使用Dubbo提供的某些架构。例如注册中心（Registry），Dubbo提供了zk和redis，但是如果我们更倾向于其他的注册中心的话，我们可以替换掉Dubbo提供的注册中心。针对这种可被替换的技术实现点我们称之为扩展点，类似的扩展点有很多，例如Protocol，Filter，Loadbalance等等。 Wrapper Dubbo在加载某个接口的扩展类时候，如果某个实现中有一个拷贝类构造函数，那么该接口实现就是该接口的包装类，
alibaba-dubbo-dubbo-2.5.8-4-gc8093cf.zip_dubbo 2.5_dubbo 2.8.4_d
09-15
《Dubbo 2.5与2.8.4版本详解》 Dubbo是阿里巴巴开源的一款高性能、轻量级的服务治理框架，它主要应用于分布式服务之间的调用，为开发者提供了服务注册、服务发现、负载均衡、容错处理等功能，极大地提高了微服务...
dubbo-master.zip
09-08
《Dubbo核心技术详解》 Dubbo，作为一款高性能、轻量级的开源Java RPC框架，是阿里巴巴集团贡献的优秀中间件之一。它以其强大的服务治理功能、高效的远程调用机制和丰富的扩展性，在微服务架构中占据着重要的地位。...
dubbo-demo微服务示例代码
01-03
【Dubbo-Demo 微服务示例代码详解】 Dubbo 是阿里巴巴开源的一款高性能、轻量级的Java服务框架，主要用于实现分布式服务之间的调用。它提供了丰富的服务治理功能，包括服务注册、服务发现、负载均衡、熔断机制等。...
alibaba-dubbo-v1.2.zip
11-19
《阿里巴巴Dubbo框架详解——基于v1.2版本》 在IT行业中，分布式服务框架是构建大型、高并发系统不可或缺的工具，而阿里巴巴的Dubbo则是一款非常知名的高性能、轻量级的服务治理框架。本文将深入探讨Dubbo v1.2版本...
Dubbo的SPI机制详解
JavaEdge全是干货的技术号
07-09 3307
1 面试题 Dubbo中的SPI是什么？ 2 考点分析 前面基础性的东西问完了，确定你应该了解Dubbo，那么自然问个稍微难的问题，就是SPI，先问问你这是个啥,然后问问你怎么实现的! 其实就是看看你对dubbo的掌握如何 3 SPI简介 SPI 全称为 Service Provider Interface，是一种服务发现机制. 说白了是啥呢，比如你有个接口，该接口有3个实现类，那么在系统运行时,...
Dubbo原理＜一＞ Dubbo SPI详解
qq_32129371的博客
03-17 996
一、SPI 全称为 Service Provider Interface，是一种服务发现机制。SPI 的本质是将接口实现类的全限定名配置在文件中，并由服务加载器读取配置文件，加载实现类。这样可以在运行时，动态为接口替换实现类; 二、JAVA SPI: 默认加载 META-INF/services/接口全限定名 内容为实现类的全限定的类名； 以换行符分隔多个实现类 ServiceLoader<Worker> serviceLoader = ServiceLoader.load(Worker.c
dubbo的SPI
景川的博客
02-13 1330
一. SPI定义 SPI 全称为 Service Provider Interface，一种服务发现机制。SPI 的本质是将接口实现类的全限定名配置在文件中，并由服务加载器读取配置文件，加载实现类。这样可以在运行时，动态为接口替换实现类。正因此特性，我们可以很容易的通过 SPI 机制为我们的程序提供拓展功能。SPI 机制在第三方框架中也有所应用，比如mysql-connector包、spring-web包等，Dubbo 就是通过 SPI 机制加载所有的组件。不过，Dubbo 并未使用 Java 原生的 S
Dubbo SPI
weixin_38829588的博客
01-19 3045
Dubbo SPI使用 SPI简介 SPI 全称为 Service Provider Interface，是一种服务发现机制，刚好与java jdk的类加载机制进行了一个互补。SPI 的本质是将接口实现类的全限定名配置在文件中，并由服务加载器读取配置文件，加载实现类。这样可以在运行时，动态为接口替换实现类。正因此特性，我们可以很容易的通过 SPI 机制为我们的程序提供拓展功能。SPI 机制在第三方框架中也有所应用，比如 Dubbo 就是通过 SPI 机制加载所有的组件。不过，Dubbo ......
dubbo源码之SPI注解
努力就有希望
02-20 2384
一、SPI 注解 @Documented @Retention(RetentionPolicy.RUNTIME) @Target({ElementType.TYPE}) public @interface SPI { String value() default ""; }。Target表明该注解只能用于类、接口（包括注释类型）或枚举声明。 ExtensionLoader的lo
深度解析dubbo扩展技术dubbo spi(注解)
猿上生活
05-24 6495
注：本文dubbo源码版本v2.6.1 1.介绍 由于jdk自身提供的spi技术不满足dubbo框架的需要，dubbo在此基础上做了一定的改进和优化，同时又兼容jdk spi。正是基于dubbo spi加载机制，让整个框架的接口和具体的实现完全解耦，dubbo几乎所有的组件都是基于扩展机制来实现的，是整个框架良好扩展性的基础。它不仅屏蔽了jdk spi的一些短板，而且还增加了对扩展IOC与AOP的功能。在dubbo-common模块的com.alibaba.dubbo.common.extension包中就
Dubbo扩展点注解之@SPI
学无止境
10-26 4130
在Dubbo框架中，@SPI注解都是使用在接口上，它的主要作用是标记这个接口是一个Dubbo SPI扩展点，可以有多个内置或用户定义的实现，运行时通过配置找到具体的实现类。 @Documented @Retention(RetentionPolicy.RUNTIME) @Target({ElementType.TYPE}) public @interface SPI { /** ...
Dubbo微内核基于SPI机制详解
1. SPI机制详解 Java SPI是一种服务发现机制，允许开发者在运行时动态地查找和加载服务实现。服务提供者将实现类的全限定名写入到`META-INF/services/<接口全名>`文件中，服务消费者则可以通过`java.util....
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值