1. dubbo基于SPI思想实现
* SPI:
我们系统里抽象的各个模块，往往有很多不同的实现方案，比如日志模块的方案、xml解析模块、jdbc模块的方案等。面向对象的设计里，我们一般推荐模块之间基于接口编程，模块之间不对实现类进行硬编码。一旦代码里涉及具体的实现类，就违反了可拔插的原则，如果需要替换一种实现，就需要修改代码。
为了实现在模块装配的时候能在程序里动态指明，这就需要一种服务发现机制。java spi就是提供这样的机制：为某个接口寻找服务实现的机制。有点类似IOC的思想，就是将装配的控制权移到程序之外，在模块化设计中这个机制尤其重要。
* java中的SPI的约定
当服务的提供者提供了服务接口的一种实现之后，在jar包的META-INF/services/目录里同时创建一个以服务接口命名的文件。该文件里面就是实现该服务接口的具体实现类。而当外部程序装配这个模块的时候，就能通过该jar包META-INF/services/里面的配置文件找到具体的实现类类名，并装载实例化，完成模块的注入。基于这样一个约定就能很好的找到服务接口的实现类，而不需要代码里指定。jdk提供服务实现查找的一个工具类：java.util.ServiceLoader.
代表例子：jdbc4以前，开发人员还需要基于Class.forName("XXX")的方式来装载驱动。现在jdbc也基于spi机制来发现驱动提供商了，可以通过META-INF/services/java.sql.Driver文件里面指定实现类的方式来暴露驱动提供者，比如mysql驱动提供者。
- dubbo中基于SPI思想的实现
dubbo的扩展点加载从JDK标准的SPI扩展点发现机制加强而来。dubbo改进了JDK标准的SPI的一下问题：
- JDK标准的SPI会一次性实例化扩展点所有实现，如果有扩展实现初始化很耗时，但如果没用上也加载，会很浪费资源。
- 如果扩展点加载失败，连扩展点名称都拿不到了。比如：JDK标准的ScriptEngine，通过getName（）；获取脚本类型的名称，但如果RubyScriptEngine因为依赖的jruby.jar不存在，导致RubyScript不支持ruby，而不是真正失败的原因。
- 增加了对扩展点IoC和AOP的支持，一个扩展点可以直接setter注入其他扩展点。
dubbo扩展点机制的基本概念：
- 扩展点（Extension Point）一个java接口
- 扩展（Extension）扩展点实现类
- 扩展实例（Extension Instance）扩展点实现类的实例
- 扩展自适应实例（extension Adaptive Instance）：扩展点自适应实例其实就是一个Extension的代理，它实现了扩展点接口。在调用扩展点的接口方法时，会根据实际的参数来决定要使用那个扩展点。
SPI接口定义：dubbo定义了注解@SPI用于扩展
public @interface SPI {
/**
* 缺省扩展点名。
*/
String value() default "";
}
当接口打上了该注解时，dubbo会在META-INF/dubbo/internal/接口全名文件下读取扩展点。
当dubbo启动时，通过ExtensionLoader类来读取扩展点中的实现类，首先读取SPI注解的value值，如果有值作为默认扩展实现的key，然后通过loadFile（）一次逐行读取
META-INF/dubbo/internal/com.alibaba.dubbo.XXX.XXX
META-INF/dubbo/com.alibaba.dubbo.XXX.XXX
文件中的内容
