Dubbo源码之SPI以及自己的IOC和AOP

简介: Dubbo源码之SPI以及自己的IOC和AOP

什么是SPI?

spi,简单来说,就是service provider interface,说白了是什么意思呢,比如你有个接口,现在这个接口有3个实现类,那么在系统运行的时候对这个接口到底选择哪个实现类呢?这就需要spi了,需要根据指定的配置或者是默认的配置,去找到对应的实现类加载进来,然后用这个实现类的实例对象

 

为什么dubbo要自己设计一套SPI?

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

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

这是原始JDK spi的代码

ServiceLoader<Command> serviceLoader=ServiceLoader.load(Command.class); 
  for(Command command:serviceLoader){  
      command.execute();  
  }

dubbo在原来的基础上设计了以下功能

1.原始JDK spi不支持缓存;dubbo设计了缓存对象:spi的key与value 缓存在 cachedInstances对象里面,它是一个ConcurrentMap

2.原始JDK spi不支持默认值,dubbo设计默认值:@SPI("dubbo") 代表默认的spi对象,例如Protocol的@SPI("dubbo")就是 DubboProtocol,

 通过 ExtensionLoader.getExtensionLoader(Protocol.class).getDefaultExtension()那默认对象

3.jdk要用for循环判断对象,dubbo设计getExtension灵活方便,动态获取spi对象,

 例如 ExtensionLoader.getExtensionLoader(Protocol.class).getExtension(spi的key)来提取对象

4.原始JDK spi不支持 AOP功能,dubbo设计增加了AOP功能,在cachedWrapperClasses,在原始spi类,包装了XxxxFilterWrapper XxxxListenerWrapper

5.原始JDK spi不支持 IOC功能,dubbo设计增加了IOC,通过构造函数注入,代码为:wrapperClass.getConstructor(type).newInstance(instance),

 

dubbo SPI有哪些约定?

spi 文件 存储路径 在 META-INF\dubbo\internal 目录下 并且文件名为接口的全路径名 就是=接口的包名+接口名 每个spi 文件里面的格式定义为: 扩展名=具体的类名,例如 dubbo=com.alibaba.dubbo.rpc.protocol.dubbo.DubboProtoco

 

这篇文章对spi机制讲的比较清楚

JAVA拾遗--关于SPI机制 https://www.cnkirito.moe/spi/

 

dubbo spi 的目的:获取一个指定实现类的对象

途径:ExtensionLoader.getExtension(String name)

实现路径:

getExtensionLoader(Class<T> type) 就是为该接口new 一个ExtensionLoader,然后缓存起来。

getAdaptiveExtension() 获取一个扩展类,如果@Adaptive注解在类上就是一个装饰类;如果注解在方法上就是一个动态代理类,例如Protocol$Adaptive对象。

getExtension(String name) 获取一个指定对象。

-----------------------ExtensionLoader.getExtensionLoader(Class<T> type)

ExtensionLoader.getExtensionLoader(Container.class)

 -->this.type = type;

 -->objectFactory = (type == ExtensionFactory.class ? null : ExtensionLoader.getExtensionLoader(ExtensionFactory.class).getAdaptiveExtension());

    -->ExtensionLoader.getExtensionLoader(ExtensionFactory.class).getAdaptiveExtension()

      -->this.type = type;

      -->objectFactory =null;

     

执行以上代码完成了2个属性的初始化

1.每个一个ExtensionLoader都包含了2个值 type 和 objectFactory

 Class<?> type;//构造器  初始化时要得到的接口名

 ExtensionFactory objectFactory//构造器  初始化时 AdaptiveExtensionFactory[SpiExtensionFactory,SpringExtensionFactory]

2.new 一个ExtensionLoader 存储在ConcurrentMap<Class<?>, ExtensionLoader<?>> EXTENSION_LOADERS

关于这个objectFactory的一些细节:

1.objectFactory就是ExtensionFactory,它也是通过ExtensionLoader.getExtensionLoader(ExtensionFactory.class)来实现的,但是它的objectFactory=null

2.objectFactory作用,它就是为dubbo的IOC提供所有对象。

     

为什么要设计adaptive?注解在类上和注解在方法上的区别?

adaptive设计的目的是为了识别固定已知类和扩展未知类。

1.注解在类上:代表人工实现,实现一个装饰类(设计模式中的装饰模式),它主要作用于固定已知类,

 目前整个系统只有2个,AdaptiveCompiler、AdaptiveExtensionFactory。

 a.为什么AdaptiveCompiler这个类是固定已知的?因为整个框架仅支持Javassist和JdkCompiler。

 b.为什么AdaptiveExtensionFactory这个类是固定已知的?因为整个框架仅支持2个objFactory,一个是spi,另一个是spring

2.注解在方法上:代表自动生成和编译一个动态的Adpative类,它主要是用于SPI,因为spi的类是不固定、未知的扩展类,所以设计了动态$Adaptive类.

例如 Protocol的spi类有 injvm dubbo registry filter listener等等 很多扩展未知类,

它设计了Protocol$Adaptive的类,通过ExtensionLoader.getExtensionLoader(Protocol.class).getExtension(spi类);来提取对象

 

-----------------------getAdaptiveExtension()

-->getAdaptiveExtension()//为cachedAdaptiveInstance赋值

 -->createAdaptiveExtension()

   -->getAdaptiveExtensionClass()

     -->getExtensionClasses()//为cachedClasses 赋值

       -->loadExtensionClasses()

         -->loadFile

     -->createAdaptiveExtensionClass()//自动生成和编译一个动态的adpative类,这个类是一个代理类

       -->ExtensionLoader.getExtensionLoader(com.alibaba.dubbo.common.compiler.Compiler.class).getAdaptiveExtension()

       -->compiler.compile(code, classLoader)

   -->injectExtension()//作用:进入IOC的反转控制模式,实现了动态入注

       

         

关于loadfile的一些细节

目的:通过把配置文件META-INF/dubbo/internal/com.alibaba.dubbo.rpc.Protocol的内容,存储在缓存变量里面。

cachedAdaptiveClass//如果这个class含有adative注解就赋值,例如ExtensionFactory,而例如Protocol在这个环节是没有的。

cachedWrapperClasses//只有当该class无adative注解,并且构造函数包含目标接口(type)类型,

                                                                例如protocol里面的spi就只有ProtocolFilterWrapper和ProtocolListenerWrapper能命中

cachedActivates//剩下的类,包含Activate注解

cachedNames//剩下的类就存储在这里。

-----------------------getExtension(String name)

getExtension(String name) //指定对象缓存在cachedInstances;get出来的对象wrapper对象,例如protocol就是ProtocolFilterWrapper和ProtocolListenerWrapper其中一个。

 -->createExtension(String name)

   -->getExtensionClasses()

   -->injectExtension(T instance)//dubbo的IOC反转控制,就是从spi和spring里面提取对象赋值。

     -->objectFactory.getExtension(pt, property)

       -->SpiExtensionFactory.getExtension(type, name)

         -->ExtensionLoader.getExtensionLoader(type)

         -->loader.getAdaptiveExtension()

       -->SpringExtensionFactory.getExtension(type, name)

         -->context.getBean(name)

   -->injectExtension((T) wrapperClass.getConstructor(type).newInstance(instance))//AOP的简单设计

   

dubboSPI总结:


相关文章
|
2月前
|
Java 数据库连接 应用服务中间件
Spring5源码(39)-Aop事物管理简介及编程式事物实现
Spring5源码(39)-Aop事物管理简介及编程式事物实现
24 0
|
3月前
|
存储 负载均衡 Dubbo
深入理解Dubbo-4.Dubbo扩展SPI
深入理解Dubbo-4.Dubbo扩展SPI
76 1
|
4月前
|
缓存 Dubbo Java
趁同事上厕所的时间,看完了 Dubbo SPI 的源码,瞬间觉得 JDK SPI 不香了
趁同事上厕所的时间,看完了 Dubbo SPI 的源码,瞬间觉得 JDK SPI 不香了
|
4月前
|
Dubbo Java 应用服务中间件
从源码全面解析 dubbo 服务端服务调用的来龙去脉
从源码全面解析 dubbo 服务端服务调用的来龙去脉
|
3月前
|
缓存 Dubbo Java
Dubbo 第三节_ Dubbo的可扩展机制SPI源码解析
Dubbo会对DubboProtocol对象进⾏依赖注⼊(也就是⾃动给属性赋值,属性的类型为⼀个接⼝,记为A接⼝),这个时候,对于Dubbo来说它并不知道该给这个属性赋什么值,换句话说,Dubbo并不知道在进⾏依赖注⼊时该找⼀个什么的的扩展点对象给这个属性,这时就会预先赋值⼀个A接⼝的⾃适应扩展点实例,也就是A接⼝的⼀个代理对象。在调⽤getExtension去获取⼀个扩展点实例后,会对实例进⾏缓存,下次再获取同样名字的扩展点实例时就会从缓存中拿了。Protocol是⼀个接。但是,不是只要在⽅法上加了。
|
2月前
|
Java 测试技术 开发者
探究 Spring Boot 的核心:IOC 和 AOP
Spring Boot 作为一种简化 Spring 应用开发的工具,继承了 Spring 框架的核心概念,其中最重要的是控制反转(IOC)和面向切面编程(AOP)。它们是 Spring 框架的基础,同时也深深植根于 Spring Boot 中。本文将讨论 IOC 和 AOP 的概念以及它们在 Spring Boot 中的应用。
60 4
|
2月前
|
XML 缓存 Dubbo
Dubbo的魔法之门:深入解析SPI扩展机制【八】
Dubbo的魔法之门:深入解析SPI扩展机制【八】
30 0
|
2月前
Spring5源码(31)-基于@AspectJ的AOP
Spring5源码(31)-基于@AspectJ的AOP
21 0
|
2月前
|
Java Spring
Spring5源码(30)-基于Schema的AOP
Spring5源码(30)-基于Schema的AOP
19 0
|
2月前
|
Java Spring
Spring5源码(28)-Aop知识点回顾以及基于Advice接口的增强实现
Spring5源码(28)-Aop知识点回顾以及基于Advice接口的增强实现
30 0