Dubbo

1、简介

SPI 全称为 Service Provider Interface,是一种服务发现机制。SPI 的本质是将接口实现类的全限定名配置在文件中,并由服务加载器读取配置文件,加载实现类。这样可以在运行时,动态为接口替换实现类。正因此特性,可以很容易的通过 SPI 机制为程序提供拓展功能。SPI 机制在第三方框架中也有所应用,比如 Dubbo 就是通过 SPI 机制加载所有的组件。不过,Dubbo 并未使用 Java 原生的 SPI 机制,而是对其进行了增强,使其能够更好的满足需求。在 Dubbo 中,SPI 是一个非常重要的模块。基于 SPI,可以很容易的对 Dubbo 进行拓展。Dubbo 中,SPI 主要有两种用法,一种是加载固定的扩展类,另一种是加载自适应扩展类。这两种方式会在下面详细的介绍。需要特别注意的是: 在 Dubbo 中,基于 SPI 扩展加载的类是单例的。

1.1 加载固定的扩展类

如果让你来设计加载固定扩展类,会怎么做了?一种常见思路是读取特定目录下的配置文件,然后解析出全类名,通过反射机制来实例化这个类,然后将这个类放在集合中存起来,如果有需要的时候,直接从集合中取。Dubbo 中的实现也是这么一个思路。不过在 Dubbo 中,实现的更加完善,它实现类了 IOC 和 AOP 的功能。IOC 就是说如果这个扩展类依赖其他属性,Dubbo 会自动的将这个属性进行注入。这个功能如何实现了?一个常见思路是获取这个扩展类的 setter 方法,调用 setter 方法进行属性注入。AOP 指的是什么了?这个说的是 Dubbo 能够为扩展类注入其包装类。比如 DubboProtocol 是 Protocol 的扩展类,ProtocolListenerWrapperDubboProtocol 的包装类。

1.2 加载自适应扩展类

先说明下自适应扩展类的使用场景。比如有需求,在调用某一个方法时,基于参数选择调用到不同的实现类。和工厂方法有些类似,基于不同的参数,构造出不同的实例对象。在 Dubbo 中实现的思路和这个差不多,不过 Dubbo 的实现更加灵活,它的实现和策略模式有些类似。每一种扩展类相当于一种策略,基于 URL 消息总线,将参数传递给 ExtensionLoader,通过 ExtensionLoader 基于参数加载对应的扩展类,实现运行时动态调用到目标实例上。

2、Dubbo SPI 源码分析

2.1 加载固定的扩展类

Dubbo 中,SPI 加载固定扩展类的入口是 ExtensionLoadergetExtension 方法,下面对拓展类对象的获取过程进行详细的分析。

  1. public T getExtension(String name) {
  2. if (name == null || name.length() == 0)
  3. throw new IllegalArgumentException("Extension name == null");
  4. if ("true".equals(name)) {
  5. // 获取默认的拓展实现类
  6. return getDefaultExtension();
  7. }
  8. // Holder,顾名思义,用于持有目标对象
  9. Holder<Object> holder = cachedInstances.get(name);
  10. // 这段逻辑保证了只有一个线程能够创建 Holder 对象
  11. if (holder == null) {
  12. cachedInstances.putIfAbsent(name, new Holder<Object>());
  13. holder = cachedInstances.get(name);
  14. }
  15. Object instance = holder.get();
  16. // 双重检查
  17. if (instance == null) {
  18. synchronized (holder) {
  19. instance = holder.get();
  20. if (instance == null) {
  21. // 创建拓展实例
  22. instance = createExtension(name);
  23. // 设置实例到 holder 中
  24. holder.set(instance);
  25. }
  26. }
  27. }
  28. return (T) instance;
  29. }

上面代码的逻辑比较简单,首先检查缓存,缓存未命中则创建拓展对象。下面来看一下创建拓展对象的过程是怎样的。

  1. private T createExtension(String name, boolean wrap) {
  2. // 从配置文件中加载所有的拓展类,可得到“配置项名称”到“配置类”的映射关系表
  3. Class<?> clazz = getExtensionClasses().get(name);
  4. // 如果没有该接口的扩展,或者该接口的实现类不允许重复但实际上重复了,直接抛出异常
  5. if (clazz == null || unacceptableExceptions.contains(name)) {
  6. throw findException(name);
  7. }
  8. try {
  9. T instance = (T) EXTENSION_INSTANCES.get(clazz);
  10. // 这段代码保证了扩展类只会被构造一次,也就是单例的.
  11. if (instance == null) {
  12. EXTENSION_INSTANCES.putIfAbsent(clazz, clazz.getDeclaredConstructor().newInstance());
  13. instance = (T) EXTENSION_INSTANCES.get(clazz);
  14. }
  15. // 向实例中注入依赖
  16. injectExtension(instance);
  17. // 如果启用包装的话,则自动为进行包装.
  18. // 比如我基于 Protocol 定义了 DubboProtocol 的扩展,但实际上在 Dubbo 中不是直接使用的 DubboProtocol, 而是其包装类
  19. // ProtocolListenerWrapper
  20. if (wrap) {
  21. List<Class<?>> wrapperClassesList = new ArrayList<>();
  22. if (cachedWrapperClasses != null) {
  23. wrapperClassesList.addAll(cachedWrapperClasses);
  24. wrapperClassesList.sort(WrapperComparator.COMPARATOR);
  25. Collections.reverse(wrapperClassesList);
  26. }
  27. // 循环创建 Wrapper 实例
  28. if (CollectionUtils.isNotEmpty(wrapperClassesList)) {
  29. for (Class<?> wrapperClass : wrapperClassesList) {
  30. Wrapper wrapper = wrapperClass.getAnnotation(Wrapper.class);
  31. if (wrapper == null
  32. || (ArrayUtils.contains(wrapper.matches(), name) && !ArrayUtils.contains(wrapper.mismatches(), name))) {
  33. // 将当前 instance 作为参数传给 Wrapper 的构造方法,并通过反射创建 Wrapper 实例。
  34. // 然后向 Wrapper 实例中注入依赖,最后将 Wrapper 实例再次赋值给 instance 变量
  35. instance = injectExtension((T) wrapperClass.getConstructor(type).newInstance(instance));
  36. }
  37. }
  38. }
  39. }
  40. // 初始化
  41. initExtension(instance);
  42. return instance;
  43. } catch (Throwable t) {
  44. throw new IllegalStateException("Extension instance (name: " + name + ", class: " +
  45. type + ") couldn't be instantiated: " + t.getMessage(), t);
  46. }
  47. }

createExtension 方法的逻辑稍复杂一下,包含了如下的步骤:

  • 通过 getExtensionClasses 获取所有的拓展类
  • 通过反射创建拓展对象
  • 向拓展对象中注入依赖
  • 将拓展对象包裹在相应的 Wrapper 对象中
  • 初始化拓展对象

以上步骤中,第一个步骤是加载拓展类的关键,第三和第四个步骤是 Dubbo IOC 与 AOP 的具体实现。在接下来的章节中,将会重点分析 getExtensionClasses 方法的逻辑,以及简单介绍 Dubbo IOC 的具体实现。

2.1.1 获取所有的拓展类

在通过名称获取拓展类之前,首先需要根据配置文件解析出拓展项名称到拓展类的映射关系表(Map<名称, 拓展类>),之后再根据拓展项名称从映射关系表中取出相应的拓展类即可。相关过程的代码分析如下:

  1. private Map<String, Class<?>> getExtensionClasses() {
  2. // 从缓存中获取已加载的拓展类
  3. Map<String, Class<?>> classes = cachedClasses.get();
  4. // 双重检查
  5. if (classes == null) {
  6. synchronized (cachedClasses) {
  7. classes = cachedClasses.get();
  8. if (classes == null) {
  9. // 加载拓展类
  10. classes = loadExtensionClasses();
  11. cachedClasses.set(classes);
  12. }
  13. }
  14. }
  15. return classes;
  16. }

这里也是先检查缓存,若缓存未命中,则通过 synchronized 加锁。加锁后再次检查缓存,并判空。此时如果 classes 仍为 null,则通过 loadExtensionClasses 加载拓展类。下面分析 loadExtensionClasses 方法的逻辑。

  1. private Map<String, Class<?>> loadExtensionClasses() {
  2. // 缓存默认的 SPI 扩展名
  3. cacheDefaultExtensionName();
  4. Map<String, Class<?>> extensionClasses = new HashMap<>();
  5. // 基于策略来加载指定文件夹下的文件
  6. // 目前有四种策略,分别读取 META-INF/services/ META-INF/dubbo/ META-INF/dubbo/internal/ META-INF/dubbo/external/ 这四个目录下的配置文件
  7. for (LoadingStrategy strategy : strategies) {
  8. loadDirectory(extensionClasses, strategy.directory(), type.getName(), strategy.preferExtensionClassLoader(), strategy.overridden(), strategy.excludedPackages());
  9. loadDirectory(extensionClasses, strategy.directory(), type.getName().replace("org.apache", "com.alibaba"), strategy.preferExtensionClassLoader(), strategy.overridden(), strategy.excludedPackages());
  10. }
  11. return extensionClasses;
  12. }

loadExtensionClasses 方法总共做了两件事情,一是对 SPI 注解进行解析,二是调用 loadDirectory 方法加载指定文件夹配置文件。SPI 注解解析过程比较简单,无需多说。下面来看一下 loadDirectory 做了哪些事情。

  1. private void loadDirectory(Map<String, Class<?>> extensionClasses, String dir, String type,
  2. boolean extensionLoaderClassLoaderFirst, boolean overridden, String... excludedPackages) {
  3. // fileName = 文件夹路径 + type 全限定名
  4. String fileName = dir + type;
  5. try {
  6. Enumeration<java.net.URL> urls = null;
  7. ClassLoader classLoader = findClassLoader();
  8. // try to load from ExtensionLoader's ClassLoader first
  9. if (extensionLoaderClassLoaderFirst) {
  10. ClassLoader extensionLoaderClassLoader = ExtensionLoader.class.getClassLoader();
  11. if (ClassLoader.getSystemClassLoader() != extensionLoaderClassLoader) {
  12. urls = extensionLoaderClassLoader.getResources(fileName);
  13. }
  14. }
  15. // 根据文件名加载所有的同名文件
  16. if (urls == null || !urls.hasMoreElements()) {
  17. if (classLoader != null) {
  18. urls = classLoader.getResources(fileName);
  19. } else {
  20. urls = ClassLoader.getSystemResources(fileName);
  21. }
  22. }
  23. if (urls != null) {
  24. while (urls.hasMoreElements()) {
  25. java.net.URL resourceURL = urls.nextElement();
  26. // 加载资源
  27. loadResource(extensionClasses, classLoader, resourceURL, overridden, excludedPackages);
  28. }
  29. }
  30. } catch (Throwable t) {
  31. logger.error("Exception occurred when loading extension class (interface: " +
  32. type + ", description file: " + fileName + ").", t);
  33. }
  34. }

loadDirectory 方法先通过 classLoader 获取所有资源链接,然后再通过 loadResource 方法加载资源。继续跟下去,看一下 loadResource 方法的实现。

  1. private void loadResource(Map<String, Class<?>> extensionClasses, ClassLoader classLoader,
  2. java.net.URL resourceURL, boolean overridden, String... excludedPackages) {
  3. try {
  4. try (BufferedReader reader = new BufferedReader(new InputStreamReader(resourceURL.openStream(), StandardCharsets.UTF_8))) {
  5. String line;
  6. String clazz = null;
  7. // 按行读取配置内容
  8. while ((line = reader.readLine()) != null) {
  9. // 定位 # 字符
  10. final int ci = line.indexOf('#');
  11. if (ci >= 0) {
  12. // 截取 # 之前的字符串,# 之后的内容为注释,需要忽略
  13. line = line.substring(0, ci);
  14. }
  15. line = line.trim();
  16. if (line.length() > 0) {
  17. try {
  18. String name = null;
  19. // 以等于号 = 为界,截取键与值
  20. int i = line.indexOf('=');
  21. if (i > 0) {
  22. name = line.substring(0, i).trim();
  23. clazz = line.substring(i + 1).trim();
  24. } else {
  25. clazz = line;
  26. }
  27. // 加载类,并通过 loadClass 方法对类进行缓存
  28. if (StringUtils.isNotEmpty(clazz) && !isExcluded(clazz, excludedPackages)) {
  29. loadClass(extensionClasses, resourceURL, Class.forName(clazz, true, classLoader), name, overridden);
  30. }
  31. } catch (Throwable t) {
  32. IllegalStateException e = new IllegalStateException("Failed to load extension class (interface: " + type + ", class line: " + line + ") in " + resourceURL + ", cause: " + t.getMessage(), t);
  33. exceptions.put(line, e);
  34. }
  35. }
  36. }
  37. }
  38. } catch (Throwable t) {
  39. logger.error("Exception occurred when loading extension class (interface: " +
  40. type + ", class file: " + resourceURL + ") in " + resourceURL, t);
  41. }
  42. }

loadResource 方法用于读取和解析配置文件,并通过反射加载类,最后调用 loadClass 方法进行其他操作。loadClass 方法用于主要用于操作缓存,该方法的逻辑如下:

  1. private void loadClass(Map<String, Class<?>> extensionClasses, java.net.URL resourceURL, Class<?> clazz, String name,
  2. boolean overridden) throws NoSuchMethodException {
  3. if (!type.isAssignableFrom(clazz)) {
  4. throw new IllegalStateException("Error occurred when loading extension class (interface: " +
  5. type + ", class line: " + clazz.getName() + "), class "
  6. + clazz.getName() + " is not subtype of interface.");
  7. }
  8. // 检测目标类上是否有 Adaptive 注解
  9. if (clazz.isAnnotationPresent(Adaptive.class)) {
  10. cacheAdaptiveClass(clazz, overridden);
  11. } else if (isWrapperClass(clazz)) {
  12. // 缓存包装类
  13. cacheWrapperClass(clazz);
  14. } else {
  15. // 进入到这里,表明只是该类只是一个普通的拓展类
  16. // 检测 clazz 是否有默认的构造方法,如果没有,则抛出异常
  17. clazz.getConstructor();
  18. if (StringUtils.isEmpty(name)) {
  19. // 如果 name 为空,则尝试从 Extension 注解中获取 name,或使用小写的类名作为 name
  20. name = findAnnotationName(clazz);
  21. if (name.length() == 0) {
  22. throw new IllegalStateException("No such extension name for the class " + clazz.getName() + " in the config " + resourceURL);
  23. }
  24. }
  25. String[] names = NAME_SEPARATOR.split(name);
  26. if (ArrayUtils.isNotEmpty(names)) {
  27. // 如果类上有 Activate 注解,则使用 names 数组的第一个元素作为键,
  28. // 存储 name 到 Activate 注解对象的映射关系
  29. cacheActivateClass(clazz, names[0]);
  30. for (String n : names) {
  31. // 存储 Class 到名称的映射关系
  32. cacheName(clazz, n);
  33. // 存储 name 到 Class 的映射关系.
  34. // 如果存在同一个扩展名对应多个实现类,基于 override 参数是否允许覆盖,如果不允许,则抛出异常.
  35. saveInExtensionClass(extensionClasses, clazz, n, overridden);
  36. }
  37. }
  38. }
  39. }

如上,loadClass 方法操作了不同的缓存,比如 cachedAdaptiveClasscachedWrapperClassescachedNames 等等。除此之外,该方法没有其他什么逻辑了。
到此,关于缓存类加载的过程就分析完了。整个过程没什么特别复杂的地方,大家按部就班的分析即可,不懂的地方可以调试一下。接下来看看 Dubbo IOC 方面的内容。

2.1.2 Dubbo IOC

Dubbo IOC 是通过 setter 方法注入依赖。Dubbo 首先会通过反射获取到实例的所有方法,然后再遍历方法列表,检测方法名是否具有 setter 方法特征。若有,则通过 ObjectFactory 获取依赖对象,最后通过反射调用 setter 方法将依赖设置到目标对象中。整个过程对应的代码如下:

  1. private T injectExtension(T instance) {
  2. if (objectFactory == null) {
  3. return instance;
  4. }
  5. try {
  6. // 遍历目标类的所有方法
  7. for (Method method : instance.getClass().getMethods()) {
  8. // 检测方法是否以 set 开头,且方法仅有一个参数,且方法访问级别为 public
  9. if (!isSetter(method)) {
  10. continue;
  11. }
  12. /**
  13. * 检测是否有 DisableInject 注解修饰.
  14. */
  15. if (method.getAnnotation(DisableInject.class) != null) {
  16. continue;
  17. }
  18. // 基本类型不注入
  19. Class<?> pt = method.getParameterTypes()[0];
  20. if (ReflectUtils.isPrimitives(pt)) {
  21. continue;
  22. }
  23. try {
  24. // 获取属性名,比如 setName 方法对应属性名 name
  25. String property = getSetterProperty(method);
  26. // 从 ObjectFactory 中获取依赖对象
  27. Object object = objectFactory.getExtension(pt, property);
  28. if (object != null) {
  29. // 注入
  30. method.invoke(instance, object);
  31. }
  32. } catch (Exception e) {
  33. logger.error("Failed to inject via method " + method.getName()
  34. + " of interface " + type.getName() + ": " + e.getMessage(), e);
  35. }
  36. }
  37. } catch (Exception e) {
  38. logger.error(e.getMessage(), e);
  39. }
  40. return instance;
  41. }

在上面代码中,objectFactory 变量的类型为 AdaptiveExtensionFactoryAdaptiveExtensionFactory 内部维护了一个 ExtensionFactory 列表,用于存储其他类型的 ExtensionFactory。Dubbo 目前提供了两种 ExtensionFactory,分别是 SpiExtensionFactorySpringExtensionFactory。前者用于创建自适应的拓展,后者是用于从 Spring 的 IOC 容器中获取所需的拓展。这两个类的类的代码不是很复杂,这里就不一一分析了。
Dubbo IOC 目前仅支持 setter 方式注入,总的来说,逻辑比较简单易懂。

2.2 加载自适应扩展类

自适应扩展类的含义是说,基于参数,在运行时动态选择到具体的目标类,然后执行。在 Dubbo 中,很多拓展都是通过 SPI 机制进行加载的,比如 ProtocolClusterLoadBalance等。有时,有些拓展并不想在框架启动阶段被加载,而是希望在拓展方法被调用时,根据运行时参数进行加载。这听起来有些矛盾。拓展未被加载,那么拓展方法就无法被调用(静态方法除外)。拓展方法未被调用,拓展就无法被加载。对于这个矛盾的问题,Dubbo 通过自适应拓展机制很好的解决了。自适应拓展机制的实现逻辑比较复杂,首先 Dubbo 会为拓展接口生成具有代理功能的代码。然后通过 javassist 或 jdk 编译这段代码,得到 Class 类。最后再通过反射创建代理类,整个过程比较复杂。
加载自适应扩展类的入口是 ExtensionLoadergetAdaptiveExtension 方法。

  1. public T getAdaptiveExtension() {
  2. // 从缓存中获取自适应拓展
  3. Object instance = cachedAdaptiveInstance.get();
  4. if (instance == null) {
  5. // 如果存在异常,则直接抛出
  6. if (createAdaptiveInstanceError != null) {
  7. throw new IllegalStateException("Failed to create adaptive instance: " +
  8. createAdaptiveInstanceError.toString(),
  9. createAdaptiveInstanceError);
  10. }
  11. synchronized (cachedAdaptiveInstance) {
  12. instance = cachedAdaptiveInstance.get();
  13. // double check
  14. if (instance == null) {
  15. try {
  16. // 创建自适应拓展
  17. // 这里分为两种情况:一种是存在 Adaptive 类,另一个是需要生成 Adaptive 类
  18. instance = createAdaptiveExtension();
  19. cachedAdaptiveInstance.set(instance);
  20. } catch (Throwable t) {
  21. createAdaptiveInstanceError = t;
  22. throw new IllegalStateException("Failed to create adaptive instance: " + t.toString(), t);
  23. }
  24. }
  25. }
  26. }
  27. return (T) instance;
  28. }

getAdaptiveExtension 方法首先会检查缓存,缓存未命中,则调用 createAdaptiveExtension 方法创建自适应拓展。下面看一下 createAdaptiveExtension 方法的代码。

  1. private T createAdaptiveExtension() {
  2. try {
  3. // 获取自适应拓展类,并通过反射实例化
  4. return injectExtension((T) getAdaptiveExtensionClass().newInstance());
  5. } catch (Exception e) {
  6. throw new IllegalStateException("Can not create adaptive extension ...");
  7. }
  8. }

createAdaptiveExtension 方法的代码比较少,但却包含了三个逻辑,分别如下:

  • 调用 getAdaptiveExtensionClass 方法获取自适应拓展 Class 对象
  • 通过反射进行实例化
  • 调用 injectExtension 方法向拓展实例中注入依赖

前两个逻辑比较好理解,第三个逻辑用于向自适应拓展对象中注入依赖。这个逻辑看似多余,但有存在的必要,这里简单说明一下。前面说过,Dubbo 中有两种类型的自适应拓展,一种是手工编码的,一种是自动生成的。手工编码的自适应拓展中可能存在着一些依赖,而自动生成的 Adaptive 拓展则不会依赖其他类。这里调用 injectExtension 方法的目的是为手工编码的自适应拓展注入依赖,这一点需要大家注意一下。关于 injectExtension 方法,前文已经分析过了,这里不再赘述。接下来,分析 getAdaptiveExtensionClass 方法的逻辑。

  1. private Class<?> getAdaptiveExtensionClass() {
  2. // 通过 SPI 获取所有的拓展类
  3. getExtensionClasses();
  4. // 检查缓存,若缓存不为空,则直接返回缓存
  5. if (cachedAdaptiveClass != null) {
  6. return cachedAdaptiveClass;
  7. }
  8. // 创建自适应拓展类
  9. return cachedAdaptiveClass = createAdaptiveExtensionClass();
  10. }

getAdaptiveExtensionClass 方法同样包含了三个逻辑,如下:

  • 调用 getExtensionClasses 获取所有的拓展类
  • 检查缓存,若缓存不为空,则返回缓存
  • 若缓存为空,则调用 createAdaptiveExtensionClass 创建自适应拓展类

这三个逻辑看起来平淡无奇,似乎没有多讲的必要。但是这些平淡无奇的代码中隐藏了着一些细节,需要说明一下。首先从第一个逻辑说起,getExtensionClasses 这个方法用于获取某个接口的所有实现类。比如该方法可以获取 Protocol 接口的 DubboProtocolHttpProtocolInjvmProtocol 等实现类。在获取实现类的过程中,如果某个实现类被 Adaptive 注解修饰了,那么该类就会被赋值给 cachedAdaptiveClass 变量。此时,上面步骤中的第二步条件成立(缓存不为空),直接返回 cachedAdaptiveClass 即可。如果所有的实现类均未被 Adaptive 注解修饰,那么执行第三步逻辑,创建自适应拓展类。相关代码如下:

  1. private Class<?> createAdaptiveExtensionClass() {
  2. // 构建自适应拓展代码
  3. String code = new AdaptiveClassCodeGenerator(type, cachedDefaultName).generate();
  4. ClassLoader classLoader = findClassLoader();
  5. // 获取编译器实现类
  6. // 编译代码,生成 Class
  7. return compiler.compile(code, classLoader);
  8. }
  9. org.apache.dubbo.common.compiler.Compiler compiler = ExtensionLoader.getExtensionLoader(org.apache.dubbo.common.compiler.
  10. Compiler.class).getAdaptiveExtension();

createAdaptiveExtensionClass 方法用于生成自适应拓展类,该方法首先会生成自适应拓展类的源码,然后通过 Compiler 实例(Dubbo 默认使用 javassist 作为编译器)编译源码,得到代理类 Class 实例。接下来,把重点放在代理类代码生成的逻辑上,其他逻辑大家自行分析。

2.2.1 自适应拓展类代码生成

AdaptiveClassCodeGenerator#generate 方法生成扩展类代码

  1. public String generate() {
  2. // 如果该接口中没有方法被 @Adaptive 注解修饰,直接抛出异常
  3. if (!hasAdaptiveMethod()) {
  4. throw new IllegalStateException("No adaptive method exist on extension " + type.getName() + ", refuse to create the adaptive class!");
  5. }
  6. StringBuilder code = new StringBuilder();
  7. // 生成包名、import、方法等.
  8. code.append(generatePackageInfo());
  9. code.append(generateImports());
  10. code.append(generateClassDeclaration());
  11. Method[] methods = type.getMethods();
  12. for (Method method : methods) {
  13. code.append(generateMethod(method));
  14. }
  15. code.append("}");
  16. if (logger.isDebugEnabled()) {
  17. logger.debug(code.toString());
  18. }
  19. return code.toString();
  20. }

2.2.2 生成方法

上面代码中,生成方法的逻辑是最关键的,详细分析下。

  1. private String generateMethod(Method method) {
  2. String methodReturnType = method.getReturnType().getCanonicalName();
  3. String methodName = method.getName();
  4. // 生成方法内容
  5. String methodContent = generateMethodContent(method);
  6. String methodArgs = generateMethodArguments(method);
  7. String methodThrows = generateMethodThrows(method);
  8. return String.format(CODE_METHOD_DECLARATION, methodReturnType, methodName, methodArgs, methodThrows, methodContent);
  9. }

generateMethodContent 分析

  1. private String generateMethodContent(Method method) {
  2. // 该方法上必须有 @Adaptive 注解修饰
  3. Adaptive adaptiveAnnotation = method.getAnnotation(Adaptive.class);
  4. StringBuilder code = new StringBuilder(512);
  5. if (adaptiveAnnotation == null) {
  6. // 没有 @Adaptive 注解修饰,生成异常信息
  7. return generateUnsupported(method);
  8. } else {
  9. // 获取 URL 在参数列表上的索引
  10. int urlTypeIndex = getUrlTypeIndex(method);
  11. if (urlTypeIndex != -1) {
  12. // 如果参数列表上存在 URL,生成对 URL 进行空检查
  13. code.append(generateUrlNullCheck(urlTypeIndex));
  14. } else {
  15. // 如果参数列表不存在 URL 类型的参数,那么就看参数列表上参数对象中是否包含 getUrl 方法
  16. // 有的话,生成 URL 空检查
  17. code.append(generateUrlAssignmentIndirectly(method));
  18. }
  19. // 解析 Adaptive 注解上的 value 属性
  20. String[] value = getMethodAdaptiveValue(adaptiveAnnotation);
  21. // 如果参数列表上有 Invocation 类型的参数,生成空检查并获取 methodName.
  22. boolean hasInvocation = hasInvocationArgument(method);
  23. code.append(generateInvocationArgumentNullCheck(method));
  24. // 这段逻辑主要就是为了生成 extName(也就是扩展名)
  25. // 分为多种情况:
  26. // 1.defaultExtName 是否存在
  27. // 2.参数中是否存在 invocation 类型参数
  28. // 3.是否是为 protocol 生成代理
  29. // 为什么要对 protocol 单独考虑了?因为 URL 中有获取 protocol 值的方法
  30. code.append(generateExtNameAssignment(value, hasInvocation));
  31. // check extName == null?
  32. code.append(generateExtNameNullCheck(value));
  33. // 生成获取扩展(使用 ExtensionLoader.getExtension 方法)
  34. code.append(generateExtensionAssignment());
  35. // 生成返回语句
  36. code.append(generateReturnAndInvocation(method));
  37. }
  38. return code.toString();
  39. }

上面那段逻辑主要做了如下几件事:

  1. 检查方法上是否 Adaptive 注解修饰
  2. 为方法生成代码的时候,参数列表上要有 URL(或参数对象中有 URL)
  3. 使用ExtensionLoader.getExtension 获取扩展
  4. 执行对应的方法

    2.2.3 附一个动态生成代码后的例子

    ```java package org.apache.dubbo.common.extension.adaptive;

import org.apache.dubbo.common.extension.ExtensionLoader;

public class HasAdaptiveExt$Adaptive implements org.apache.dubbo.common.extension.adaptive.HasAdaptiveExt { public java.lang.String echo(org.apache.dubbo.common.URL arg0, java.lang.String arg1) { // URL 空校验 if (arg0 == null) { throw new IllegalArgumentException(“url == null”); }

  1. org.apache.dubbo.common.URL url = arg0;
  2. // 获取扩展名
  3. String extName = url.getParameter("has.adaptive.ext", "adaptive");
  4. // 扩展名空校验
  5. if (extName == null) {
  6. throw new IllegalStateException(
  7. url.toString() + ") use keys([has.adaptive.ext])");
  8. }
  9. // 获取扩展
  10. .getExtension(extName);
  11. // 执行对应的方法
  12. return extension.echo(arg0, arg1);
  13. }

} “Failed to get extension (org.apache.dubbo.common.extension.adaptive.HasAdaptiveExt) name from url (“ + org.apache.dubbo.common.extension.adaptive.HasAdaptiveExt extension = (org.apache.dubbo.common.extension.adaptive.HasAdaptiveExt) ExtensionLoader.getExtensionLoader(org.apache.dubbo.common.extension .adaptive.HasAdaptiveExt.class) .getExtension(extName)

  1. <a name="ENHSV"></a>
  2. ## 3、SPI 扩展示例
  3. <a name="rJVSz"></a>
  4. ### 3.1 加载固定扩展类
  5. <a name="iFqu1"></a>
  6. #### 3.1.1 编写 SPI 接口及实现类
  7. 不管是 Java SPI,还是 Dubbo 中实现的 SPI,都需要编写接口。不过 Dubbo 中的接口需要被 `@SPI` 注解修饰。
  8. ```java
  9. @SPI
  10. public interface DemoSpi {
  11. void say();
  12. }
  13. public class DemoSpiImpl implements DemoSpi {
  14. public void say() {
  15. }
  16. }

3.1.2 将实现类放在特定目录下

从上面的代码可知,dubbo 在加载扩展类的时候,会从四个目录中读取。在 META-INF/dubbo 目录下新建一个以 DemoSpi 接口名为文件名的文件,内容如下:
demoSpiImpl = com.xxx.xxx.DemoSpiImpl(为 DemoSpi 接口实现类的全类名)

3.1.3 使用

  1. public class DubboSPITest {
  2. @Test
  3. public void sayHello() throws Exception {
  4. ExtensionLoader<DemoSpi> extensionLoader =
  5. ExtensionLoader.getExtensionLoader(DemoSpi.class);
  6. DemoSpi dmeoSpi = extensionLoader.getExtension("demoSpiImpl");
  7. optimusPrime.sayHello();
  8. }
  9. }

3.2 加载自适应扩展类

这个以 Protocol 为例进行说明

3.2.1 Protocol 接口(抽取部分核心方法)

  1. @SPI("dubbo")
  2. public interface Protocol {
  3. @Adaptive
  4. <T> Exporter<T> export(Invoker<T> invoker) throws RpcException;
  5. @Adaptive
  6. <T> Invoker<T> refer(Class<T> type, URL url) throws RpcException;
  7. }
  8. public class DubboProtocol extends AbstractProtocol {
  9. ......
  10. @Override
  11. public <T> Invoker<T> refer(Class<T> type, URL url) throws RpcException {
  12. return protocolBindingRefer(type, url);
  13. }
  14. @Override
  15. public <T> Exporter<T> export(Invoker<T> invoker) throws RpcException {
  16. ......
  17. return exporter;
  18. }
  19. }

3.2.2 将实现类放在特定目录下

在 dubbo 中,该配置路径META-INF/dubbo/internal/org.apache.dubbo.rpc.Protocol
dubbo=org.apache.dubbo.rpc.protocol.dubbo.DubboProtocol
需要说明一点的是,在 dubbo 中,并不是直接使用 DubboProtocol 的,而是使用的是其包装类。

3.2.3 使用

  1. public class DubboAdaptiveTest {
  2. @Test
  3. public void sayHello() throws Exception {
  4. URL url = URL.valueOf("dubbo://localhost/test");
  5. Protocol adaptiveProtocol = ExtensionLoader.getExtensionLoader(Protocol.class).getAdaptiveExtension();
  6. adaptiveProtocol.refer(type, url);
  7. }
  8. }