Dubbo Spi机制

已于 2024-05-17 14:15:37 修改
阅读量318 收藏 6
点赞数 1
文章标签： 架构
于 2024-02-01 19:43:32 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq_36851469/article/details/135978264
版权

本质：将接口实现类的全限定名配置在文件中，并由服务加载器读取配置文件，加载实现类。这样可以在运行时，动态为接口替换实现类。

java SPI：用来设计给服务提供商做插件使用的。基于策略模式来实现动态加载的机制。我们在程序只定义一个接口，具体的实现交个不同的服务提供者；在程序启动的时候，读取配置文件，由配置确定要调用哪一个实现。具体流程为：

  1. 需要在 classpath 下创建一个目录，该目录命名必须是：META-INF/service。
  2. 在该目录下创建一个 文本文件，该文件需要满足以下几个条件：文件名必须是扩展的接口的全路径名称、文件内部描述的是该扩展接口的所有实现类、文件的编码格式是 UTF-8。
  3. 通过 java.util.ServiceLoader 的加载机制来加载服务。

javaSPI我们最熟悉的应用就是数据库驱动了，mysql和oracle驱动针对JDBC分别有自己的实现，这就有赖于java的SPI机制。

JDK SPI 机制就存在以下一些问题：

  1. 实现类会被全部遍历并且实例化，假如我们只需要使用其中的一个实现，这在实现类很多的情况下无疑是对机器资源巨大的浪费。
  2. 无法按需获取实现类，不够灵活，我们需要遍历一遍所有实现类才能找到指定实现。

Dubbo SPI：在dubbo中也有SPI机制，虽然都需要将接口全限定名配置在文件中，但是dubbo并没有使用java的spi机制，而是重新实现了一套功能更强【支持AOP与依赖注入】的 SPI 机制，并且 利用缓存提高加载实现类的性能，同时支持实现类的灵活获取。基于SPI，我们可以很容易的对 Dubbo 进行拓展。例如dubbo当中的protocol，LoadBalance等都是通过SPI机制扩展。具体实现流程如下：

  1. 需要在 classpath 下创建一个目录，该目录命名可以是：META-INF/service/、META-INF/dubbo/、META-INF/dubbo/internal/。
  2. 在该目录下创建一个 文本文件，该文件需要满足以下几个条件：文件名必须是扩展的接口的全路径名称、文件内部描述的是该扩展接口的所有实现类,将服务实现类写成KV键值对的形式，Key是拓展类的name，Value是扩展的全限定名实现类。
  3. 通过 org.apache.dubbo.common.extension.ExtensionLoader 的加载机制来加载服务。

java SPI和dubbo SPI对比：

  1. Java SPI在加载扩展点的时候，会一次性加载所有可用的扩展点，很多是不需要的，会浪费系统资源。dubboSPI有选择性地加载所需要的SPI接口。
  2. javaSPI配置文件中只是简单的列出了所有的扩展实现，而没有给他们命名。导致在程序中很难去准确的引用它们。而dubboSPI配置文件中以键值对的形式有别名，易于区分。
  3. SPI扩展如果依赖其他的扩展，javaspi做不到自动注入和装配，dubbo可以实现自动注入。
  4. javaSPI不提供类似于Spring的IOC和AOP功能，dubboSPI是支持的。

Spring SPI机制之SpringFactoriesLoader约定如下：

  • 配置文件必须在META-INF/目录下，文件名必须为spring.factories。
  • 文件内容为键值对，一个键可以有多个值（逗号分割）。键和值都需要是类的全限定名，键和值可以没有任何类与类之间的关系，当然也可以有实现的关系。
// 这种方式对应的接口Driver以及配置的类可以不存在任何关系
List<String> stringList = SpringFactoriesLoader.loadFactoryNames(Driver.class, App.class.getClassLoader());
stringList.stream().forEach(item -> System.out.println(item));
// 这种方式配置的扩展类一定是接口Driver的实现类
List<Driver> drivers = SpringFactoriesLoader.loadFactories(Driver.class, App.class.getClassLoader());

如下所示：键值中值可以是任意包路径下的类。

net.csdn.spi.Driver=net.csdn.spi.Mysql,net.ali.Oracle

与Java SPI机制对比：

  1. 首先Spring的SPI机制对Java的SPI机制对进行了一些简化，Java的SPI每个接口都需要对应的文件，而Spring的SPI机制只需要一个spring.factories文件。
  2. Java的SPI机制文件内容必须为接口的实现类，而Spring的SPI并不要求键值对必须有什么关系，更加灵活。
  3. Spring的SPI机制提供了获取类限定名的方法loadFactoryNames，而Java的SPI机制是没有的。通过这个方法获取到类限定名之后就可以将这些类注入到Spring容器中，用Spring容器加载这些Bean，而不仅仅是通过反射。

Spring的SPI也同样没有实现获取指定某个指定实现类的功能，所以要想能够找到具体的某个实现类，还得依靠具体接口的设计。

所以不知道你有没有发现，PropertySourceLoader它其实就是一个策略接口，注释也有说，所以当你的配置文件是properties格式的时候，他可以找到解析properties格式的PropertiesPropertySourceLoader对象来解析配置文件。

1.ScopeModel

抽象这三个能力是为了实现 Dubbo 的多实例支持，FrameworkModel 是实现类似 JVM 租户级别的隔离，ApplicationModel 是为了实现一个机器上发布多个应用（如 demo-application1 和 demo-application2 一起发布），ModuleModel 是为了实现服务生命周期的独立管理（如一个 demo-application 可以由多个 Spring 容器共同提供）。

public abstract class ScopeModel implements ExtensionAccessor {

    private final ScopeModel parent;
    private final ExtensionScope scope;
    private ExtensionDirector extensionDirector;
    // 子类构造器中分别指定parent & scope
    public ScopeModel(ScopeModel parent, ExtensionScope scope, boolean isInternal) {
        this.parent = parent;
        this.scope = scope;
        this.internalScope = isInternal;
    }
    
    protected void initialize() {
        this.extensionDirector = new ExtensionDirector(parent != null ? parent.getExtensionDirector() : null, scope, this);
        this.extensionDirector.addExtensionPostProcessor(new ScopeModelAwareExtensionProcessor(this));
    }
    
    @Override
    public ExtensionDirector getExtensionDirector() {
        return extensionDirector;
    }
}

相关子类初始化时机：

  1. @EnableDubbo注解通过import方式引入类DubboConfigConfigurationRegistrar、DubboComponentScanRegistrar。
  2. 接口ImportBeanDefinitionRegistrar子类核心方法内部通过类DubboSpringInitializer触发ScopeModel相关子类。并且将Dubbo应用上下文DubboSpringInitContext、ApplicationModel、ModuleModel都被Spring IOC托管。--【@EnableDubbo该注解核心功能】
  3. FrameworkModel构造器中初始化ApplicationModel，ApplicationModel构造器中初始化ModuleModel。
  4. FrameworkModel、ApplicationModel、ModuleModel三者之间并没有Java编程语法意义上的继承关系，但是是通过父类ScopeModel的parent属性建立父子关系。
  5. FrameworkModel的parent属性为null，ApplicationModel的parent属性为FrameworkModel，ModuleModel的parent属性为ApplicationModel。

类ExtensionDirector作用：子类加载扩展类就是利用该类得到类ExtensionLoader完成SPI功能的。

1.1.FrameworkModel

public class FrameworkModel extends ScopeModel {
    
    public FrameworkModel() {
        super(null, ExtensionScope.FRAMEWORK, false);
        ...
        initialize();
    }

    @Override
    protected void initialize() {
        super.initialize();
        TypeDefinitionBuilder.initBuilders(this);

        serviceRepository = new FrameworkServiceRepository(this);
        // 获取 ScopeModelInitializer 类型的扩展类
        ExtensionLoader<ScopeModelInitializer> initializerExtensionLoader = this.getExtensionLoader(ScopeModelInitializer.class);
        Set<ScopeModelInitializer> initializers = initializerExtensionLoader.getSupportedExtensionInstances();
        for (ScopeModelInitializer initializer : initializers) {
            initializer.initializeFrameworkModel(this);
        }
        // 将当前类作为 ApplicationModel 的父类
        internalApplicationModel = new ApplicationModel(this, true);
        internalApplicationModel.getApplicationConfigManager().setApplication(new ApplicationConfig(internalApplicationModel, CommonConstants.DUBBO_INTERNAL_APPLICATION));
        internalApplicationModel.setModelName(CommonConstants.DUBBO_INTERNAL_APPLICATION);
    }
}

1.2.ApplicationModel

public class ApplicationModel extends ScopeModel {
    
    public ApplicationModel(FrameworkModel frameworkModel, boolean isInternal) {
        super(frameworkModel, ExtensionScope.APPLICATION, isInternal);
        this.frameworkModel = frameworkModel;
        frameworkModel.addApplication(this);
        initialize();
    }

    @Override
    protected void initialize() {
        super.initialize();
        // 将当前类作为 ModuleModel 的父类
        internalModule = new ModuleModel(this, true);
        this.serviceRepository = new ServiceRepository(this);
        // 加载 ApplicationInitListener类型 的扩展类
        ExtensionLoader<ApplicationInitListener> extensionLoader = this.getExtensionLoader(ApplicationInitListener.class);
        Set<String> listenerNames = extensionLoader.getSupportedExtensions();
        for (String listenerName : listenerNames) {
            extensionLoader.getExtension(listenerName).init();
        }
        initApplicationExts();
        // 加载 ScopeModelInitializer类型的 扩展类
        ExtensionLoader<ScopeModelInitializer> initializerExtensionLoader = this.getExtensionLoader(ScopeModelInitializer.class);
        Set<ScopeModelInitializer> initializers = initializerExtensionLoader.getSupportedExtensionInstances();
        for (ScopeModelInitializer initializer : initializers) {
            // 马上执行扩展类的核心方法
            initializer.initializeApplicationModel(this);
        }
    }
}

1.3.ModuleModel

public class ModuleModel extends ScopeModel {
    
    public ModuleModel(ApplicationModel applicationModel, boolean isInternal) {
        super(applicationModel, ExtensionScope.MODULE, isInternal);
        this.applicationModel = applicationModel;
        applicationModel.addModule(this, isInternal);
        initialize();
    }

    @Override
    protected void initialize() {
        super.initialize();
        this.serviceRepository = new ModuleServiceRepository(this);
        this.moduleConfigManager = new ModuleConfigManager(this);
        this.moduleConfigManager.initialize();
        initModuleExt();
        // 加载 ScopeModelInitializer类型的扩展类
        ExtensionLoader<ScopeModelInitializer> initializerExtensionLoader = this.getExtensionLoader(ScopeModelInitializer.class);
        Set<ScopeModelInitializer> initializers = initializerExtensionLoader.getSupportedExtensionInstances();
        for (ScopeModelInitializer initializer : initializers) {
            // 马上执行扩展类的核心方法
            initializer.initializeModuleModel(this);
        }
    }
}

2.ExtensionAccessor

利用Spi机制获取扩展类都是通过当前类先获取ExtensionLoader，后续通过ExtensionLoader加载对应的扩展类。

获取ExtensionLoader存在两种方式：

  1. 通过ExtensionDirector直接获取。
  2. 通过ExtensionAccessor间接获取。这种方式其实是通过ScopeModel间接获取到ExtensionDirector，其目的是利用ScopeModel初始化ExtensionDirector的parent属性。

如果是通过 ScopeModel 的子类获取扩展类，则必然是通过第二种方式获取ExtensionLoader。

public interface ExtensionAccessor {
    // 由 ExtensionDirector 以及 ScopeModel 类实现该方法
    ExtensionDirector getExtensionDirector();

    default <T> ExtensionLoader<T> getExtensionLoader(Class<T> type) {
        return this.getExtensionDirector().getExtensionLoader(type);
    }
    //支持获取特定name对应的扩展类
    default <T> T getExtension(Class<T> type, String name) {
        ExtensionLoader<T> extensionLoader = getExtensionLoader(type);
        return extensionLoader != null ? extensionLoader.getExtension(name) : null;
    }

    default <T> T getAdaptiveExtension(Class<T> type) {
        ExtensionLoader<T> extensionLoader = getExtensionLoader(type);
        return extensionLoader != null ? extensionLoader.getAdaptiveExtension() : null;
    }

    default <T> T getDefaultExtension(Class<T> type) {
        ExtensionLoader<T> extensionLoader = getExtensionLoader(type);
        return extensionLoader != null ? extensionLoader.getDefaultExtension() : null;
    }

}

内部方法参数type类型必须是被@SPI注解的类。

FrameworkModel、ApplicationModel、ModuleModel三者抽象父类ScopeModel实现了方法：

public interface ExtensionAccessor {
    ExtensionDirector getExtensionDirector();
}

2.1.ExtensionDirector

ExtensionDirector的作用其实就是获取扩展类的加载器ExtensionLoader。其实任何方式得到的扩展类的加载器都是ExtensionLoader，唯一的区别就是parent属性赋值与否。

ExtensionScope的取值涉及：FRAMEWORK、APPLICATION、MODULE、SELF。

public class ExtensionDirector implements ExtensionAccessor {
    private final ConcurrentMap<Class<?>, ExtensionLoader<?>> extensionLoadersMap = new ConcurrentHashMap<>(64);
    private final ConcurrentMap<Class<?>, ExtensionScope> extensionScopeMap = new ConcurrentHashMap<>(64);

    public <T> ExtensionLoader<T> getExtensionLoader(Class<T> type) {
        ...
        // 1. find in local cache
        ExtensionLoader<T> loader = (ExtensionLoader<T>) extensionLoadersMap.get(type);

        ExtensionScope scope = extensionScopeMap.get(type);
        if (scope == null) {
            SPI annotation = type.getAnnotation(SPI.class);
            scope = annotation.scope();
            extensionScopeMap.put(type, scope);
        }
        // 如果 type 的scope范围是SELF，则直接返回 ExtensionLoader，并不需要考虑 属性parent的功能
        if (loader == null && scope == ExtensionScope.SELF) {
            // create an instance in self scope
            loader = createExtensionLoader0(type);
        }

        // 2. find in parent
        if (loader == null) {
            // 条件成立的条件是：必须是通过ScopeModel子类触发的扩展类加载
            if (this.parent != null) {
                // 递归的方式
                loader = this.parent.getExtensionLoader(type);
            }
        }

        // 3. create it
        if (loader == null) {
            // type & ScopeModel 的scope值必须匹配
            loader = createExtensionLoader(type);
        }

        return loader;
    }

    private <T> ExtensionLoader<T> createExtensionLoader(Class<T> type) {
        ExtensionLoader<T> loader = null;
        if (isScopeMatched(type)) {
            // if scope is matched, just create it
            loader = createExtensionLoader0(type);
        } else {
            // if scope is not matched, ignore it
        }
        return loader;
    }

    private <T> ExtensionLoader<T> createExtensionLoader0(Class<T> type) {
        checkDestroyed();
        ExtensionLoader<T> loader;
        extensionLoadersMap.putIfAbsent(type, new ExtensionLoader<T>(type, this, scopeModel));
        loader = (ExtensionLoader<T>) extensionLoadersMap.get(type);
        return loader;
    }

    private boolean isScopeMatched(Class<?> type) {
        // 当前ScopeModel对应的scope值是否与type spi注解中scope一致
        final SPI defaultAnnotation = type.getAnnotation(SPI.class);
        return defaultAnnotation.scope().equals(scope);
    }
}

上述获取扩展类loader类似于jdk类加载器流程：

  • 抽象类ScopeModel三个子类存在非Java规范意义上的继承关系。
  • 任何一个ScopeModel的子类触发的loader流程优先获取属性parent的ExtensionLoader。
  • 目标接口type注解SPI其scope属性必须与当前ScopeModel的scope值一致方能引用当前parent的ExtensionLoader。否则继续向下寻找child对应的ExtensionLoader。
  • type的scope以及type的ExtensionLoader都存在集合类型的本地缓存。

 扩展类loader加载机制的作用：不同child需要相同的扩展类，只要scope值一样则可以由parent统一触发，避免child多次触发；child定制化的扩展类则通过scope值单独实现。

2.2.ExtensionLoader

利用ExtensionLoader获取目标接口扩展类的方式：

  1. 普通SPI实现原理：指定name获取接口的扩展类。根据接口名找到并解析配置文件，加载对应的扩展点实现类；类加载成功后就可以反射创建对象；对该对象完成IOC及AOP。

  2. 自适应SPI（Adaptive注解）实现原理：Javaassit 编译器对目标接口生成代理。代理类【type$Adaptive】执行@Adaptive方法触发目标方法执行。

2.2.1.普通SPI实现原理

public class ExtensionLoader<T> {

    private T createExtension(String name, boolean wrap) {
        //执行核心方法：利用不同策略获取扩展候选类类
        // 此处其实已经通过name得到候选类，例如利用javassist得到JavassistProxyFactory
        Class<?> clazz = getExtensionClasses().get(name);
        T instance = (T) extensionInstances.get(clazz);
        if (instance == null) {
            extensionInstances.putIfAbsent(clazz, createExtensionInstance(clazz));
            // 反射创建候选类实例
            instance = (T) extensionInstances.get(clazz);
            ...
        }
        if (wrap) {// 如果集合属性 cachedWrapperClasses 不为null，则需要通过代理方式增强目标方法功能，真正增强是通过wrap类型的候选类实现的
            List<Class<?>> wrapperClassesList = new ArrayList<>();
            if (cachedWrapperClasses != null) {
                wrapperClassesList.addAll(cachedWrapperClasses);
                wrapperClassesList.sort(WrapperComparator.COMPARATOR);
                Collections.reverse(wrapperClassesList);
            }

            if (CollectionUtils.isNotEmpty(wrapperClassesList)) {
                for (Class<?> wrapperClass : wrapperClassesList) {
                    Wrapper wrapper = wrapperClass.getAnnotation(Wrapper.class);
                    ...
                    //如果 cachedWrapperClasses 集合中存在当前type对应的候选类，则依次返回wrapper类型的候选类
                    // 实例化wrapperClass：1.获取存在type构造参数的构造器;2.将type接口类型的实现子类通过构造方法属性赋值
                    instance = injectExtension((T) wrapperClass.getConstructor(type).newInstance(instance));
                }
            }
        }
        ...
        return instance;
    }
    
}
 2.2.1.1.IOC

 场景：SPI接口中通过set开头的方法注入其他SPI接口作为属性。

  1. set方法注入条件：set开头,参数只有一个并且public修饰。
  2. set方法上没有使用 DisableInject 注解。
  3. set 方法是在ScopeModelAware 系列中声明的也不能注入。
private T createExtension(String name, boolean wrap) {
  
  // 1️⃣.加载扩展点实现类，得到class对象
  Class<?> clazz = getExtensionClasses().get(name);
  
  // 2️⃣.这里通过反射调用空参构造函数，完成实例化
  T instance = (T) EXTENSION_INSTANCES.get(clazz);
  if (instance == null) {  
    EXTENSION_INSTANCES.putIfAbsent(clazz, clazz.newInstance());
    instance = (T) EXTENSION_INSTANCES.get(clazz);
  }

  // 3️⃣.IOC
  injectExtension(instance);

  // 4️⃣.AOP
  if (wrap) {
    // .....
  }
  
  // 5️⃣.扩展点生命周期，进一步完成初始化
  initExtension(instance);
  return instance;
}

public class ExtensionLoader<T> {
    private final ExtensionInjector injector;

    private T injectExtension(T instance) {

        if (injector == null) {
            return instance;
        }
        // 遍历 当前SPI接口存在的全部方法
        for (Method method : instance.getClass().getMethods()) {
            if (!isSetter(method)) {// 如果方法不存在set方法，则表明不存在IOC注入功能
                continue;
            }
            //如果方法存在DisableInject注解，则表明不存在IOC注入功能
            if (method.isAnnotationPresent(DisableInject.class)) {
                continue;
            }
            // "set"方法只存在一个SPI接口类型的变量
            Class<?> pt = method.getParameterTypes()[0];
            if (ReflectUtils.isPrimitives(pt)) {
                continue;
            }
            // 从"set"方法名中获取 SPI接口 的名，例如setProtocol，表明SPI接口名为protocol
            String property = getSetterProperty(method);
            // 从 Dubbo IOC容器中 获取 beanName 为 property的 bean
            Object object = injector.getInstance(pt, property);
            if (object != null) {// 通过反射调用注入目标bean
                method.invoke(instance, object);
            }
        }
        return instance;
    }
}
2.2.1.2.AOP

实现AOP功能的前提条件：

  1. SPI接口的实现类至少存在两个扩展类，一个是原始类，另一个是对原始类增强的wrappr类。
  2. wrappr类的类名最好以wrappr作为前缀。
  3. wrappr类存在有参构造方法，并且参数类型SPI接口类型，有且仅有一个参数。
  4. wrappr类中目标方法是增强方法。
public class ExtensionLoader<T> {
    //增强之前，必须存在SPI接口的扩展类
    Class<?> clazz = getExtensionClasses().get(name);
    if (clazz == null || unacceptableExceptions.contains(name)) {
        throw findException(name);
    }
    ...
    if (wrap) {
        // SPI接口的扩展类必须同时存在wrapper类型的扩展类，用于增强目标类
        List<Class<?>> wrapperClassesList = new ArrayList<>();
        if (cachedWrapperClasses != null) {
            wrapperClassesList.addAll(cachedWrapperClasses);
            wrapperClassesList.sort(WrapperComparator.COMPARATOR);
            Collections.reverse(wrapperClassesList);
        }

        if (CollectionUtils.isNotEmpty(wrapperClassesList)) {
            for (Class<?> wrapperClass : wrapperClassesList) {
                Wrapper wrapper = wrapperClass.getAnnotation(Wrapper.class);
                boolean match = (wrapper == null) ||
                    ((ArrayUtils.isEmpty(wrapper.matches()) || ArrayUtils.contains(wrapper.matches(), name)) &&
                        !ArrayUtils.contains(wrapper.mismatches(), name));
                if (match) {
                    // 此处就是对 增强类的实例化，注意：反射方式实例化时构造器必须在SPI接口类型的参数。
                    // 返回的实例也是SPI接口的扩展类，只不过该扩展类内部通过 SPI接口 回调了目标方法
                    instance = injectExtension((T) wrapperClass.getConstructor(type).newInstance(instance));
                    instance = postProcessAfterInitialization(instance, name);
                }
            }
        }
    }
    return instance;
}

2.2.2.自适应SPI（Adaptive注解）实现原理

Adaptive 机制可以指定想要加载的扩展名，也可以不指定。若不指定则直接加载默认的扩展类。即其会自动匹配做到自适应。其是通过@Adaptive注解实现的。

该SPI机制的前提：

  1. 目标接口必须存在@Adaptive方法。
  2. @Adaptive方法首个参数必须是org.apache.dubbo.common.URL类型。
public class ExtensionLoader<T> {
    private final Class<?> type;//目标接口
    private Class<?> createAdaptiveExtensionClass() {
        ClassLoader classLoader = type.getClassLoader();
        // 目标接口type对应的代理类字符串形式
        String code = new AdaptiveClassCodeGenerator(type, cachedDefaultName).generate();
        org.apache.dubbo.common.compiler.Compiler compiler = extensionDirector.getExtensionLoader(
            org.apache.dubbo.common.compiler.Compiler.class).getAdaptiveExtension();
        return compiler.compile(type, code, classLoader);
    }
}

如上所示自适应SPI原理其实就是对目标接口type进行Javaassit编译生成代理类，如下所示：

public class Order$Adaptive implements net.dubbo.provider.spi.adaptive.Order {
    //非@Adaptive方法
    public java.lang.String way() {
        throw new UnsupportedOperationException("The method public abstract java.lang.String net.dubbo.provider.spi.adaptive.Order.way() of interface net.dubbo.provider.spi.adaptive.Order is not adaptive method!");
    }
    //@Adaptive方法
    public java.lang.String pay(org.apache.dubbo.common.URL arg0) {
        if (arg0 == null) throw new IllegalArgumentException("url == null");
        org.apache.dubbo.common.URL url = arg0;
        // order：目标接口名。wechat：接口@SPI指定的扩展类名。
        // 从 URL 中获取  order 的value，默认值 @SPI指定的扩展类名
        String extName = url.getParameter("order", "wechat");
        if (extName == null)throw new IllegalStateException("Failed to get extension (net.dubbo.provider.spi.adaptive.Order) name from url (" + url.toString() + ") use keys([order])");
        ScopeModel scopeModel = ScopeModelUtil.getOrDefault(url.getScopeModel(), net.dubbo.provider.spi.adaptive.Order.class);
        // 通过 普通SPI 机制获取目标接口利用 @SPI注解指定的扩展类
        Order extension = (Order) scopeModel.getExtensionLoader(Order.class).getExtension(extName);
        return extension.pay(arg0);
    }
}

所以综上所述，通过在代理类调用目标方法时可以改变 @SPI注解指定的扩展类名。

非@Adaptive方法通过代理类执行目标方法就直接抛出异常

2.3.LoadingStrategy

Dubbo SPI 的配置做出了改进，在 Dubbo 中有三种不同的目录可以存放 SPI 配置，用途也不同，优先级由低到高如下所示：

  • META-INF/services/ 目录：此目录配置文件用于兼容 JDK SPI 【ServicesLoadingStrategy】。
  •  META-INF/dubbo/ 目录：此目录用于存放用户自定义 SPI 配置文件【DubboLoadingStrategy】。
  • META-INF/dubbo/internal/ 目录：此目录用于存放 Dubbo 内部使用的 SPI 配置文件【DubboInternalLoadingStrategy】。

其中，只有ServicesLoadingStrategy在其对应目录文件中是不支持kv形式的。

3. ScopeModelInitializer

 

public interface ScopeModelInitializer {

    void initializeFrameworkModel(FrameworkModel frameworkModel);

    void initializeApplicationModel(ApplicationModel applicationModel);

    void initializeModuleModel(ModuleModel moduleModel);
}

ScopeModelInitializer存在各种实现类，并且在ScopeModel子类的构造器中完成ScopeModelInitializer相关子类的实例化。其中ConfigScopeModelInitializer主要功能是完成接口Deployer子类的实例化。

4.ExtensionInjector

@SPI(scope = ExtensionScope.SELF)
public interface ExtensionInjector extends ExtensionAccessorAware {
    @Override
    default void setExtensionAccessor(ExtensionAccessor extensionAccessor) {
    }
}

该类型接口实现类：

  1. ScopeBeanExtensionInjector：从Dubbo自己设计的IOC容器中获取。
  2. SpringExtensionInjector：从Spring IOC容器中获取目标bean。
  3. SpiExtensionInjector：利用SPI机制加载注入的目标接口实现类。
阿......嚏
关注
Dubbo SPI机制
weixin_41400063的博客
03-01 666
SPI 全称为 Service Provider Interface，是一种服务发现机制。SPI 的本质是将接口实现类的全限定名配置在文件中，并由服务加载器读取配置文件，加载实现类。这样可以在运行时，动态为接口替换实现类。正因此特性，我们可以很容易的通过 SPI 机制为我们的程序提供拓展功能。Dubbo 并未使用 Java SPI，而是重新实现了一套功能更强的 SPI 机制。
Dubbo SPI机制使用
Charge8的博客
07-10 798
Dubbo SPI机制使用
Dubbo SPI机制详解
weixin_39082432的博客
05-09 1903
什么是SPI？ 扩展点 Dubbo作用灵活的框架，并不会强制所有用户都一定使用Dubbo提供的某些架构。例如注册中心（Registry），Dubbo提供了zk和redis，但是如果我们更倾向于其他的注册中心的话，我们可以替换掉Dubbo提供的注册中心。针对这种可被替换的技术实现点我们称之为扩展点，类似的扩展点有很多，例如Protocol，Filter，Loadbalance等等。 Wrapper Dubbo在加载某个接口的扩展类时候，如果某个实现中有一个拷贝类构造函数，那么该接口实现就是该接口的包装类，
Dubbo（三）：Dubbo SPI机制
Men-DD
08-19 310
当服务提供者提供了接口的一种具体实现后，在 jar 包的 META-INF/services 目录下创建一个以“接口全限定名”为命名的文件， 内容为实现类的全限定名;接口实现类所在的 jar 包放在主程序的 classpath 中;主程序通过 java.util.ServiceLoder 动态装载实现模块，它通过扫描 META-INF/services 目录下的配置文件找到实现类的全限定名，把类加载到 JVM;SPI 的实现类必须携带一个不带参数的构造方法;...
Dubbo SPI机制和原理解析
th1996的博客
05-13 1497
简介SPI（service provider interface）是一种服务发现机制，通过加载指定路径下配置文件中的实现类，达到运行时用实现动态替换接口的目的。SPI常常用于扩展应用的功能，Dubbo就是通过SPI来加载所有的组件，因此用户可以很方便地扩展Dubbo的功能。Dubbo SPI是在JDK SPI的基础上发展过来的，相比之下，它做了一些改进和优化。改进（相比JDK SPI）JDK SPI会一次性加载所有扩展点实现，如果有的实现初始化耗时，有的没用上，会比较浪费资源。Dubbo SPI在配置文件中
dubbo SPI机制
目标检测专栏持续更新中，改进YOLO系列通用，适用v5、v7、v8、所有博客均是团队原创博客，所有文章禁止转载，违者必究。
09-01 124
SPI(Service Provider Interface)：服务提供接口本文主要介绍dubbo源码中大量使用的SPI机制，至于什么是SPI，请自行查阅基于上述自适应扩展机制，比如我想设置某个服务的负载均衡策略为每次只选择第一个，那么只要这样写根据LoadBalance spi机制，自定义自己的LoadBalance实现@Override// 测试只选择第一个}}...
dubbo SPI机制demo
ZXH240651200的博客
11-30 346
dubbo 3 SPI机制
Dubbo 3.x源码(3)—Dubbo SPI机制的介绍与使用
终生学习践行者
06-29 746
介绍了JDK的SPI机制的概念和原理，并且介绍了Dubbo SPI机制的概念和原理，以及Dubbo SPI机制的优缺点
Dubbo-SPI机制
TheOne的博客
10-12 713
SPI的全称是Service Provider Interface，是JDK内置的动态加载实现扩展点的机制，通过SPI可以动态获取接口的实现类，属于一种设计理念。系统设计的各个抽象，往往有很多不同的实现方案，在面向的对象的设计里，一般推荐模块之间基于接口编程，模块之间不对实现类进行硬编码。如果代码中引用了特定的实现类，那么就违反了可插拔的原则。为了进行实现的替换，需要对代码进行修改。需要一种服务发现机制，以实现在模块装配时无需在程序中动态指定。最常见的使用案例有JDBC、Dubbo和Spring。笔者在代码
dubbo SPI机制与@Adaptive自适应扩展机制
RicardoDing的博客
07-24 608
1.@Adaptive使用规则疑云 近期，在阅读dubbo服务暴露相关源码时，有一点引起了我的注意。 在很多dubbo源码的解读文章中，都告诉我们，对于被@Adaptive接口修饰的方法，我们都需要在其方法参数中提供一个url参数，并且在url的参数列表中指定我们所需要的扩展实现，如： @SPI("Mercedes") public interface MyCar { //汽车运行 @Adaptive void run(UR...
Dubbo SPI 机制 代码实现，dubbo-2.6.0 源码
03-14
dubbo-2.6.0 源码
dubbo spi可扩展机制源码解析
12-24
总结来说，Dubbo SPI机制通过元数据配置、服务加载、服务发现、扩展点和动态代理等手段，实现了服务的高可扩展性和灵活性。开发者可以轻松地添加新的服务实现或扩展已有功能，而无需修改原有代码，符合开放封闭原则...
dubbo spi机制
gechijian3972的博客
02-05 377
想要深入理解dubbo，SPI机制是绕不过去的，面试中也经常被提问到，dubbo大部分组件都是基于SPI机制实现的。 那么什么是SPI机制呢，要解决什么问题呢， 实际上要解决的问题就是，一个接口有多个实现类时，具体实现类不在程序中直接确定，而是由程序之外的配置掌控。这是设计模式中的策略模式。 dubbo SPI是基于java SPI机制实现的，进行一定的改造和优化，我们知道dubbo是以总线模式来时刻传递和保存配置信息的，也就是配置信息都被放在URL上进行传递。 。。。java SPI 介绍 截图
Spring Boot中的响应与分层解耦架构
hong161688的博客
09-20 1096
数据访问层的设计应遵循高内聚低耦合的原则，即各个模块之间的依赖关系应尽可能少，而模块内部的功能应尽可能紧密。在Spring Boot应用程序中，分层解耦的三层架构是一种常见的设计模式，它将应用程序分为表示层、业务逻辑层和数据访问层（也称为持久层），以提高代码的可维护性、可扩展性和复用性。当需要添加新的功能时，只需要在相应的层中添加新的类或方法即可，而不需要修改其他层的代码。在Spring Boot中，Controller层负责接收前端发送的请求，并处理这些请求，最终返回响应数据给前端。
十三、SOA（企业服务总线ESB架构实现）
最新发布
xiaoqi270620903的专栏
09-20 650
*企业服务总线（ESB）**是SOA架构的重要组成部分，通过提供协议转换、消息路由、服务编排和监控等功能，ESB帮助企业实现了跨系统、跨平台的集成。通过有效的ESB实施，企业可以提高系统的灵活性、可扩展性和效率，同时降低维护复杂度。企业服务总线（ESB）提供了强大的集成能力，但同时也带来了各种风险与挑战，如单点故障、性能瓶颈、复杂性、安全性等问题。在实施和维护ESB时，企业需要仔细规划和设计，采用合适的技术和管理手段来应对这些挑战，确保架构的稳定性和可扩展性。
Feed流系统重构：架构篇
m0_72864708的博客
09-18 1262
移动互联网时代，Feed 流产品是非常常见的，比如我们每天都会用到的朋友圈，微博，就是一种非常典型的 Feed 流产品。Feed (动态)：Feed 流中的每一条状态或者消息都是 Feed，比如朋友圈中的一个状态就是一个 Feed，微博中的一条微博就是一个 Feed。Feed 流：持续更新并呈现给用户内容的信息流。每个人的朋友圈，微博关注页等等都是一个 Feed 流。家校朋友圈是校信 app 的一个子功能。学生和老师可以发送图片，视频，声音等动态信息，学生和老师可以查看班级下的动态聚合。为什么要重构呢。
Imagen架构详解：理解其背后的技术与创新
weixin_41859354的博客
09-17 1292
生成式模型是指能够生成新数据的机器学习模型，通常用于图像、文本、音频等领域。文本到图像生成模型通过将自然语言描述映射到图像空间，从而生成符合文本描述的图像。早期的生成模型如 GAN（生成对抗网络）和 VAE（变分自编码器）取得了不错的成果，但它们在复杂细节和文本一致性方面的表现较弱。扩散模型（Diffusion Models）是一种生成式模型，近些年在生成任务中表现出色。其工作原理是逐渐向数据添加噪声，最终将其转化为纯噪声，然后通过学习反向扩散过程，逐步去噪，生成目标图像。
Ceph 基本架构（一）
Lzcsfg的博客
09-20 897
Ceph 的 MON 节点通过无中心化的共识机制来确保集群的一致性和高可用性。当某个 MON 节点失效时，剩余的 MON 节点会继续工作，并在必要时重新选举一个领导者来协调特定的操作。这种设计使得 Ceph 能够在单点故障的情况下继续保持正常运行，提高了系统的可靠性和稳定性。
Dubbo SPI机制与服务发布的深入解析
Dubbo的SPI机制会从多个文件中查找扩展点实现，包括`META-INF/dubbo/internal/`（用于内部实现）、`META-INF/dubbo/`和`META-INF/services/`。`loadExtensionClasses`方法负责读取这些文件，解析出扩展点的实现类。...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值