GitHub 下载较慢，可以从码云中获取：git@gitee.com:mirrors/dubbo.git

Dubbo 在 2.7.x 的时候，包路径已经更改为 Apache 的了。

Dubbo 设计时遵循的原则：

  • 采用 微内核 + Plugin 模式，微内核 只负责组装 Plugin，Dubbo 自身的功能也是通过扩展点实现的，也就是 Dubbo 的所有功能点都可被用户自定义扩展所替换。
  • 采用 URL 作为配置信息的统一格式，所有扩展点都通过传递 URL 携带配置信息。

Dubbo 抽出的领域模型：

  • Protocol 是服务域，它是 Invoker 暴露和引用的主功能入口，它负责 Invoker 的生命周期管理。
  • Invoker 是实体域，它是 Dubbo 的核心模型，其它模型都向它靠扰，或转换成它，它代表一个可执行体，可向它发起 invoke 调用，它有可能是一个本地的实现，也可能是一个远程的实现，也可能一个集群实现。
  • Invocation 是会话域，它持有调用过程中的变量，比如方法名，参数等。

SPI

Service Provider Interface，服务提供者接口，是一种服务发现机制。

JDK SPI 规范

  • 接口名可以随便定义
  • 实现类名可以随便定义
  • 提供者配置文件路径为 META-INF/services
  • 提供者配置文件名称为 接口的全限定类名
  • 提供者配置文件内容 该接口的所有实现类全限类名，一个类占一行

如果是没了解过可能比较抽象，简单来说就是一个约定好的规范，一种编码格式就行，这里写了个 dmeo：

image.png

Dubbo SPI 规范

Dubbo

  • 接口名可以随便定义
  • 实现类名在接口名称前加一个用于表示自身标志前缀的字符串
  • 提供者配置路径有 **META-INF/dubbo/internal,META-INF/dubbo,META-INF/services**
  • 提供者配置文件名称为 接口的全限定类名
  • 提供者配置文件内容为 key=value 格式，key 可以随意，但一般是实现类首字母小写；value是实现类全类名，一个类占一行

可能还是比较抽象，看看官方 common 模块中的例子：
image.png

这里有个术语，实现这些 SPI 接口的实现类，Dubbo 中称他们为扩展点
**

Dubbo 中 SPI 的使用

Dubbo 中 有个 @SPI 注解就是用来标记的某个接口

image.png
**
有一个 value 属性值，表示默认获取哪个类型的实现类，这里线程池默认用的是 fixed，也就是从这里获取实现类：fixed=org.apache.dubbo.common.threadpool.support.fixed.FixedThreadPool

image.png

同理还有 Protocol 接口，也是类似的，它上面默认用的就是 dubbo 协议

image.png
**

从源码来看，SPI 通过事先的约定和配置文件的形式，这样可自定义程度高，扩展性强，但底层创建实例还是用反射来操作得。这个思路可以借鉴下。