Dubbo——ExtensionFactory的实现原理

ExtensionFactory的实现原理

RegistryFactory工厂类通过@Adaptive({"protocol"})注解动态查找注册中心实现，根据URL中的protocol参数动态选择对应的注册中心工厂，并初始化具体的注册中心客户端。而实现这个特性的ExtensionLoader类，本身又是通过工厂方法ExtensionFactory创建的，并且这个工厂接口上也有SPI注解，还有多个实现。

AdaptiveExtensionFactory这个实现类工厂上有@Adaptive注解。因此，AdaptiveExtensionFactory会作为一开始的默认实现。

工厂类之间的关系如下：

可以看到，除了可以从Dubbo SPI管理的容器中获取扩展点实例，还可以从Spring容器中获取。

Dubbo和Spring容器之间是如何打通的呢？

看SpringExtensionFactory的实现，该工厂提供了保存Spring上下文的静态方法，可以把Spring上下文保存到Set集合中。当调用getExtension获取扩展类时，会遍历Set集合中所有的Spring上下文，先根据名字依次从每个Spring容器中进行匹配，如果根据名字没匹配到，则根据类型去匹配，如果还没有匹配到则返回null：

再看SPIExtensionFactory，主要就是获取扩展点接口对应的Adaptive实现类。例如：某个扩展点实现类ClassA上有@Adaptive注解，则调用SpiExtensionFactory#getExtesion会直接返回ClassA实例：

经过一番流转，最终还是回到了默认实现AdaptiveExtensionFactory上，因为该工厂上有@Adaptive注解。这个默认工厂在构造方法中就获取了所有扩展类工厂并缓存起来，包括SpiExtensionFactory和SpringExtensionFactory。

被AdaptiveExtensionFactory缓存的工厂会通过TreeSet进行排序，SPI排在前面，Spring排在后面。当调用getExtension方法时，会遍历所有的工厂，先从SPI容器中获取扩展类，如果没找到，则再从Spring容器中查找。

可以理解为，AdaptiveExtensionFactory持有了所有的具体工厂实现，它的getExtesion方法中只是遍历了它持有的所有工厂，最终还是调动SPI或Spring工厂实现的getExtesion方法。