Dubbo-SPI(一)-加载机制概述

最新推荐文章于 2024-04-22 10:11:18 发布

星光之子0317

最新推荐文章于 2024-04-22 10:11:18 发布

阅读量248

点赞数

分类专栏： Dubbo+Zookeeper 文章标签： dubbo spi 扩展点自适应自动激活

本文链接：https://blog.csdn.net/weixin_38405646/article/details/115589290

版权

31 篇文章 6 订阅

订阅专栏

Dubbo-SPI系列文章目录

Java SPI 使用了策略模式，一个接口多种实现
只需要声明接口
具体的实现并不在程序中直接确定
而是由程序之外的配置掌控，用于具体实现的装配
步骤如下：

Java SPI 会一次性实例化扩展点的所有实现，扩展实现可能很耗时，也可能用不上，会浪费资源
如果扩展加载失败，连扩展的名称都获取不到，异常信息也可能会被 “吞掉”，问题追踪比较困难；Dubbo SPI 在扩展加载失败的时候会先抛出真实异常并打印日志，扩展点在被动加载的时候，即使有部分扩展加载失败也不会影响其他扩展点和整个框架的使用
Dubbo SPI 增加了对扩展的 IOC 和 AOP 支持，一个扩展可以直接setter注入其他扩展
Dubbo SPI 只是加载配置文件中的类，并分成不同种类的缓存放在内存中，而不会立即全部初始化，在性能上会有更好的表现
Dubbo SPI 支持包装扩展类，推荐把通用的抽象逻辑放在包装类中，用于实现扩展点的AOP特性。这和Spring的动态代理思想一样，在被代理类的前后插入自己的逻辑进行增强

规范名	规范说明
SPI配置文件路径	META-INF/services（兼容Java SPI）、META-INF/dubbo/（用户扩展）、META-INF/dubbo/internal （Dubbo内部使用）
SPI配置文件名称	全路径类名
文件内容格式	key=value，多个用换行符分隔

被缓存的Class和对象实例可以根据不同的特性分别不同的类别

普通扩展类：最基础的，配置在SPI配置文件中的扩展类实现
包装扩展类：这种Wrapper(包装)类没有具体的实现逻辑，只是做了通过逻辑的抽象，并且需要 在构造方法中 传入一个具体的扩展接口的实现
自适应扩展类：一个扩展接口会有多种实现类，具体使用哪个，可以不写死在配置或者代码中，在运行时，通过传入URL对象中的某些参数parameter来动态确定，相关注解是@Adaptive
其他缓存：扩展类加载器缓存、扩展名缓存

集合名	缓存类型
Holder<Map<String,Class<?>>> cachedClasses	普通扩展类缓存，不包括自适应扩展类和包装扩展类
Set<Class<?>> cachedWrapperClasses	包装扩展类缓存
Class<?> cachedAdaptiveClass	自适应扩展类缓存，只能同时存在一个
Map<Stirng, Activate> cachedActivates	扩展名与 @Activate(自动激活)的缓存
ConcurrendMap<Class<?>, ExtensionLoader<?>> EXTESION_LOADERS	扩展类与对应的类加载器缓存
ConcurrendMap<Class<?>, String> cachedNames	扩展类与扩展名缓存

集合名	缓存类型
Holder<Obejct> cachedAdaptiveInstance	实例化后的自适应扩展类的对象，只能同时存在一个
ConcurrendMap<Sting, Holder<Object>> cachedInstances	扩展名与扩展对象实例缓存
ConcurrendMap<Class<?>, Object> EXTESION_INSTANCES	扩展类与类初始化后的实例

ExtensionLoader在加载扩展时，如果发现这个扩展类 包含其他扩展点作为构造函数的参数，则这个扩展类就会被认为是封装类

如果某个扩展类是另外一个扩展类的成员属性，并且拥有setter方法，那么框架也会自动注入对应的扩展点实例。

使用@Adaptive注解，可以 动态地通过URL中的参数来确定要使用哪一个具体的实现类，从而解决自动加载中的实例注入问题

使用@Activate注解，可以标记对应的扩展点默认被激活启用，这个注解还可以通过传入不同的参数，设置扩展点在不同的条件下被自动激活
主要使用场景是某个扩展点的 多个实现类需要同时启用

关注