理解 Dubbo SPI 扩展机制

写在前面

最近接触了 gRPC 体会到虽然众多 RPC 框架各有各的特点但是他们提供的特性和功能有很多的相似之处 ， 这就说明他们面对同样的分布式系统带来的问题。从 2016 年左右开始接触到 dubbo ，基本停留在使用的层面，对 dubbo 的设计以及着重要解决的问题都没有系统的研究过，通过对 dubbo 和其他类似 RPC 产品的系统学习 ，学习分布式系统中面临的共同问题以及解决之道。

微内核架构

微内核架构 （Microkernel architecture） 模式也被称为插件架构 （Plugin architecture） 模式。原本与内核集成在一起的组件会被分离出来，内核提供了特定的接口使得这些组件可以灵活的接入，这些组件在内核的管理下工作，但是这些组件可以独立的发展、更改（不会对现有系统造成改动），只要符合内核的接口即可。典型的例子比如 ， Eclipse ， IDEA 。

Dubbo 的微内核设计

根据我个人对 Dubbo 微内核设计的理解，以及阅读源码后总结。视觉总是最直观的，可以让大脑最快速度的有一个最直观的认识，一开始就一头深入到源码的细节中只会让人迷糊。不理解 Dubbo 的微内核设计架构的话，学习起来会走不少弯路。

dubbo 内核对扩展是无感的 ， 完全不知道扩展的存在 ， 内核代码中不会出现使用具体扩展的硬编码。

术语说明 ：

SPI ： Service Provider Interface 。

扩展点 ： 称 Dubbo 中被 @SPI 注解的 Interface 为一个扩展点。

扩展 ： 被 @SPI 注解的 Interface 的实现称为这个扩展点的一个扩展。

Dubbo SPI  约定

扩展点约定 :  扩展点必须是 Interface 类型 ， 必须被 @SPI 注解 ， 满足这两点才是一个扩展点。

扩展定义约定 ： 在 META-INF/services/$扩展点接口的全类名 ， META-INF/dubbo/$扩展点接口的全类名 , META-INF/dubbo/internal/$扩展点接口的全类名 ， 这些路径下定义的文件名称为 $扩展点接口的全类名 , 文件中以键值对的方式配置扩展点的扩展实现。例如文件 META-INF/dubbo/internal/com.alibaba.dubbo.common.extension.ExtensionFactory 中定义的扩展 ：


adaptive=com.alibaba.dubbo.common.extension.factory.AdaptiveExtensionFactory
spi=com.alibaba.dubbo.common.extension.factory.SpiExtensionFactory
spring=com.alibaba.dubbo.config.spring.extension.SpringExtensionFactory

默认适应扩展 ： 被 @SPI("abc") 注解的 Interface  , 那么这个扩展点的缺省适应扩展就是 SPI 配置文件中 key 为 "abc"  的扩展。如果存在被 @Adaptive 注解在类上的扩展点接口实现 ，那么这个类就作为扩展点的缺省适应扩展， 一个扩展点只能有一个缺省适应扩展也就是说多个扩展中只能有一个在类上被 @Adaptive 注解，如果有多个 dubbo 会抛出 IllegalStateException("More than 1 adaptive class found : ")。

@SPI 、@Adaptive 、@Activate 作用

@SPI （注解在类上） :  @SPI 注解标识了接口是一个扩展点 ， 属性 value 用来指定默认适配扩展点的名称。

@Activate （注解在类型和方法上） ：  @Activate 注解在扩展点的实现类上 ，表示了一个扩展类被获取到的的条件，符合条件就被获取，不符合条件就不获取 ，根据 @Activate 中的 group 、 value 属性来过滤 。具体参考 ExtensionLoader 中的  getActivateExtension 函数。

@Adaptive （注解在类型和方法上） ：  @Adaptive 注解在类上 ， 这个类就是缺省的适配扩展。@Adaptive 注解在扩展点 Interface 的方法上时 ， dubbo 动态的生成一个这个扩展点的适配扩展类（生成代码 ，动态编译实例化 Class ），名称为 扩展点 Interface 的简单类名 + $Adaptive ，例如 ： ProxyFactory$Adpative  。这么做的目的是为了在运行时去适配不同的扩展实例 ， 在运行时通过传入的 URL 类型的参数或者内部含有获取 URL 方法的参数 ，从 URL 中获取到要使用的扩展类的名称 ，再去根据名称加载对应的扩展实例 ，用这个扩展实例对象调用相同的方法  。如果运行时没有适配到运行的扩展实例 ， 那么就使用 @SPI 注解缺省指定的扩展。通过这种方式就实现了运行时去适配到对应的扩展。

运行时动态生成的适配扩展类代码 ：



package com.alibaba.dubbo.rpc;

import com.alibaba.dubbo.common.extension.ExtensionLoader;

public class Protocol$Adpative implements com.alibaba.dubbo.rpc.Protocol {
    public void destroy() {
        throw new UnsupportedOperationException("method public abstract void com.alibaba.dubbo.rpc.Protocol.destroy() of interface com.alibaba.dubbo.rpc.Protocol is not adaptive method!");
    }

    public int getDefaultPort() {
        throw new UnsupportedOperationException("method public abstract int com.alibaba.dubbo.rpc.Protocol.getDefaultPort() of interface com.alibaba.dubbo.rpc.Protocol is not adaptive method!");
    }

    public com.alibaba.dubbo.rpc.Invoker refer(java.lang.Class arg0, com.alibaba.dubbo.common.URL arg1) throws java.lang.Class {
        if (arg1 == null) throw new IllegalArgumentException("url == null");
        com.alibaba.dubbo.common.URL url = arg1;

        // 从 URL 中获取扩展名称 , "dubbo" 是从 ExtensionLoader 对象中的 cachedDefaultName
        // 属性获取到的 , cachedDefaultName 是扩展点上 @SPI 注解中 value 属性指定的
        String extName = (url.getProtocol() == null ? "dubbo" : url.getProtocol());
        if (extName == null)
            throw new IllegalStateException("Fail to get extension(com.alibaba.dubbo.rpc.Protocol) name from url(" + url.toString() + ") use keys([protocol])");

        // 通过扩展名称获取扩展实例对象 , 调用扩展实例对象的相同方法
        com.alibaba.dubbo.rpc.Protocol extension = (com.alibaba.dubbo.rpc.Protocol) ExtensionLoader.getExtensionLoader(com.alibaba.dubbo.rpc.Protocol.class).getExtension(extName);
        return extension.refer(arg0, arg1);
    }

    public com.alibaba.dubbo.rpc.Exporter export(com.alibaba.dubbo.rpc.Invoker arg0) throws com.alibaba.dubbo.rpc.Invoker {
        if (arg0 == null) throw new IllegalArgumentException("com.alibaba.dubbo.rpc.Invoker argument == null");
        if (arg0.getUrl() == null)
            throw new IllegalArgumentException("com.alibaba.dubbo.rpc.Invoker argument getUrl() == null");
        com.alibaba.dubbo.common.URL url = arg0.getUrl();

        // 从 URL 中获取扩展名称
        String extName = (url.getProtocol() == null ? "dubbo" : url.getProtocol());
        if (extName == null)
            throw new IllegalStateException("Fail to get extension(com.alibaba.dubbo.rpc.Protocol) name from url(" + url.toString() + ") use keys([protocol])");

        // 通过扩展名称获取扩展实例对象 , 调用扩展实例对象的相同方法
        com.alibaba.dubbo.rpc.Protocol extension = (com.alibaba.dubbo.rpc.Protocol) ExtensionLoader.getExtensionLoader(com.alibaba.dubbo.rpc.Protocol.class).getExtension(extName);
        return extension.export(arg0);
    }
}

package com.alibaba.dubbo.rpc;

import com.alibaba.dubbo.common.extension.ExtensionLoader;

public class ProxyFactory$Adpative implements com.alibaba.dubbo.rpc.ProxyFactory {
    public java.lang.Object getProxy(com.alibaba.dubbo.rpc.Invoker arg0) throws com.alibaba.dubbo.rpc.Invoker {
        if (arg0 == null) throw new IllegalArgumentException("com.alibaba.dubbo.rpc.Invoker argument == null");
        if (arg0.getUrl() == null)
            throw new IllegalArgumentException("com.alibaba.dubbo.rpc.Invoker argument getUrl() == null");
        com.alibaba.dubbo.common.URL url = arg0.getUrl();

        // 从 URL 中获取扩展名称
        String extName = url.getParameter("proxy", "javassist");
        if (extName == null)
            throw new IllegalStateException("Fail to get extension(com.alibaba.dubbo.rpc.ProxyFactory) name from url(" + url.toString() + ") use keys([proxy])");

        // 通过扩展名称获取扩展实例对象 , 调用扩展实例对象的相同方法
        com.alibaba.dubbo.rpc.ProxyFactory extension = (com.alibaba.dubbo.rpc.ProxyFactory) ExtensionLoader.getExtensionLoader(com.alibaba.dubbo.rpc.ProxyFactory.class).getExtension(extName);
        return extension.getProxy(arg0);
    }

    public com.alibaba.dubbo.rpc.Invoker getInvoker(java.lang.Object arg0, java.lang.Class arg1, com.alibaba.dubbo.common.URL arg2) throws java.lang.Object {
        if (arg2 == null) throw new IllegalArgumentException("url == null");
        com.alibaba.dubbo.common.URL url = arg2;

        // 从 URL 中获取扩展名称
        String extName = url.getParameter("proxy", "javassist");
        if (extName == null)
            throw new IllegalStateException("Fail to get extension(com.alibaba.dubbo.rpc.ProxyFactory) name from url(" + url.toString() + ") use keys([proxy])");

        // 通过扩展名称获取扩展实例对象 , 调用扩展实例对象的相同方法
        com.alibaba.dubbo.rpc.ProxyFactory extension = (com.alibaba.dubbo.rpc.ProxyFactory) ExtensionLoader.getExtensionLoader(com.alibaba.dubbo.rpc.ProxyFactory.class).getExtension(extName);
        return extension.getInvoker(arg0, arg1, arg2);
    }
}

这些代码都是模板代码 ， 最核心的代码就只有一行 , 这行代码是去获取一个指定名称的扩展实例对象 ：


ExtensionLoader.getExtensionLoader(Xxx.class).getExtension(extName);

在使用 dubbo 生成的源码时要注意 ， 它生成的代码是有错误的， 比如 Protocol$Adpative 类的中的 refer 和 export 方法签名 throws 的不是 Protocol 接口中方法定义抛出的 RpcException , 而是 Class ，和 Invoker  。 这个问题存在于 dubbo 2.5.4 之前的版本中，在 2.5.4 版本中修复了。

扩展加载器 ExtensionLoader

扩展加载器绝对是一个核心组件了 ，它控制着 dubbo 内部所有扩展点的初始化、加载扩展的过程。这个类的源码是很有必要深入学习的。从 Dubbo 内核设计简图可以看到，现在的学习还没有接触到 dubbo 的内核。

ExtensionLoader 中会存储两个静态属性 ， EXTENSION_LOADERS 保存了内核开放的扩展点对应的 ExtensionLoader 实例对象 （说明了一种扩展点有一个对应的 ExtensionLoader 对象）。EXTENSION_INSTANCES 保存了扩展类型 （Class） 和扩展类型的实例对象。

ExtensionLoader  对象中的属性 ：


Class<?> type;

ExtensionFactory objectFactory;

ConcurrentMap<Class<?>, String> cachedNames;

Holder<Map<String, Class<?>>> cachedClasses;

Map<String, Activate> cachedActivates;

Class<?> cachedAdaptiveClass;

ConcurrentMap<String, Holder<Object>> cachedInstances;

String cachedDefaultName;

Holder<Object> cachedAdaptiveInstance;

Throwable createAdaptiveInstanceError;

Set<Class<?>> cachedWrapperClasses;

Map<String, IllegalStateException> exceptions;

 type ： 被 @SPI 注解的 Interface ， 也就是扩展点。

    objectFactory ： 扩展工厂，可以从中获取到扩展类型实例对象 ，缺省为 AdaptiveExtensionFactory。 

          cachedNames ： 保存不满足装饰模式（不存在只有一个参数，并且参数是扩展点类型实例对象的构造函数）的扩展的名称。

        cachedClasses ： 保存不满足装饰模式的扩展的 Class 实例 ， 扩展的名称作为 key , Class 实例作为 value。

        cachedActivates ： 保存不满足装饰模式 ， 被 @Activate 注解的扩展的 Class 实例。

        cachedAdaptiveClass ： 被 @Adpative 注解的扩展的 Class 实例 。

        cachedInstances ： 保存扩展的名称和实例对象 ， 扩展名称为 key  ， 扩展实例为 value。

        cachedDefaultName :  扩展点上 @SPI 注解指定的缺省适配扩展。

        createAdaptiveInstanceError ： 创建适配扩展实例过程中抛出的异常。

        cachedWrapperClasses ： 满足装饰模式的扩展的 Class 实例。

        exceptions ： 保存在加载扩展点配置文件时，加载扩展点过程中抛出的异常 ， key 是当前读取的扩展点配置文件的一行 ， value 是抛出的异常。

附： dubbo 开放的扩展点


com.alibaba.dubbo.cache.CacheFactory
com.alibaba.dubbo.common.compiler.Compiler
com.alibaba.dubbo.common.extension.ExtensionFactory
com.alibaba.dubbo.common.logger.LoggerAdapter
com.alibaba.dubbo.common.serialize.Serialization
com.alibaba.dubbo.common.status.StatusChecker
com.alibaba.dubbo.common.store.DataStore
com.alibaba.dubbo.common.threadpool.ThreadPool
com.alibaba.dubbo.container.Container
com.alibaba.dubbo.container.page.PageHandler
com.alibaba.dubbo.monitor.MonitorFactory
com.alibaba.dubbo.registry.RegistryFactory
com.alibaba.dubbo.remoting.Codec2
com.alibaba.dubbo.remoting.Dispatcher
com.alibaba.dubbo.remoting.exchange.Exchanger
com.alibaba.dubbo.remoting.http.HttpBinder
com.alibaba.dubbo.remoting.p2p.Networker
com.alibaba.dubbo.remoting.telnet.TelnetHandler
com.alibaba.dubbo.remoting.Transporter
com.alibaba.dubbo.remoting.zookeeper.ZookeeperTransporter
com.alibaba.dubbo.rpc.cluster.Cluster
com.alibaba.dubbo.rpc.cluster.ConfiguratorFactory
com.alibaba.dubbo.rpc.cluster.LoadBalance
com.alibaba.dubbo.rpc.cluster.Merger
com.alibaba.dubbo.rpc.cluster.RouterFactory
com.alibaba.dubbo.rpc.Filter
com.alibaba.dubbo.rpc.InvokerListener
com.alibaba.dubbo.rpc.Protocol
com.alibaba.dubbo.rpc.protocol.thrift.ClassNameGenerator
com.alibaba.dubbo.rpc.ProxyFactory
com.alibaba.dubbo.validation.Validation

原文链接：https://my.oschina.net/j4love/blog/1813040

原文地址：https://www.cnblogs.com/qixidi/p/10260106.html

时间： 2024-10-10 05:12:13

理解 Dubbo SPI 扩展机制的相关文章

Dubbo中SPI扩展机制解析

dubbo的SPI机制类似与Java的SPI,Java的SPI会一次性的实例化所有扩展点的实现,有点显得浪费资源. dubbo的扩展机制可以方便的获取某一个想要的扩展实现,每个实现都有自己的name,可以通过name找到具体的实现. 每个扩展点都有一个@Adaptive实例,用来注入到依赖这个扩展点的某些类中,运行时通过url参数去动态判断最终选择哪个Extension实例用. dubbo的SPI扩展机制增加了对扩展点自动装配(类似IOC)和自动包装(类似AOP)的支持. 标注了@Activat

聊聊Dubbo - Dubbo可扩展机制实战

摘要: 在Dubbo的官网上,Dubbo描述自己是一个高性能的RPC框架.今天我想聊聊Dubbo的另一个很棒的特性, 就是它的可扩展性. 1. Dubbo的扩展机制 在Dubbo的官网上,Dubbo描述自己是一个高性能的RPC框架.今天我想聊聊Dubbo的另一个很棒的特性, 就是它的可扩展性. 如同罗马不是一天建成的,任何系统都一定是从小系统不断发展成为大系统的,想要从一开始就把系统设计的足够完善是不可能的,相反的,我们应该关注当下的需求,然后再不断地对系统进行迭代.在代码层面,要求我们适当的对

聊聊Dubbo - Dubbo可扩展机制源码解析

摘要: 在Dubbo可扩展机制实战中,我们了解了Dubbo扩展机制的一些概念,初探了Dubbo中LoadBalance的实现,并自己实现了一个LoadBalance.是不是觉得Dubbo的扩展机制很不错呀,接下来,我们就深入Dubbo的源码,一睹庐山真面目. 在Dubbo可扩展机制实战中,我们了解了Dubbo扩展机制的一些概念,初探了Dubbo中LoadBalance的实现,并自己实现了一个LoadBalance.是不是觉得Dubbo的扩展机制很不错呀,接下来,我们就深入Dubbo的源码,一睹庐

Java中的SPI扩展机制（有demo）

参考连接:https://www.jianshu.com/p/3a3edbcd8f24 一.什么是SPI SPI ,全称为 Service Provider Interface,是一种服务发现机制.它通过在ClassPath路径下的META-INF/services文件夹查找文件,自动加载文件里所定义的类. 二.设计的目的 肯定是为了扩展性,在不想修改源码的情况下,去替换系统原有的实现,代价最小也最灵活. 三.案例demo 先看看目录接结构 spi-api模块:定义扩展接口 spi-client

Dubbo 扩展点加载机制：从 Java SPI 到 Dubbo SPI

SPI 全称为 Service Provider Interface,是一种服务发现机制.当程序运行调用接口时,会根据配置文件或默认规则信息加载对应的实现类.所以在程序中并没有直接指定使用接口的哪个实现,而是在外部进行装配. 要想了解 Dubbo 的设计与实现,其中 Dubbo SPI 加载机制是必须了解的,在 Dubbo 中有大量功能的实现都是基于 Dubbo SPI 实现解耦,同时也使得 Dubbo 获得如此好的可扩展性. Java SPI 通过完成一个 Java SPI 的操作来了解它的机

从ExtensionLoader理解Dubbo扩展机制

Dubbo的扩展机制是怎么实现的?最简单的回答就是@SPI. Dubbo的插件化思路来源于Java SPI. JAVA SPI 机制 SPI的全名为Service Provider Interface. 大多数人可能不了解,因为它是JDK针对插件或者厂商的.java spi机制的思想就是: 我们的系统的抽象模块(接口),往往有很多不同方案的实现.如日志模块,jdbc模块等.而在面向对象的设计里,我们一般都要做模块解耦,面向接口编程.但如果要切换接口的不同实现,就可能需要改动代码.为了实现模块的自

Dubbo源码分析系列-扩展机制的实现

Spring可扩展Schema 像标签dubbo:monitor.dubbo:service.dubbo:provider等怎么读的,读完之后怎么又是怎么解析的呢? 以上标签都是基于Spring可扩展Schema提供的自定义配置 下面举个例子 1)创建JavaBean 首先设计好配置项,通过JavaBean来建模,如类People public class People { private String name; private Integer age; } 2)编写XSD文件 XSD文件是X

dubbo的扩展点重构

可扩展设计是框架要重点考虑的设计,因为它直接影响到框架的稳定性和功能的扩展,Dubbo扩展点重构.它在扩展性设计上踩过的坑,值得框架设计者借鉴学习. 第一步,微核心,插件式,平等对待第三方 即然要扩展,扩展点的加载方式,首先要统一,微核心+插件式,是比较能达到 OCP 原则的思路. 由一个插件生命周期管理容器,构成微核心,核心不包括任何功能,这样可以确保所有功能都能被替换,并且,框架作者能做到的功能,扩展者也一定要能做到,以保证平等对待第三方,所以,框架自身的功能也要用插件的方式实现,不能有任何

探究Dubbo的拓展机制: 下

承接上篇, 本篇博文的主题就是认认真真捋一捋, 看一下 Dubbo是如何实现他的IOC / AOP / 以及Dubbo SPI这个拓展点的 总览: 本篇的话总体上分成两部分进行展开 第一点就是 Dubbo在启动过程中加载原生的配置文件中提供的被@SPI标记的实现类: 第二就是Dubbo加载程序员后续添加进去的被@SPI标注的接口和实现类, 进而探究 Dubbo的IOC / AOP / 以及Dubbo SPI这个拓展点机制 环境的初始化 入口程序 如下代码是追踪的起点: 我也是看了好多遍才勉强将这