Dubbo的扩展点的背景与实现

Java有以下几个常用扩展点加载的实现：

标准的Java Service（sun.misc.Service/java.util.ServiceLoader）
Spring classpath*
OSGi

都可以做到新加入一个Extension的Jar在启动时甚至是运行时发现新的扩展点。

Dubbo的扩展点实现方式采用了标准Java Service，使用相同的配置文件，在此之上结合Dubbo的使用方式作一些加强

一、关于Java中的SPI(Service Provider Interface)介绍
原始定义可以参见链接如下： http://download.oracle.com/javase/1.5.0/docs/guide/jar/jar.html#Service Provider
       那么这个东西是用来做什么的呢？一般来说，一个比较大的系统里的各个模块，往往有很多不同的实现方案，比如日志模块的方案，xml解析模块、jdbc模块的方案等。面向的对象的设计里，我们一般推荐模块之间基于接口编程，模块之间不对实现类进行硬编码。一旦代码里涉及具体的实现类，就违反了可拔插的原则，如果需要替换一种实现，就需要修改代码。

       为了实现在模块装配的时候能不在程序里动态指明，这就需要一种服务发现机制。java spi就是提供这样的一个机制：为某个接口寻找服务实现的机制。有点类似IOC的思想，就是将装配的控制权移到程序之外，在模块化设计中这个机制尤其重要。

       这种实现方式，感觉和我们通常的开发方式差不多，都是定义一个接口，然后子类实现父类中定义的方法，为什么要搞这么一套标准以及单独搞一个配置文件？这种方式主要是针对不同的服务提供厂商，对不同场景的提供不同的解决方案制定的一套标准，举个简单的例子，如现在的JDK中有支持音乐播放，假设只支持mp3的播放，有些厂商想在这个基础之上支持mp4的播放，有的想支持mp5，而这些厂商都是第三方厂商，如果没有提供SPI这种实现标准，那就只有修改JAVA的源代码了，那这个弊端也是显而易见的，也就是不能够随着JDK的升级而升级现在的应用了，而有了SPI标准，SUN公司只需要提供一个播放接口，在实现播放的功能上通过ServiceLoad的方式加载服务，那么第三方只需要实现这个播放接口，再按SPI标准进行打包成jar，再放到classpath下面就OK了，没有一点代码的侵入性。

二、Dubbo的实现

       由于Dubbo是开源框架，必须要提供很多的可扩展点。Dubbo是通过扩展SPI机制来实现可扩展的。
（1）在META-INF目录下，放置文件名为接口全称，文件中为key、value键值对，value为具体实现类的全类名，key为标志值。
（2）通过ExtensionLoader把对应的设置文件装入，查看ExtensionLoader的源码，可以看到Dubbo对SPI做了三个方面的扩展：
* SPI仅仅通过接口类名获取所有实现，而ExtensionLoader则通过接口类名和key值获取一个实现；
* Adaptive实现，就是生成一个代理类，这样就可以根据实际调用时的一些参数动态决定要调用的类了。
* 自动包装实现，这种实现的类一般是自动激活的，常用于包装类，比如Protocol的两个实现类：ProtocolFilterWrapper、ProtocolListenerWrapper。