Dubbo进阶（六）- Dubbo SPI 源码级过程详解

最新推荐文章于 2024-03-22 14:44:17 发布
最新推荐文章于 2024-03-22 14:44:17 发布
阅读量1.1k 收藏 2
点赞数
分类专栏： dubbo 文章标签： dubbo SPI 中间件 Java
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/anla_/article/details/99774045
版权

Dubbo SPI 是Dubbo用于支持 扩展 一个功能。

关于 SPI 的具体意思以及内容，相信 官方这篇文档已经讲的足够通俗易懂了：
http://dubbo.apache.org/zh-cn/blog/introduction-to-dubbo-spi.html

里面提到了两点对于SPI 功能的解释，有两点：

  1. 作为框架的维护者，在添加一个新功能时，只需要添加一些新代码，而不用大量的修改现有的代码，即符合开闭原则。
  2. 作为框架的使用者，在添加一个新功能时，不需要去修改框架的源码，在自己的工程中添加代码即可。

Dubbo 支持多种协议，多种配置中心，注册中心，传输层协议的配置，当然里面也有相关代码维护，如果以设计模式角度来说，当然可以通过工厂模式来完成多协议的配置。

上文中对于 SPI 的优点，从框架维护者到使用者都有涉及，不多废话，听博主一层一层解析SPI 过程吧

本文将以以下问题展开：

  1. dubbo SPI 关键类，ExtensionLoader 是共享的，还是一个SPI一个？
  2. ExtensionLoader 是如何初始化的？
  3. SPI 类文件在哪些路径下面？
  4. SPI 加载过程 是怎样的？

以上问题看完文章后相信大家就可以清楚，若有疑问，关注博主公众号：六点A君，回复标题获取最新答案><

获取

主要从 ReferenceConfig 入手，它里面有 声明具有 SPI 声明的多个接口，这里以 Protocol 为例：

private static final Protocol REF_PROTOCOL = ExtensionLoader.getExtensionLoader(Protocol.class).getAdaptiveExtension();

接下来看看 Protocol 的声明：


/**
 * Protocol. (API/SPI, Singleton, ThreadSafe)
 */
@SPI("dubbo")
public interface Protocol {

    int getDefaultPort();
    @Adaptive
    <T> Exporter<T> export(Invoker<T> invoker) throws RpcException;

    @Adaptive
    <T> Invoker<T> refer(Class<T> type, URL url) throws RpcException;

    void destroy();
}

Protocol 使用了 @SPI 修饰，并且有了默认值是 dubbo，同时定义了 export，refer等方法。

getExtensionLoader

进去看看 getExtensionLoader 方法：

    public static <T> ExtensionLoader<T> getExtensionLoader(Class<T> type) {
        // 检查下type是否为null
        if (type == null) {
            throw new IllegalArgumentException("Extension type == null");
        }
        // 检查是否为接口
        if (!type.isInterface()) {
            throw new IllegalArgumentException("Extension type (" + type + ") is not an interface!");
        }
        // 检查是否有 @SPI 注解
        if (!withExtensionAnnotation(type)) {
            throw new IllegalArgumentException("Extension type (" + type +
                    ") is not an extension, because it is NOT annotated with @" + SPI.class.getSimpleName() + "!");
        }
		// 尝试从缓存中去加载
        ExtensionLoader<T> loader = (ExtensionLoader<T>) EXTENSION_LOADERS.get(type);
        if (loader == null) {
            EXTENSION_LOADERS.putIfAbsent(type, new ExtensionLoader<T>(type));
            loader = (ExtensionLoader<T>) EXTENSION_LOADERS.get(type);
        }
        return loader;
    }

前面有对 type 进行 判断，包括：

  1. 为空
  2. 是否为接口
  3. 是否有 SPI 注解

最后尝试去 EXTENSION_LOADERS 获取，如果没有的化，则会new一个ExtensionLoader<T>(type) 放入，
最后也同样是 返回该 ExtensionLoader。

ExtensionLoader 构造方法

    private ExtensionLoader(Class<?> type) {
        this.type = type;
        objectFactory = (type == ExtensionFactory.class ? null : ExtensionLoader.getExtensionLoader(ExtensionFactory.class).getAdaptiveExtension());
    }

首先会记录该 type，作为 SPI 的类型，而后会去初始化 objectFactory， 如果当前type是 ExtensionFactory，则初始化为null，否则继续调用 ExtensionLoader 的 getExtensionLoader 去获取 ExtensionFactory 这个 SPI 实例。
这是一个递归调用，所以下一个先回调用 getExtensionLoader ，而后会给 ExtensionFactory 也分配一个 ExtensionLoader，而后执行完之后，则会调用 ExtentionLoader 的 getAdaptiveExtension。

getAdaptiveExtension

这里以传入的 type 为 ExtensionFactory 的 getAdaptiveExtension：

    public T getAdaptiveExtension() {
    // 看是否已经初始化了
        Object instance = cachedAdaptiveInstance.get();
        if (instance == null) {
            if (createAdaptiveInstanceError == null) {
                synchronized (cachedAdaptiveInstance) {
                // 再尝试获取一次
                    instance = cachedAdaptiveInstance.get();
                    if (instance == null) {
                        try {
                        	// 初始化
                            instance = createAdaptiveExtension();
                            // 放入 cachedAdaptiveInstance 中
                            cachedAdaptiveInstance.set(instance);
                        } catch (Throwable t) {
                        	// 报错了，放入了 createAdaptiveInstanceError
                            createAdaptiveInstanceError = t;
                            throw new IllegalStateException("Failed to create adaptive instance: " + t.toString(), t);
                        }
                    }
                }
            } else {
            // 说明出错了
                throw new IllegalStateException("Failed to create adaptive instance: " + createAdaptiveInstanceError.toString(), createAdaptiveInstanceError);
            }
        }
		// 返回instance
        return (T) instance;
    }

判断是 当前缓存的 cachedAdaptiveInstance 优先实例 为 空，如果为空，则需要调用 createAdaptiveExtension 创建一个。

createAdaptiveExtension

在 createAdaptiveExtension 中，则主要会调用 getAdaptiveExtensionClass 获取优先加载的类，并使用 newInstance new出实例。
而后则会调用 injectExtension 对newInstance 出来的实例进行 SPI 属性注入。

getAdaptiveExtensionClass

    private Class<?> getAdaptiveExtensionClass() {
       // 加载类
        getExtensionClasses();
        if (cachedAdaptiveClass != null) {
            return cachedAdaptiveClass;
        }
        // 如果加载的类中，没有 @Adaptive类型，则需要创建一个默认的 @Adaptive字节码类。
        return cachedAdaptiveClass = createAdaptiveExtensionClass();
    }

首先会调用 getExtensionClass 去从 文件目录下读取类，而后将 有 @Adaptive 的进行初始化。

getExtensionClasses

getExtensionClass 则会先判断 该类型的 SPI 类是否已经加载，即从 cachedClasses 中读取。否则将会调用 loadExtensionClasses 去调用。

    private Map<String, Class<?>> getExtensionClasses() {
        Map<String, Class<?>> classes = cachedClasses.get();
        // 判断是否已经缓存
        if (classes == null) {
            synchronized (cachedClasses) {
                classes = cachedClasses.get();
                if (classes == null) {
                // 否则将会去获取load 以下对应文件中内容
                    classes = loadExtensionClasses();
                    cachedClasses.set(classes);
                }
            }
        }
        return classes;
    }

loadExtensionClasses

loadExtensionClasses 则是从不同位置文件夹去加载配置，由于 加入旧版本的支持，所以会 将根目录下 com.alibaba 对应包名也处理下：

    private Map<String, Class<?>> loadExtensionClasses() {
        cacheDefaultExtensionName();

        Map<String, Class<?>> extensionClasses = new HashMap<>();
        loadDirectory(extensionClasses, DUBBO_INTERNAL_DIRECTORY, type.getName());
        loadDirectory(extensionClasses, DUBBO_INTERNAL_DIRECTORY, type.getName().replace("org.apache", "com.alibaba"));
        loadDirectory(extensionClasses, DUBBO_DIRECTORY, type.getName());
        loadDirectory(extensionClasses, DUBBO_DIRECTORY, type.getName().replace("org.apache", "com.alibaba"));
        loadDirectory(extensionClasses, SERVICES_DIRECTORY, type.getName());
        loadDirectory(extensionClasses, SERVICES_DIRECTORY, type.getName().replace("org.apache", "com.alibaba"));
        return extensionClasses;
    }

在 cacheDefaulltExtensionName 方法中，主要目的就是解析 @SPI注解，获取 value值，然后将 value值 存储到 当前ExtensionLoader 的cachedDefaultName 中。
接下来执行了多次 loadDirectory，主要就是加载 META-INF 下面 类名相同的扩展文件，主要就是 dubbo 的SPI机制。
主要有以下几个方面：

  1. META-INF/dubbo/internal/
  2. META-INF/dubbo/
  3. META-INF/services/

另外，对于旧版本的 SPI问题，Dubbo也给出了解决方案，使用 type.getName().replace("org.apache", "com.alibaba") 将 org.apache 改为com.alibaba
通过给定的 ExtensionLoader中的type，从而加载对应名字的 SPI 文件。
从而反射将其初始化。

    private void loadDirectory(Map<String, Class<?>> extensionClasses, String dir, String type) {
        String fileName = dir + type;
        try {
            Enumeration<java.net.URL> urls;
            // 获取类加载器
            ClassLoader classLoader = findClassLoader();
            if (classLoader != null) {
                // url 是文件的地址，这一步只是加载对应 spi 文件名 的所有的文件地址
                urls = classLoader.getResources(fileName);
            } else {
                // 直接加载系统资源
                urls = ClassLoader.getSystemResources(fileName);
            }
            if (urls != null) {
                while (urls.hasMoreElements()) {
                    java.net.URL resourceURL = urls.nextElement();
                    loadResource(extensionClasses, classLoader, resourceURL);
                }
            }
        } catch (Throwable t) {
            logger.error("Exception occurred when loading extension class (interface: " +
                    type + ", description file: " + fileName + ").", t);
        }
    }

loadResource

由于 spi 文件的 格式是key=value ，所以需要读取这一段并加载里面所得到的类名：
另外，由于 在loadResource时候，有些 可插拔式的接口并没有完全引入相应的包，例如在加载 Protocol 的SPI时候，初始化
hessian=org.apache.dubbo.rpc.protocol.hessian.HessianProtocol，如果没有引入 hessian 相应依赖，则会报错，放入 exceptions中。

    private void loadResource(Map<String, Class<?>> extensionClasses, ClassLoader classLoader, java.net.URL resourceURL) {
        try {
            try (BufferedReader reader = new BufferedReader(new InputStreamReader(resourceURL.openStream(), StandardCharsets.UTF_8))) {
                String line;
                while ((line = reader.readLine()) != null) {
                    // 读取一行，# 标识注释
                    final int ci = line.indexOf('#');
                    if (ci >= 0) {
                        line = line.substring(0, ci);
                    }
                    // 过滤空格
                    line = line.trim();
                    if (line.length() > 0) {
                        try {
                            String name = null;
                            int i = line.indexOf('=');
                            if (i > 0) {
                                name = line.substring(0, i).trim();
                                line = line.substring(i + 1).trim();
                            }
                            if (line.length() > 0) {
                            // 加载类。
                                loadClass(extensionClasses, resourceURL, Class.forName(line, true, classLoader), name);
                            }
                        } catch (Throwable t) {
                            // 允许报错，因为dubbo 的spi里面定义了 很多协议，但是需要有对应jar包引入，如果没有引入，则在这一步，则会报错，例如hessian 和 http。webservice等
                            // 这一步错误，主要是在 Class.forName 这一步出错。
                            IllegalStateException e = new IllegalStateException("Failed to load extension class (interface: " + type + ", class line: " + line + ") in " + resourceURL + ", cause: " + t.getMessage(), t);
                            exceptions.put(line, e);
                        }
                    }
                }
            }
        } catch (Throwable t) {
            logger.error("Exception occurred when loading extension class (interface: " +
                    type + ", class file: " + resourceURL + ") in " + resourceURL, t);
        }
    }

loadClass

这个方法挺重要的，在初始化对应 SPI 中类时候，需要对其类进行区分：

  1. @Adaptive 的修饰类
  2. Wrapper类
  3. 普通扩展类
    区分后，并缓存到不同地方。
 private void loadClass(Map<String, Class<?>> extensionClasses, java.net.URL resourceURL, Class<?> clazz, String name) throws NoSuchMethodException {
        // 检查是否有几成关系
        if (!type.isAssignableFrom(clazz)) {
            throw new IllegalStateException("Error occurred when loading extension class (interface: " +
                    type + ", class line: " + clazz.getName() + "), class "
                    + clazz.getName() + " is not subtype of interface.");
        }
        if (clazz.isAnnotationPresent(Adaptive.class)) {
        //  缓存clazz，到 cachedAdaptiveClass 中
            cacheAdaptiveClass(clazz);
        } else if (isWrapperClass(clazz)) {
        // 包装类，就是这个类有一个构造方法，然后只有一个参数就是type
            cacheWrapperClass(clazz);
        } else {
            clazz.getConstructor();
            if (StringUtils.isEmpty(name)) {
                name = findAnnotationName(clazz);
                if (name.length() == 0) {
                    throw new IllegalStateException("No such extension name for the class " + clazz.getName() + " in the config " + resourceURL);
                }
            }

            String[] names = NAME_SEPARATOR.split(name);
            if (ArrayUtils.isNotEmpty(names)) {
            // 缓存 Activate的class
                cacheActivateClass(clazz, names[0]);
                for (String n : names) {
                // 缓存名字，可以多个名字对应同一个类 到 
                    cacheName(clazz, n);
                // 缓存类
                    saveInExtensionClass(extensionClasses, clazz, name);
                }
            }
        }
    }

最后执行 saveInExtensionClass，将 对应 SPI 扩展类，放到 extensionClass中，依次返回给loadResource、loadDirectory、loadExtensionClasses，最终设置给 cachedClasses。

总结

总结以下，整个 SPI 加载过程

  1. 通过 静态方法 ExtensionLoader.getExtensionLoader 去初始化或者获取已有的 ExtensionLoader
  2. 在 getExtensionLoader 中会先去检查该type是否已经加载，有则直接返回，否则new 一个 ExtensionLoader 返回
  3. getAdaptiveExtension 主要获取使用 @Adaptive 修饰的 扩展，可以理解为默认扩展
  4. 如果从来没有加载过该扩展，则会尝试去DUBBO_INTERNAL_DIRECTORY，DUBBO_DIRECTORY，SERVICES_DIRECTORY 去加载对应文件名为 type 的SPI 类。
  5. 最后将加载过得 SPI 类缓存在 ExtensionLoader中。
    而后，会将已经加载的放入ExtensionLoader 的多个字段缓存中，具体可以看以下表格

ExtensionLoader详解

ExtensionLoader 是 SPI 功能的一个核心的类，这里单独提出来，对其机制，以及 字段进行单独分析，可以先读完全篇文章在读这里
字段：

字段名类型作用
EXTENSION_LOADERSConcurrentMap<Class<?>, ExtensionLoader<?>>用于存储 该 type 的 SPI 所对应的 ExtensionLoader如果有则说明该类型的 SPI已经Load 过
objectFactoryExtensionFactoryExtensionFactory 也是一个SPI类，主要用于加载 SPI类，主要有 SpiExtensionFactory 和 SpringExtensionFactory 和 AdaptiveExtensionFactory
cachedAdaptiveInstanceHolder<Object>用于保存当前的 该 SPI 的 优先缓存实例
cachedWrapperClassesSet<Class<?>>用于存储该 SPI 类对应的 Wrapper 类，即包装类，包装类主要作用可以使Filter或者修饰作用，其特点是 有一个单参数的构造方法，且其参数为 该 SPI 类
cachedNamesConcurrentMap<Class<?>, String>将 SPI 文件中，以Class 为key， name为value
cachedActivatesMap<String, Object>用于存储 被 @Active 注解修饰的类和映射，名字是 SPI 对应的key，Object是 Activate 对象

题外

如果整个扩展子类都没有使用 @Adaptive 修饰怎么办？此时 使用的是 @SPI 中的默认扩展名字。并且 Dubbo 会生成一个默认的代理，通过SPI 中 默认扩展名字获取具体的 扩展类。
而后使用createAdaptiveExtensionClass 生成代理类，欲知下文如何，且看下篇分析

觉得博主写的有用，不妨关注博主公众号: 六点A君。
哈哈哈，Dubbo小吃街不迷路：
在这里插入图片描述

6点A君
关注
专栏目录
【Java教程】dubbo源码解析-服务暴露与发现
Blue92120的博客
09-26 577
1、Invoker 是实体域，它是 Dubbo 的核心模型，其它模型都向它靠扰，或转换成它，它代表一个可执行体，可向它发起 invoke 调用，它有可能是一个本地的实现，也可能是一个远程的实现，也可能一个集群实现。此方法代码很长，主要完成的配置加载，检查，以及创建引用的代理对象。Dubbo是运行在spring容器中，dubbo的配置文件也是通过spring的配置文件applicationContext.xml来加载，所以dubbo的自定义配置标签实现，其实同样依赖spring的xml schema机制。
dubbo源码分析学习---dubbo 重要内容Invoker 和服务注册过程
qq_36697880的博客
11-05 633
这篇文章主要续接上一篇文章的基础上做的分析学习。前面没有分析 Invoker，我们来简单看看 Invoker 到底是一个啥东西。 一、Invoker 是什么 从前面的分析来看，服务的发布分三个阶段： 第一个阶段会创造一个 invoker 第二个阶段会把经历过一系列处理的 invoker（各种包装），在 DubboProtocol 中保存到 exporterMap 中 第三个阶段把 dubbo 协议的 url 地址注册到注册中心上 Invoker 是 Dubbo 领域模型中非常重要的...
2.2 dubbo-spi源码解析
weixin_33889665的博客
10-01 87
1 package com.alibaba.dubbo.demo.test; 2 3 import com.alibaba.dubbo.common.extension.ExtensionLoader; 4 import com.alibaba.dubbo.rpc.Protocol; 5 6 public class TestExtension { 7 public s...
从Java SPI机制实现到Dubbo SPI扩展
java界的小学生
01-20 2192
SPI扩展 SPI 全称为 Service Provider Interface，是一种服务发现机制。SPI 的本质是将接口实现类的全限定名配置在文件中，并由服务加载器读取配置文件，加载实现类。这样可以在运行时，动态为接口替换实现类。正因此特性，我们可以很容易的通过 SPI 机制为我们的程序提供拓展功能。SPI 机制在第三方框架中也有所应用，比如 Dubbo 就是通过 SPI 机制加载所有的组件。...
dubbo SPI的实现过程
u010627840的专栏
09-23 227
1. 问题 dubbo的自适应类加载机制是如何实现的？ 例如，Protocol的实现类是如何加载的 // 如何解析 private static final Protocol REF_PROTOCOL = (Protocol)ExtensionLoader.getExtensionLoader(Protocol.class).getAdaptiveExtension(); ...
dubbo的spi流程 总结
wzn232614的博客
02-21 253
Dubbo源码-SPI
hzqf的博客
07-27 284
上一篇我们讲了Dubbo的快速指南,今天就开始我们的源码之旅.这里先给大家介绍一下spi机制. SPI(JDK)   SPI的设计目标: SPI的全名为Service Provider Interface.在面想对象的设计里,模块之间是基于接口编程,模块之间不对实现类进行硬编码.一旦代码涉及具体的实现类,那么久违反了可拔插的原则,如果需要替换一种实现类,就需要修改代码. 为了实现在模块装配...
dubbo源码分析-consumer端5-Filter
youaremoon的专栏
05-07 5734
前面一篇dubbo源码分析中，我们对ClusterInvoker和LoadBalance进行了分析，可以知道ClusterInvoker在一批Invoker中选择了一个Invoker来进行调用，而这里的Invoker是通过RegistryDirectory得到的，而RegistryDirectory返回的Invoker实现为：InvokerDelegete（RegistryDirectory的内部
dubbo+zookeeper案例,dubbo和Zookeeper详解,Java源码.zip
09-30
在Java源码层面，Dubbo提供了丰富的API和 SPI（Service Provider Interface）机制，允许开发者通过自定义插件来扩展其功能。Zookeeper的Java客户端则提供了对Zookeeper服务器操作的基本接口，如create、delete、...
dubbo源码解析
01-27
### Dubbo源码解析 #### 一、Dubbo框架概览与SPI机制 **Dubbo**作为一款高性能、轻量级的微服务框架，在分布式系统领域有着广泛的应用。其核心特性之一是采用了微内核+插件体系的设计理念，使得整体架构既灵活又...
DUBBO SPI部分源码浅析
喝不醉的solace的博客
09-12 460
private static final Protocol protocol = ExtensionLoader.getExtensionLoader(Protocol.class).getAdaptiveExtension();这里先上核心代码。 在分析dubbo源码时，我们发现每个config类里面都有这段代码。 首先，protocal类带有spi注解，我们可以确认，默认使用的DUBBO-P
Dubbo-SPI源码看这篇就够了
weixin_39313241的博客
05-18 486
JAVA SPI 与API 对比 SPI的全称是Service Provider Interface，是Java提供的可用于第三方实现和扩展的机制，通过该机制，我们可以实现解耦，SPI接口方负责定义和提供默认实现，SPI调用方可以按需扩展 API的全称是Application Programming Interface，广义上来看就是接口，负责程序与程序之间进行协作的通道，就好比上面给的例子，【我们封装好了一套服务，通过API的形式提供给他人使用，别人使用API就能得到想要的】 所以他们俩的区别就很明显
dubbo spi 源码分析
你就像甜甜的益达
03-23 761
文章目录java spi,dubbo spi测试源码分析ExtensionLoader入口createExtension创建拓展对象的过程getExtensionClasses获取所有的拓展类 java spi,dubbo spi Java SPI的缺点： 不支持按需加载，迭代器遍历会实例化所有的实现类，即使它没有被用到，太浪费资源了。 获取实现类的方式不灵活，只能通过迭代器遍历。 没有缓存，实现类会被多次创建。 扩展加载失败，失败原因丢失，不方便排查。 不支持AOP和IOC。 Dubbo SPI定义了
Dubbo源码（1）——SPI
想当厨子的程序媛
03-18 257
未完待续。。。。。 一、SPI的目的 获取一个实现类的对象。 JDK的SPI，新建接口，然后定义不同实现，然后META-INF\dubbo\internal下定义定义接口的全路径的文件，文件中写上接口的全部实现类，最后代码通过ServiceLoader加载，循环迭代得到所有实现类 1.1 途径 途径： ExtensionLoader.getExtension(String name) 所以说du...
Dubbo SPI源码分析
Charge8的博客
07-10 304
Dubbo SPI源码分析
Dubbo中SPI源码解析
chijunmei7041的博客
02-24 173
从两个示例代码，介绍dubbo的SPI的使用以及相关源码分析，分析了获取扩展实现和获取自适应扩展点实现的源码，最后简单说了下ExtensionFactory的流程，看完就可以理解为什么dubbo是自包含的了。从上往下看，再回头看，应该能看明白，文章比较长，希望能耐心读下去。如果有错误的地方希望...
Dubbo源码之SPI
weixin_33935505的博客
02-17 227
Dubbo 源码分析 1. Dubbo的扩展机制 在Dubbo的官网上，Dubbo描述自己是一个高性能的RPC框架。今天我想聊聊Dubbo的另一个很棒的特性, 就是它的可扩展性。 如同罗马不是一天建成的，任何系统都一定是从小系统不断发展成为大系统的，想要从一开始就把系统设计的足够完善是不可能的，相反的，我们应该关注当下的需求，然后再不断地对系统进行迭代。在代码层面，要求我们适当的对关注点进行抽象和...
dubbo源码系列2-Dubbo SPI源码
大龙的博客
10-21 353
简介 SPI 全称为 Service Provider Interface，是一种服务发现机制。SPI 的本质是将接口实现类的全限定名配置在文件中，并由服务加载器读取配置文件，加载实现类。这样可以在运行时，动态为接口替换实现类。正因此特性，我们可以很容易的通过 SPI 机制为我们的程序提供拓展功能。SPI 机制在第三方框架中也有所应用，比如 Dubbo 就是通过 SPI 机制加载所有的组件。不过...
【Dubbo源码】SPI机制源码解析，java开发大厂面试经验
最新发布
m0_60452293的博客
03-22 638
按照上面的过程，4个月的时间刚刚好。当然Java的体系是很庞大的，还有很多更高级的技能需要掌握，但不要着急，这些完全可以放到以后工作中边用别学。学习编程就是一个由混沌到有序的过程，所以你在学习过程中，如果一时碰到理解不了的知识点，大可不必沮丧，更不要气馁，这都是正常的不能再正常的事情了，不过是“人同此心，心同此理”的暂时而已。道路是曲折的，前途是光明的！O等大厂，18年进入阿里一直到现在。**
Dubbo SPI源码深度解析：打造高效分布式服务
"深度解析Dubbo的可扩展机制SPI源码：从理论到实践，打造高效、稳定的分布式服务框架" Dubbo的可扩展性是通过其Service Provider Interface (SPI) 实现的，这是一种允许用户自定义扩展点并动态加载的机制。SPI的...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值