码迷,mamicode.com
首页 > 其他好文 > 详细

从ExtensionLoader理解Dubbo扩展机制

时间:2017-01-22 16:27:26      阅读:510      评论:0      收藏:0      [点我收藏+]

标签:注入   actor   多个   size   start   文件名   search   hint   rpc   

Dubbo的扩展机制是怎么实现的?最简单的回答就是@SPI. Dubbo的插件化思路来源于Java SPI.
 
JAVA SPI 机制
    SPI的全名为Service Provider Interface. 大多数人可能不了解,因为它是JDK针对插件或者厂商的。java spi机制的思想就是:
我们的系统的抽象模块(接口),往往有很多不同方案的实现。如日志模块,jdbc模块等。而在面向对象的设计里,我们一般都要做模块解耦,面向接口编程。但如果要切换接口的不同实现,就可能需要改动代码。为了实现模块的自动装配而不硬编码,就需要一种服务发现机制,这就有了java spi.
    java spi 约定:当我们实现了一个接口,在jar包的 META-INF/services 目录下放一个以该接口命名的文件,文件的内容是 该接口的具体实现类。当外部程序装配jar包时,就通过这个文件找到具体的实现类,完成模块的注入。而这个服务发现的过程就用的是 java.util.ServiceLoader.
 
JAVA SPI 举例
接口:
package com.my.spi; 
public interface Search {  
   public List serch(String keyword);  
} 
实现:
        A的实现:com.A.spi.impl.FileSearch
        B的实现:  com.B.spi.impl.DBSearch
文件:
        A- jar包 META-INF/services目录下文件com.my.spi.Search 内容为:com.A.spi.impl.FileSearch
        B- jar包 META-INF/services目录下文件com.my.spi.Search 内容为:com.B.spi.impl.DBSearch
使用:    
package com.xyz.factory;  
import java.util.Iterator;  
import java.util.ServiceLoader;  
import my.xyz.spi.Search;  
public class SearchFactory {  
    private SearchFactory() {  
    }  
    public static Search newSearch() {  
        Search search = null;  
        ServiceLoader<Search> serviceLoader = ServiceLoader.load(Search.class);  
        Iterator<Search> searchs = serviceLoader.iterator();  
        if (searchs.hasNext()) {  
            search = searchs.next();  
        }  
        return search;  
    }  
}  

 

  1. package my.xyz.test;  
    import java.util.Iterator;  
    import java.util.ServiceLoader;  
    import com.xyz.factory.SearchFactory;  
    import my.xyz.spi.Search;  
    public class SearchTest {  
        public static void main(String[] args) {  
            Search search = SearchFactory.newSearch();  
            search.serch("java spi test");  
        }  
    }  

 

Dubbo的扩展点机制:ExtensionLoader和SPI
Dubbo的扩展点加载从JDK标准的SPI(Service Provider Interface)扩展点发现机制加强而来。

Dubbo改进了JDK标准的SPI的以下问题:

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

Dubbo提供了一个@SPI  扩展注解,它达到的功能和java的spi一样,不过它的服务发现用的不是 ServiceLoader,而是自己实现的ExtensionLoader.

约定:

在扩展类的jar包内,放置扩展点配置文件:META-INF/dubbo/接口全限定名,内容为:配置名=扩展实现类全限定名,多个实现类用换行符分隔。

(注意:这里的配置文件是放在你自己的jar包内,不是dubbo本身的jar包内,Dubbo会全ClassPath扫描所有jar包内同名的这个文件,然后进行合并)

扩展Dubbo的协议示例:

在协议的实现jar包内放置文本文件:META-INF/dubbo/com.alibaba.dubbo.rpc.Protocol,内容为:

xxx=com.alibaba.xxx.XxxProtocol

实现类内容:

package com.alibaba.xxx;
 
import com.alibaba.dubbo.rpc.Protocol;
 
public class XxxProtocol implemenets Protocol {
 
    // ...
 
}

注意: 扩展点使用单一实例加载(请确保扩展实现的线程安全性),Cache在ExtensionLoader中。  

ExtensionLoader的实现

ExtensionLoader 通过其loadFile方法,加载 META-INF/internal/ ,MEAT-INF/dubbo/,META-INF/services/目录下的配置文件(接口全名为文件名),将扩展类加载并缓存。

  1. @SPI注解用在接口上, 来表明接口实现是可扩展的。这种标记有@SPI的接口,就是可扩展点
  2. 在dubbo中,扩展点默认存在三种实现: Adaptive, Wrapped ,以及normal实现。 其中normal实现就是第三方实现的有特定功能的接口实现。 Adaptive和Wrapped都是对这些normal实现的适配和包装。 Adaptive是某种意义上的集成和适配。Wrapped是包装和代理,有些aop的意思。可以在dubbo源码中找几个默认的adaptive和wrapped实现看看源码。
  3. 其中扩展点实现类还支持@Activate注解,指明了扩展点实现类被激活的加载条件。 

技术分享

 getAdaptiveExtensionClass流程:

1.先找缓存

2.缓存没有,loadExtension From file (只能有一个实现类被@Adaptive标注)

3. loadFile后还是没有,动态生成(Xxx$Adaptive implements Xxx)。(接口方法至少有一个标注了@Adaptive,且只动态生成有标记的方法)

 

 

从ExtensionLoader理解Dubbo扩展机制

标签:注入   actor   多个   size   start   文件名   search   hint   rpc   

原文地址:http://www.cnblogs.com/louistz/p/6340498.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!