01提出问题
其实会提出这个问题，也是因为强哥在知乎上被问了另一个问题：
而要解决上面这个问题，就涉及到了Dubbo的SPI机制，它是Dubbo的扩展点，通过它我们能清楚的知道Dubbo底层真正使用的第三方框架及原理实现。
但是，我们又知道，其实Java也有自己的一套SPI，作为JDK内置的一种服务提供发现机制。而目前市面上很多框架都用它来做服务的扩展发现。SPI的简单理解就是一种动态替换发现的机制。举个例子，我们想在运行时动态给它添加实现，你只需要添加一个实现，然后把新的实现描述给JDK知道就行了。大家耳熟能详的如JDBC，日志框架都有用到。
那么为什么Dubbo不用Java的SPI而要自己搞一套呢？那还用说，当然是因为其本身存在一定的弊端，导致Dubbo不得不自己再造个新轮子。
Java SPI的使用
我们先来看看怎么使用Java的SPI。
- 需要在 classpath 下创建一个目录，该目录命名必须是：META-INF/service；
- 在该目录下创建一个 properties 文件，该文件需要满足以下几个条件
2.1 文件名必须是扩展的接口的全路径名称
2.2 文件内部描述的是该扩展接口的所有实现类
2.3 文件的编码格式是 UTF-8 - 通过 java.util.ServiceLoader 的加载机制来发现
不多啰嗦，直接给例子，文件目录如下：
代码如下，为了简单，把各个文件代码合到一起展示：
public interface INanShen { void show();} public class DianZanQiangGe implements INanShen{ public void show() { System.out.println("欢迎点赞，强哥叨逼叨！"); }} public class GuanZhuQiangGe implements INanShen{ public void show() { System.out.println("欢迎关注，强哥叨逼叨！"); }} public class NiuBiMain { public static void main(String[] args) { ServiceLoader<INanShen> serviceLoader = ServiceLoader.load(INanShen.class); Iterator<INanShen> iterator = serviceLoader.iterator(); while (iterator.hasNext()) { INanShen nanShen = iterator.next(); nanShen.show(); } }}
文件demo.INanShen内容及运行对应输出如下：
内容：demo.GuanZhuQiangGe输出：欢迎关注，强哥叨逼叨！ 内容：demo.GuanZhuQiangGedemo.DianZanQiangGe输出：欢迎关注，强哥叨逼叨！欢迎点赞，强哥叨逼叨！
看起来是不是非常简单好用，那么为什么Dubbo不直接使用呢？
这就要从源码角度找原因了，感兴趣的同学可以复制上面的代码debug走一下Java SPI源码的加载流程，限于篇幅，强哥就不列出源码了，流程大体如下：
简单来说就是：就是约定一个目录META-INF/services/，根据接口名去那个目录找到文件，文件解析得到实现类的全限定名，然后循环加载实现类和创建其实例。这种方式存在一些缺点：
- JDK 标准的 SPI 会一次性加载实例化扩展点的所有实现，什么意思呢？就是如果你在 META-INF/service 下的文件里面加了 N 个实现类，那么 JDK 启动的时候都会一次性全部加载。那么如果有的扩展点实现初始化很耗时或者如果有些实现类并没有用到， 那么会很浪费资源；
- 如果扩展点加载失败，会导致调用方报错，而且这个错误很难定位到是这个原因。
所以，Dubbo为了避免以上的确定，自己搞了一套更牛的SPI机制。
02问题解析
Dubbo的SPI机制，主要用了它自己的一个加载器ExtensionLoader。除了可以按需加载实现类之外，增加了 IOC 和 AOP 的特性，还有个自适应扩展机制。
对配置文件目录的约定，不同于 Java SPI ，Dubbo 分为了三类目录：
- META-INF/services/ 目录：该目录下的 SPI 配置文件是为了用来兼容 Java SPI 。
- META-INF/dubbo/ 目录：该目录存放用户自定义的 SPI 配置文件。
- META-INF/dubbo/internal/ 目录：该目录存放 Dubbo 内部使用的 SPI 配置文件。
而其配置文件的内容，也改成了键值对的方式。
可能这么说大家一下子还不太好理解，我们来通过解决上面知乎网友问的问题，来加深一下，问题是：Dubbo真的底层是基于Netty吗？
怎么知道呢？从上面的三个目录中我们找一下，可以在META-INF/dubbo/internal/下找到如下文件：
内容为：
然后全局搜索文件名对应的类：org.apache.dubbo.remoting.Transporter
嘿嘿，从Transporter类上的注解@SPI("netty")，我们便可以知道，Dubbo底层传输默认使用的是netty，不是netty3，netty4也不是mina。
而具体的使用，有兴趣的小伙伴也可以看看Transporter类下的bind和connect的子类实现，也就是netty的实现：
终上所述，也就解答了：Dubbo底层确实是基于Netty的。
