关于Dubbo扩展点加载机制(2)

2018-02-24 10:10:27来源:oschina作者:zlcode人点击

分享

上一章旨在描述扩展点加载关键类的结构,本章重点讲解Dubbo扩展点加载中突出的特性和一些技术细节。


1.JDK spi的增强版


官方给的描述如下:


Dubbo 改进了 JDK 标准的 SPI 的以下问题: JDK 标准的 SPI 会一次性实例化扩展点所有实现,如果有扩展实现初始化很耗 时,但如果没用上也加载,会很浪费资源。 如果扩展点加载失败,连扩展点的名称都拿不到了。比如:JDK 标准的 ScriptEngine,通过 getName() 获取脚本类型的名称,但如果 RubyScriptEngine 因为所依赖的 jruby.jar 不存在,导致 RubyScriptEngine 类 加载失败,这个失败原因被吃掉了,和 ruby 对应不起来,当用户执行 ruby 脚 本时,会报不支持 ruby,而不是真正失败的原因。


2.dubbo中IOC和装饰器模式的实现


dubbo中IOC功能是由ExtensionLoader 中的objectFactory属性完成。上篇描述ExtensionLoader 结构的文章中有提到过objectFactory持有的是AdaptiveExtensionFactory的实例,AdaptiveExtensionFactory是一个自适应的扩展实现,这种自适应的扩展实现并不会真正的去完成实例产生和加载的动作,而是通过关键字使用SpiExtensionFactory和SpringExtensionFactory加载bean ;SpiExtensionFactory 使用ExtensionLoader.getExtensionLoader(type).getAdaptiveExtension() 拿到的仍然是对应接口的自适应扩展类,SpringExtensionFactory则是通过context.getBean(name)获取扩展点实例。目前来看,objectFactory仅在injectExtension方法中使用


dubbo使用装饰器模式最直接的体现是在创建扩展点实例时,如果存在扩展点的包装类时,使用warpper类持有实际的扩展点实现类。


instance = injectExtension((T) wrapperClass.getConstructor(type).newInstance(instance));

从ExtensionLoader中获取到的其实是wrapper类的实例。通过装饰器模式可以将扩展点的公共逻辑移至wrapper类中,不会对具体的扩展点实例造成干扰。有点类似于AOP

最新文章

123

最新摄影

闪念基因

微信扫一扫

第七城市微信公众平台