上一篇文章讲到了如何去找到 Dubbo 源码的调试入口,如果你跟随文章思路,那你将要阅读的第一条主线将是 Dubbo 的服务发布流程。在阅读的过程中你会发现,有很多代码很相似,并且重复出现,比如这里:,这段代码是 Dubbo 服务发布的关键流程,其中用到了两个类都是通过
ExtensionLoader.getExtensionLoader()
去获得的,这其实体现的就是Dubbo 的SPI机制,SPI 机制在 Dubbo 中被大量运用,也是 Dubbo 设计的亮点所在。,这就要谈到Dubbo的架构设计了,之前提到 Dubbo 采用的是分层架构的方式,Dubbo 的设计体现了程序设计中的开闭原则,每一层都可以被另一种实现技术替换掉,而不影响上下层之间的依赖和整体逻辑的运转,这其实就是微内核架构(微内核+插件)。,微内核架构也被称为插件化架构(Plug-in Architecture),这是一种面向功能进行拆分的可扩展性架构。内核功能是比较稳定的,只负责管理插件的生命周期,不会因为系统功能的扩展而不断进行修改。功能上的扩展全部封装到插件之中,插件模块是独立存在的模块,包含特定的功能,全部可被替换,并且可以拓展内核系统的功能,而 Dubbo 最终决定采用
SPI 机制来加载插件。,开闭原则 OCP (Open-Closed Principle ):程序的设计应该是不约束扩展,即扩展开放,但又不能修改已有功能,即修改关闭。,
,SPI ,全称为 Service Provider Interface,直接翻译过来是服务提供者接口,是一种服务发现机制,而我们通常指的是JDK的SPI。,JDK SPI,它是JDK内置的一种服务发现机制,可以动态的发现服务,即服务提供商,它通过在ClassPath路径下的META-INF/services文件夹查找文件,自动加载文件里所定义的类。,根据他的定义就知道他主要是被框架开发人员使用的,通过 SPI 可以加载服务本身以外的扩展。最常用的比如JDBC驱动连接时候选择不同的驱动,对
java.sql.Driver
的实现就利用了SPI机制;Spring框架中也使用了很多,比如在 Spring 中为了支持Servlet3.0规范不使用
web.xml
,对
javax.servlet.ServletContainerInitializer
的实现也利用了SPI;在Dubbo中更是大量运用了SPI机制,不但有JDK SPI的运用,更重要的是 Dubbo 自己还实现了一套SPI机制。,当服务提供者想利用SPI机制去扩展,需要遵循以下步骤。,如果看完上述流程还不是很清楚,请看如下示例。比如这里有接口 MySPI 需要按照上述流程按照SPI机制加载。,
,首先提供了两个实现类 GoodbyeMySPI 和 HelloMySPI,然后在 META-INF/services 文件夹下保存了文件
org.daley.spi.demo.MySPI
,文件的内容是两个实现类的全路径名。就绪之后就可以在
main
方法中启动demo,用
ServiceLoader.load()
加载 MySPI 的两个实现类,然后分别调用接口方法执行。代码如下:,看完上述 demo,你有没有好奇 JDK SPI 的原理是什么?相信你已经猜的八九不离十了。我们从demo的
main
方法开始追踪起。,很明显关键的代码就一行
ServiceLoader.load(MySPI.class)
,他是整个类加载的入口。,在
reload()
方法中首先清空了
providers
,它里面存贮了所有服务接口的实现,key为实现类名,value为对象。然后便会
new
一个
LazyIterator
,
LazyIterator
是
ServiceLoader
内部实现的一个迭代器,此时还没有真正开始加载,只是保存了接口和类加载器在迭代器中。,正如其名懒加载迭代器,在调用
iterator.hasNext()
时才真正发生加载。在
hasNextService()
方法中,第一次调用此方法会先拼接出配置SPI的文件名,在本demo中也就是
META-INF/services/org.daley.spi.demo.MySPI
,然后会使用类加载器加载配置文件并且将每行的内容设置到迭代器
pending
中,每次遍历都可以按行依次拿到实现类的名字。,
,比如第一次迭代,返回第一行配置的实现类名
org.daley.spi.demo.GoodbyeMySPI
。到这里只是加载配置文件拿到类名,还未加载类。,当执行到
iterator.next()
的时候才会真正去加载class类。追踪此方法最终进入
nextService()
方法,在这里你会看到熟悉的
Class.forName()
以及
newInstance()
方法,读取类和实例化类的逻辑一目了然。到这里JDK SPI的核心逻辑就结束了。,简言之,通过将实现类名保存在以服务接口命名的配置文件中,放置在
META-INF/services
,
ServiceLoader
会在先读取配置文件中实现类的名字,然后根据调用
newInstance()
方法对其进行实例化。简化的原理图如下:,
,既然已经有了 JDP SPI 为什么还需要 Dubbo SPI呢?,技术的出现通常都是为了解决现有问题,通过之前的 demo,不难发现 JDK SPI 机制就存在以下一些问题:,所以 Dubbo SPI 以 JDK SPI 为参考做出了改进设计,进行了性能优化以及功能增强,Dubbo SPI 机制的出现解决了上述问题。 由于 Dubbo SPI的知识点太多并且很重要,将专门安排在下一篇文章讲解,更多关于Dubbo JDK SPI原理的资料请关注其它相关文章!