java开发Dubbo注解Adaptive实现原理

目录
  • 前言
    • 什么是@Adaptive
  • 实现原理
    • getAdaptiveExtension
    • getAdaptiveExtensionClass
    • generate

前言

前面我们已经分析Dubbo SPI相关的源码,看过的小伙伴相信已经知晓整个加载过程,我们也留下两个问题,今天我们先来处理下其中关于注解Adaptive的原理。

什么是@Adaptive

对应于Adaptive机制,Dubbo提供了一个注解@Adaptive,该注解可以用于接口的某个子类上,也可以用于接口方法上。

如果用在接口的子类上,则表示Adaptive机制的实现会按照该子类的方式进行自定义实现;如果用在方法上,则表示Dubbo会为该接口自动生成一个子类,并且重写该方法,没有标注@Adaptive注解的方法将会默认抛出异常。对于第一种Adaptive的使用方式,Dubbo里只有ExtensionFactory接口使用,AdaptiveExte

nsionFactory的实现就使用了@Adaptive注解进行了标注,主要作用就是在获取目标对象时,分别通过ExtensionLoader和Spring容器两种方式获取,该类的实现已经在Dubbo SPI机制分析过,此篇文章关注的重点是关于@Adaptive注解修饰在接口方法的实现原理,也就是关于Dubbo SPI动态的加载扩展类能力如何实现,搞清楚Dubbo是如何在运行时动态的选择对应的扩展类来提供服务。

简单一点说就是一个代理层,通过对应的参数返回对应的类的实现,运行时编译。为了更好的理解我们来写个案例:

@SPI("china")
public interface PersonService {
    @Adaptive
    String queryCountry(URL url);
}
public class ChinaPersonServiceImpl implements PersonService {
    @Override
    public String queryCountry(URL url) {
        System.out.println("中国人");
        return "中国人";
    }
}
public class EnglandPersonServiceImpl implements PersonService{
    @Override
    public String queryCountry(URL url) {
        System.out.println("英国人");
        return "英国人";
    }
}
public class Test {
    public static void main(String[] args) {
        URL url = URL.valueOf("dubbo://192.168.0.101:20880?person.service=china");
        PersonService service = ExtensionLoader.getExtensionLoader(PersonService.class)
                .getAdaptiveExtension();
        service.queryCountry(url);
    }
}
china=org.dubbo.spi.example.ChinaPersonServiceImpl
england=org.dubbo.spi.example.EnglandPersonServiceImpl

该案例中首先构造了一个URL对象,这个URL对象是Dubbo中进行参数传递所使用的一个基础类,在配置文件中配置的属性都会被封装到该对象中。

这里我们需要注意的是我们的对象是通过一个url构造的,并且在url的最后有一个参数person.service=china,这里也就是我们所指定的使用哪种基础服务类的参数,通过指向不同的对象就可以生成对应不同的实现。关于URL部分的介绍我们在下一篇文章介绍,聊聊Dubbo中URL的使用场景有哪些。

在构造一个URL对象之后,通过getExtensionLoader(PersonService.class)方法获取了一个PersonService对应的ExtensionLoader对象,然后调用其getAdaptiveExtension()方法获取PersonService接口构造的子类实例,这里的子类实际上就是ExtensionLoader通过一定的规则为PersonService接口编写的子类代码,然后通过javassist或jdk编译加载这段代码,加载完成之后通过反射构造其实例,最后将其实例返回。

当发生调用的时候,方法内部就会通过url对象指定的参数来选择具体的实例,从而将真正的工作交给该实例进行。通过这种方式,Dubbo SPI就实现了根据传入参数动态的选用具体的实例来提供服务的功能。以下代码就是动态生成以后的代码:

public class PersonService$Adaptive implements org.dubbo.spi.example.PersonService {
    public java.lang.String queryCountry(org.apache.dubbo.common.URL arg0) {
        if (arg0 == null) throw new IllegalArgumentException("url == null");
        org.apache.dubbo.common.URL url = arg0;
        String extName = url.getParameter("person.service", "china");
        if (extName == null)
            throw new IllegalStateException("Failed to get extension (org.dubbo.spi.example.PersonService) name from url (" + url.toString() + ") use keys([person.service])");
        org.dubbo.spi.example.PersonService extension = (org.dubbo.spi.example.PersonService) ExtensionLoader.getExtensionLoader(org.dubbo.spi.example.PersonService.class).getExtension(extName);
        return extension.queryCountry(arg0);
    }
}

关于使用我们需要注意以下两个问题:

  • 要使用Dubbo的SPI的支持,必须在目标接口上使用@SPI注解进行标注,后面的值提供了一个默认值,此处可以理解为这是一种规范,如果在接口的@SPI注解中指定了默认值,那么在使用URL对象获取参数值时,如果没有取到,就会使用该默认值;
  • @Adaptive注解标注的方法中,其参数中必须有一个参数类型为URL,或者其某个参数提供了某个方法,该方法可以返回一个URL对象,此处我们可以再看源码的时候给大家标注一下,面试的时候防止大佬问:是不是一定要 @Adaptive 实现的方法的中必须有URL对象;

实现原理

getAdaptiveExtension

关于getAdaptiveExtension方法我们在上篇文章已经讲过,此方法就是通过双检查法来从缓存中获取Adaptive实例,如果没获取到,则创建一个。

    public T getAdaptiveExtension() {
        //从装载适配器实例缓存里面找
        Object instance = cachedAdaptiveInstance.get();
        if (instance == null) {
            //创建cachedAdaptiveInstance异常
            if (createAdaptiveInstanceError != null) {
                throw new IllegalStateException("Failed to create adaptive instance: " +
                        createAdaptiveInstanceError.toString(),
                        createAdaptiveInstanceError);
            }
            synchronized (cachedAdaptiveInstance) {
                instance = cachedAdaptiveInstance.get();
                if (instance == null) {
                    try {
                        //创建对应的适配器类
                        instance = createAdaptiveExtension();
                        //缓存
                        cachedAdaptiveInstance.set(instance);
                    } catch (Throwable t) {
                        createAdaptiveInstanceError = t;
                        throw new IllegalStateException("Failed to create adaptive instance: " + t.toString(), t);
                    }
                }
            }
        }
        return (T) instance;
    }
    private T createAdaptiveExtension() {
        try {
            return injectExtension((T) getAdaptiveExtensionClass().newInstance());
        } catch (Exception e) {
            throw new IllegalStateException("Can't create adaptive extension " + type + ", cause: " + e.getMessage(), e);
        }
    }

getAdaptiveExtensionClass

在getAdaptiveExtensionClass方法中有两个分支,如果某个子类标注了@Adaptive注解,那么就会使用该子类所自定义的Adaptive机制,如果没有子类标注该注解,那么就会使用下面的createAdaptiveExtensionClass()方式来创建一个目标类class对象。

整个过程通过AdaptiveClassCodeGenerator来为目标类生成子类代码,并以字符串的形式返回,最后通过javassist或jdk的方式进行编译然后返回class对象。

    private Class<?> getAdaptiveExtensionClass() {
        //获取所有的扩展类
        getExtensionClasses();
        //如果可以适配
        if (cachedAdaptiveClass != null) {
            return cachedAdaptiveClass;
        }
        //如果没有适配扩展类就创建
        return cachedAdaptiveClass = createAdaptiveExtensionClass();
    }
    private Class<?> createAdaptiveExtensionClass() {
        //生成代码片段
        String code = new AdaptiveClassCodeGenerator(type, cachedDefaultName).generate();
        //获取ClassLoader
        ClassLoader classLoader = findClassLoader();
        //通过jdk或者javassist的方式编译生成的子类字符串,从而得到一个class对象
        org.apache.dubbo.common.compiler.Compiler compiler =
                ExtensionLoader.getExtensionLoader(org.apache.dubbo.common.compiler.Compiler.class).getAdaptiveExtension();
        //编译
        return compiler.compile(code, classLoader);
    }

generate

generate方法是生成目标类的方法,其实和创建一个类一样,其主要四个步骤:

  • 生成package信息;
  • 生成import信息;
  • 生成类声明信息;
  • 生成各个方法的实现;
    public String generate() {
        // 判断目标接口是否有方法标注了@Adaptive注解,如果没有则抛出异常
        if (!hasAdaptiveMethod()) {
            throw new IllegalStateException("No adaptive method exist on extension " + type.getName() + ", refuse to create the adaptive class!");
        }
        StringBuilder code = new StringBuilder();
        //生成package
        code.append(generatePackageInfo());
        //生成import信息 只导入了ExtensionLoader类,其余的类都通过全限定名的方式来使用
        code.append(generateImports());
        //生成类声明信息
        code.append(generateClassDeclaration());
        Method[] methods = type.getMethods();
        //为各个方法生成实现方法信息
        for (Method method : methods) {
            code.append(generateMethod(method));
        }
        code.append("}");
        if (logger.isDebugEnabled()) {
            logger.debug(code.toString());
        }
        //返回class代码
        return code.toString();
    }

接下来主要看方法实现的生成,对于包路径、类的生成的代码相对比较简单,这里进行忽略,对于方法生成主要包含以下几个步骤:

  • 获取返回值信息;
  • 获取方法名信息;
  • 获取方法体内容;
  • 获取方法参数;
  • 获取异常信息;
  • 格式化
    private String generateMethod(Method method) {
        //获取方法返回值
        String methodReturnType = method.getReturnType().getCanonicalName();
        //获取方法名称
        String methodName = method.getName();
        //获取方法体内容
        String methodContent = generateMethodContent(method);
        //获取方法参数
        String methodArgs = generateMethodArguments(method);
        //生成异常信息
        String methodThrows = generateMethodThrows(method);
        //格式化
        return String.format(CODE_METHOD_DECLARATION, methodReturnType, methodName, methodArgs, methodThrows, methodContent);
    }

需要注意的是,这里所使用的所有类都是使用的其全限定类名,在上面生成的代码中也可以看到,在方法生成的整个过程中,方法的返回值,方法名,方法参数以及异常信息都可以通过反射的信息获取到,而方法体则需要根据一定规则来生成,这里我们要看一下方法体是如何生成的;

    private String generateMethodContent(Method method) {
        //获取Adaptive的注解信息
        Adaptive adaptiveAnnotation = method.getAnnotation(Adaptive.class);
        StringBuilder code = new StringBuilder(512);
        if (adaptiveAnnotation == null) {
            //如果当前方法没有被Adaptive修饰则需要抛出异常
            return generateUnsupported(method);
        } else {
            //获取参数中类型为URL的参数所在的参数索引位 通过下标获取对应的参数值信息
            int urlTypeIndex = getUrlTypeIndex(method);
            if (urlTypeIndex != -1) {
                //如果参数中存在URL类型的参数,那么就为该参数进行空值检查,如果为空,则抛出异常
                code.append(generateUrlNullCheck(urlTypeIndex));
            } else {
                //如果参数中不存在URL类型的参数,则会检查每个参数,判断是否有某个方法的返回类型是URL类型,
                //如果存在该方法,首先对该参数进行空指针检查,如果为空则抛出异常。如果不为空则调用该对象的目标方法,
                //获取URL对象,然后对获取到的URL对象进行空值检查,为空抛出异常。
                code.append(generateUrlAssignmentIndirectly(method));
            }
            //获取@Adaptive注解的参数,如果没有配置,就会使用目标接口的类型由驼峰形式转换为点分形式
            //的名称作为将要获取的参数值的key名称
            String[] value = getMethodAdaptiveValue(adaptiveAnnotation);
            //判断是否存在Invocation类型的参数 关于这个对象我们在后续章节在进行讲解
            boolean hasInvocation = hasInvocationArgument(method);
            //为Invocation类型的参数添加空值检查的逻辑
            code.append(generateInvocationArgumentNullCheck(method));
            //生成获取extName的逻辑,获取用户配置的扩展的名称
            code.append(generateExtNameAssignment(value, hasInvocation));
            //extName空值检查代码
            code.append(generateExtNameNullCheck(value));
            //通过extName在ExtensionLoader中获取其对应的基础服务类
            code.append(generateExtensionAssignment());
            //生成实例的当前方法的调用逻辑,然后将结果返回
            code.append(generateReturnAndInvocation(method));
        }
        return code.toString();
    }

上面整体的逻辑还是比较清楚的,通过对比PersonService$Adaptive生成我们可以更容易理解改代码生成的过程,整体的逻辑可以分为四步:

  • 判断当前方法是否标注了@Adaptive注解,如果没有标注,则为其生成默认抛出异常的方法,只有使用@Adaptive注解标注的方法才是作为自适应机制的方法;
  • 获取方法参数中类型为URL的参数,如果不存在,则获取参数中存在URL类型的参数,如果不存在抛出异常,如果存在获取URL参数类型;
  • 通过@Adaptive注解的配置获取目标参数的key值,然后通过URL参数获取该key对应的参数值,得到了基础服务类对应的名称;
  • 通过ExtensionLoader获取该名称对应的基础服务类实例,最终调用该服务的方法来进行实现;

以上就是java开发Dubbo注解Adaptive实现原理的详细内容,更多关于java Dubbo注解Adaptive的资料请关注我们其它相关文章!

(0)

相关推荐

  • 解决Lombok注解不起作用的问题

    Lombok注解不起作用 场景: 减少实体类中如Getter,Setter方法的书写 原因: lombok是一个第三方插件,我们使用时需要进行两个步骤(两个步骤缺一不可): 1:引入lombok依赖 2: 安装lombok插件 作用: Lombok是一个第三方插件,通过它我们可以直接书写注解来代替原来的getter,setter,toString等方法. 深入理解Lombok 说道Lombok,可能会鲜为人知.但是在实际的开发中,它起到了很大的作用,话不多说,直入正题: 一.Lombok是什么

  • 一次由Lombok的@AllArgsConstructor注解引发的错误及解决

    目录 由Lombok的@AllArgsConstructor注解引发的错误 查了资料这里简单解释一下 按照上面注解的解释 @AllArgsConstructor lombok注解踩坑记录 这里记录一下使用注意点 由Lombok的@AllArgsConstructor注解引发的错误 需求:在Service实现中写了一个方法调用第三方接口同步数据. 功能代码不做展示,比较普通的调用接口返回JSON数据. 直接看SpringBoot启动的报错信息: Parameter 3 of constructor

  • 使用Lombok @Builder注解导致默认值无效的问题

    目录 @Builder注解导致默认值无效 原因分析 lombok@Builder忽略属性默认值的坑点 1. 简单使用 2. 默认值问题 3. 修改属性值 @Builder注解导致默认值无效 使用Lombok注解可以极高的简化代码量,比较好用的注解除了@Data之外,还有@Builder这个注解,它可以让你很方便的使用builder模式构建对象,但是今天发现@Builder注解会把对象的默认值清掉. 像下面这段代码,会导致对象的name属性变为null: public class BuilderT

  • Lombok基本注解之@SneakyThrows的作用

    使用范围: 只能作用在方法和构造函数之上 @SneakyThrows注解的作用得从java的异常设计体系说起. java中常见的异常有两种: Exception即非运行时异常(编译异常). RuntimeException即运行时异常. 第一种会强制要求抛出它的方法声明throws,从程序语法角度讲是必须进行处理的异常,如果不处理,程序就不能编译通过.设计的目的是为了提醒开发者处理一些场景中必然可能存在的异常情况.比如网络异常造成IOException. 但是现实,往往事与愿违.大部分情况下的异

  • java开发Dubbo注解Adaptive实现原理

    目录 前言 什么是@Adaptive 实现原理 getAdaptiveExtension getAdaptiveExtensionClass generate 前言 前面我们已经分析Dubbo SPI相关的源码,看过的小伙伴相信已经知晓整个加载过程,我们也留下两个问题,今天我们先来处理下其中关于注解Adaptive的原理. 什么是@Adaptive 对应于Adaptive机制,Dubbo提供了一个注解@Adaptive,该注解可以用于接口的某个子类上,也可以用于接口方法上. 如果用在接口的子类上

  • Java和Dubbo的SPI机制原理解析

    SPI: 简单理解就是,你一个接口有多种实现,然后在代码运行时候,具体选用那个实现,这时候我们就可以通过一些特定的方式来告诉程序寻用那个实现类,这就是SPI. JAVA的SPI 全称为 Service Provider Interface,是一种服务发现机制.它是约定在 Classpath 下的 META-INF/services/ 目录里创建一个以服务接口命名的文件,然后文件里面记录的是此 jar 包提供的具体实现类的全限定名. 这样当我们引用了某个 jar 包的时候就可以去找这个 jar 包

  • java开发Dubbo负载均衡与集群容错示例详解

    目录 负载均衡与集群容错 Invoker 服务目录 RegistryDirectory 获取Invoker列表 监听注册中心 刷新Invoker列表 StaticDirectory 服务路由 Cluster FailoverClusterInvoker FailfastClusterInvoker FailsafeClusterInvoker FailbackClusterInvoker ForkingClusterInvoker BroadcastClusterInvoker Abstract

  • java开发分布式服务框架Dubbo原理机制详解

    目录 前言 Dubbo框架有以下部件 Consumer Provider Registry Monitor Container 架构 高可用性 框架设计 服务暴露过程 服务消费过程 前言 在介绍Dubbo之前先了解一下基本概念: Dubbo是一个RPC框架,RPC,即Remote Procedure Call(远程过程调用),相对的就是本地过程调用,在分布式架构之前的单体应用架构和垂直应用架构运用的都是本地过程调用.它允许程序调用另外一个地址空间(通常是网络共享的另外一台机器)的过程或函数,并且

  • java开发分布式服务框架Dubbo暴露服务过程详解

    目录 Dubbo服务暴露机制 前言 服务暴露流程 源码解析 本地暴露 远程暴露 Dubbo服务暴露机制 前言 在进行服务暴露机制的分析之前,必须谈谈什么是URL,在Dubbo服务暴露过程中URL是无处不在的,贯穿了整个过程. 一般情况下,URL指的是统一资源定位符,标准格式如下: protocol://host:port/path?key1=value1&key2=value2 Dubbo就是用这种URL的方式来作为约定的参数类型,服务之间也是用URL来进行交互. Dubbo用URL作为配置总线

  • java开发MVC三层架构上再加一层Manager层原理详解

    目录 MVC三层架构 MVC架构弊端 Manager层的特征 Manager层使用案例 MVC三层架构 我们在刚刚成为程序员的时候,就会被前辈们 "教育" 说系统的设计要遵循 MVC(Model-View-Controller)架构.它将整体的系统分成了 Model(模型),View(视图)和 Controller(控制器)三个层次,也就是将用户视图和业务处理隔离开,并且通过控制器连接起来,很好地实现了表现和逻辑的解耦,是一种标准的软件分层架构. MVC分层架构是架构上最简单的一种分层

  • java开发分布式服务框架Dubbo服务引用过程详解

    目录 大致流程 服务引用策略 服务引用的三种方式 服务引入流程解析 总结 大致流程 Provider将服务暴露出来并且注册到注册中心,而Consumer通过注册中心获取Provider的信息,之后将自己封装成一个调用类去与Provider进行交互. 首先需要将所有调用转化为Dubbo中我们熟悉的Invoker,再通过代理类去远程获取服务. 大致流程如下: 服务引用策略 服务的引用和服务的暴露原理相似,都是Spring自定义标签机制解析生成对应的Bean,在之前服务暴露使用到的Provider S

  • java中注解机制及其原理的详解

    java中注解机制及其原理的详解 什么是注解 注解也叫元数据,例如我们常见的@Override和@Deprecated,注解是JDK1.5版本开始引入的一个特性,用于对代码进行说明,可以对包.类.接口.字段.方法参数.局部变量等进行注解.它主要的作用有以下四方面: 生成文档,通过代码里标识的元数据生成javadoc文档. 编译检查,通过代码里标识的元数据让编译器在编译期间进行检查验证. 编译时动态处理,编译时通过代码里标识的元数据动态处理,例如动态生成代码. 运行时动态处理,运行时通过代码里标识

  • Java之Spring注解开发案例详解

    在Spring4之后,要使用注解开发,必须要保证aop的包导入了 使用注解需要导入context约束,增加注解的支持! <?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance&

  • java开发MyBatis中常用plus实体类注解符详解

    目录 mybatis-plus常用注解符 1. 表名注解(@TableName) 2. 主键注解(@TableId) 3. 属性注解(@TableField) mybatis-plus常用注解符 1. 表名注解(@TableName) 作用:实体类和数据库中表建立对应关系:如 @TableName("thotset") public class HotsetEntity implements Serializable { private static final long serial

随机推荐