Dubbo扩展点SPI实践示例解析

目录
  • 正文
  • 扩展点配置:
  • 扩展实现类:
  • 拦截配置文件:
  • 调用拦截扩展:
  • 拦截扩展说明:
    • 常用约定:
    • 实现细节:
  • 扩展点的几个特点:
    • 扩展点自动包装
    • 扩展点自动装配
    • 扩展点自适应
    • 扩展点自动激活

正文

Dubbo的扩展点加载从JDK标准的SPI(Service Provider Interface)扩展点发现机制加强而来。Dubbo改进了JDK标准的SPI的以下问题:

  • JDK标准的SPI会一次性实例化扩展点所有实现,如果有扩展实现初始化很耗时,但如果没用上也加载,会很浪费资源。如果扩展点加载失败,连扩展点的名称都拿不到了。
  • Dubbo增加了对扩展点IoC和AOP的支持,一个扩展点可以直接setter注入其它扩展点。 比如:Filter是Dubbo的集合类扩展点的一种,还有其他如InvokerListener, ExportListener, TelnetHandler, StatusChecker等扩展,这个有时间可以都看看(搜索Dubbo开发者指南:SPI参考手册)

扩展点配置:

src\
 |-main\
    |-java\
        |-com\
            |-xxx\
                |-XxxFilter.java (实现Filter接口)\
    |-resources\
        |-META-INF\
            |-dubbo\
                |-com.alibaba.dubbo.rpc.Filter (纯文本文件,内容为:xxx=com.xxx.XxxFilter)

扩展实现类:

@Activate
public class AuthorityFilter implements Filter {
    private static Logger logger = LoggerFactory.getLogger(AuthorityFilter.class);
    List<String> ipWhiteList = AuthorityUtils.getAccessListByKey("1");
    @Override
    public Result invoke(Invoker<?> invoker, Invocation invocation) throws RpcException {
        [logger.info](http://logger.info/)("########go into filtersuccess !!########");
        String clientIp = RpcContext.getContext().getRemoteHost();
        String host = IpParseUtils.getHostByIp(clientIp);
        if (ipWhiteList.contains(host))
Unknown macro: {            [logger.info](http://logger.info/)("########白名单校验通过!########");            return invoker.invoke(invocation);        }
else
Unknown macro: {            [logger.info](http://logger.info/)("########白名单校验未通过!########");            return new RpcResult();        }
    }
}

拦截配置文件:

在扩展类的jar包内,放置扩展点配置文件:META-INF/dubbo/接口全限定名,内容为:配置名=扩展实现类全限定名,多个实现类用换行符分隔。(注意:这里的配置文件是放在你自己的jar包内,不是dubbo本身的jar包内,Dubbo会全ClassPath扫描所有jar包内同名的这个文件,然后进行合并)

注意这个xxx=左侧的名字跟你扩展类同名哦(这是个坑儿,别问我怎么知道的)!

AuthorityFilter=your.extend.dubbo.async.provider.AuthorityFilter

调用拦截扩展:

<dubbo:provider filter="AuthorityFilter"></dubbo:provider>

拦截扩展说明:

服务提供方和服务消费方调用过程拦截,Dubbo本身的大多功能均基于此扩展点实现,每次远程方法执行,该拦截都会被执行,请注意对性能的影响。\

常用约定:

  • 用户自定义filter默认在内置filter之后。
  • 特殊值default,表示缺省扩展点插入的位置。 比如:filter="xxx,default,yyy",表示xxx在缺省filter之前,yyy在缺省filter之后。\
  • 特殊符号-,表示剔除。
    比如:filter="-foo1",剔除添加缺省扩展点foo1。
    比如:filter="-default",剔除添加所有缺省扩展点。\
  • provider和service同时配置的filter时,累加所有filter,而不是覆盖。
    比如:<dubbo:provider filter="xxx,yyy"/>和<dubbo:service filter="aaa,bbb" />,则xxx,yyy,aaa,bbb均会生效。
    如果要覆盖,需配置:<dubbo:service filter="-xxx,-yyy,aaa,bbb" />\

实现细节:

  • 解析服务

基于dubbo.jar内的META-INF/spring.handlers配置,Spring在遇到dubbo名称空间时,会回调DubboNamespaceHandler。

所有dubbo的标签,都统一用DubboBeanDefinitionParser进行解析,基于一对一属性映射,将XML标签解析为Bean对象。

在ServiceConfig.export()或ReferenceConfig.get()初始化时,将Bean对象转换URL格式,所有Bean属性转成URL的参数。

然后将URL传给Protocol扩展点,基于扩展点的Adaptive机制,根据URL的协议头,进行不同协议的服务暴露或引用。

  • 拦截服务

基于扩展点的Wrapper机制,所有的Protocol扩展点都会自动套上Wrapper类。

基于ProtocolFilterWrapper类,将所有Filter组装成链,在链的最后一节调用真实的引用。

基于ProtocolListenerWrapper类,将所有InvokerListener和ExporterListener组装集合,在暴露和引用前后,进行回调。

包括监控在内,所有附加功能,全部通过Filter拦截实现。

还有暴露服务和引用服务,个人觉得看这上面这两个对写程序相对更有用些!

扩展点的几个特点:

扩展点自动包装

自动Wrap扩展点的Wrapper类

ExtensionLoader会把加载扩展点时(通过扩展点配置文件中内容),如果该实现有拷贝构造函数,则判定为扩展点Wrapper类。Wrapper类同样实现了扩展点接口。

扩展点自动装配

加载扩展点时,自动注入依赖的扩展点

加载扩展点时,扩展点实现类的成员如果为其它扩展点类型,ExtensionLoader在会自动注入依赖的扩展点。

ExtensionLoader通过扫描扩展点实现类的所有set方法来判定其成员。即ExtensionLoader会执行扩展点的拼装操作。

ExtensionLoader加载CarMaker的扩展点实现RaceCar时,setWheelMaker方法的WheelMaker也是扩展点则会注入WheelMaker的实现。

扩展点自适应

扩展点的Adaptive实例
ExtensionLoader注入的依赖扩展点是一个Adaptive实例,直到扩展点方法执行时才决定调用是一个扩展点实现。

  • Dubbo使用URL对象(包含了Key-Value)传递配置信息

扩展点方法调用会有URL参数(或是参数有URL成员)

这样依赖的扩展点也可以从URL拿到配置信息,所有的扩展点自己定好配置的Key后,配置信息从URL上从最外层传入。URL在配置传递上即是一条总线。

示例:有两个为扩展点CarMaker(造车者)、wheelMaker(造轮者)

扩展点自动激活

对于集合类扩展点,比如:Filter, InvokerListener, ExportListener, TelnetHandler, StatusChecker等,可以同时加载多个实现,此时,可以用自动激活来简化配置,如:

import com.alibaba.dubbo.common.extension.Activate;
import com.alibaba.dubbo.rpc.Filter;
@Activate // 无条件自动激活
public class XxxFilter implements Filter {
    // ...
}

以上就是Dubbo扩展点SPI实践示例解析的详细内容,更多关于Dubbo扩展点SPI实践的资料请关注我们其它相关文章!

(0)

相关推荐

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

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

  • 解析Apache Dubbo的SPI实现机制

    一.SPI 在Java中,SPI体现了面向接口编程的思想,满足开闭设计原则. 1.1.JDK自带SPI实现 从JDK1.6开始引入SPI机制后,可以看到很多使用SPI的案例,比如最常见的数据库驱动实现,在JDK中只定义了java.sql.Driver的接口,具体实现由各数据库厂商来提供.下面一个简单的例子来快速了解下Java SPI的使用方式: 1)定义一个接口 package com.vivo.study public interface Car { void getPrice(); } 2)

  • 详解SPI在Dubbo中的应用

    目录 一.概述 二.JDK自带SPI 2.1.代码示例 2.2.简单分析 三.SPI与双亲委派 3.1.SPI加载到何处 3.2.SPI是否破坏了双亲委派 四.Dubbo SPI 4.1.基本概念 4.2.代码示例 4.3.源码分析 五.总结 一.概述 SPI 全称为 Service Provider Interface,是一种模块间组件相互引用的机制.其方案通常是提供方将接口实现类的全名配置在classPath下的指定文件中,由调用方读取并加载.这样需要替换某个组件时,只需要引入新的JAR包并

  • JDK与Dubbo中的SPI详细介绍

    目录 1.SPI简介 2.JDK中的SPI 3.Dubbo中的SPI 4.Dubbo中扩展点使用方式 5.DubboSPI中的Adaptive功能 1.SPI简介 SPI 全称为 (Service Provider Interface) ,是JDK内置的一种服务提供发现机制. 目前有不少框架用它来做服务的扩展发现,简单来说,它就是一种动态替换发现的机制.使用SPI机制的优势是实现解耦,使得第三方服务模块的装配控制逻辑与调用者的业务代码分离. 2.JDK中的SPI Java中如果想要使用SPI功能

  • Java Spring Dubbo三种SPI机制的区别

    目录 前言 SPI 有什么用?​ JDK SPI​ Dubbo SPI Spring SPI​ 对比​ 前言 SPI 全称为 Service Provider Interface,是一种服务发现机制.SPI 的本质是将接口实现类的全限定名配置在文件中,并由服务加载器读取配置文件,加载实现类.这样可以在运行时,动态为接口替换实现类.正因此特性,我们可以很容易的通过 SPI 机制为我们的程序提供拓展功能. 本文主要是特性 & 用法介绍,不涉及源码解析(源码都很简单,相信你一定一看就懂) SPI 有什

  • Apache Dubbo的SPI机制是如何实现的

    一.SPI 1.1 JDK自带SPI实现 从JDK1.6开始引入SPI机制后,可以看到很多使用SPI的案例,比如最常见的数据库驱动实现,在JDK中只定义了java.sql.Driver的接口,具体实现由各数据库厂商来提供.下面一个简单的例子来快速了解下Java SPI的使用方式: 1)定义一个接口 package com.vivo.study public interface Car { void getPrice(); } 2)接口实现 package com.vivo.study.impl

  • 浅析Java SPI 与 dubbo SPI

    Java原生SPI 面向接口编程+策略模式 实现 建立接口 Robot public interface Robot { /** * 测试方法1 */ void sayHello(); } 多个实现类实现接口 RobotA public class RobotA implements Robot { public RobotA() { System.out.println("Happy RobotA is loaded"); } @Override public void sayHel

  • Dubbo扩展点SPI实践示例解析

    目录 正文 扩展点配置: 扩展实现类: 拦截配置文件: 调用拦截扩展: 拦截扩展说明: 常用约定: 实现细节: 扩展点的几个特点: 扩展点自动包装 扩展点自动装配 扩展点自适应 扩展点自动激活 正文 Dubbo的扩展点加载从JDK标准的SPI(Service Provider Interface)扩展点发现机制加强而来.Dubbo改进了JDK标准的SPI的以下问题: JDK标准的SPI会一次性实例化扩展点所有实现,如果有扩展实现初始化很耗时,但如果没用上也加载,会很浪费资源.如果扩展点加载失败,

  • SpringBoot详细介绍SPI机制示例

    目录 简介 Java SPI实现 示例说明 创建动态接口 实现类1 实现类2 相关测试 运行结果 源码分析 Spring SPI 源码分析 总结 简介 SPI(Service Provider Interface)是JDK内置的一种服务提供发现机制,可以用来启用框架扩展和替换组件,主要用于框架中开发,例如Dubbo.Spring.Common-Logging,JDBC等采用采用SPI机制,针对同一接口采用不同的实现提供给不同的用户,从而提高了框架的扩展性. Java SPI实现 Java内置的S

  • java面向对象设计原则之开闭原则示例解析

    概念 唯一不变的是不断的变化,在软件开发中应该对需求的变化持开放态度,我们要做的就是如何将这种变化对我们现有的成果带来最小的冲击.开闭原则直接面对面向对象程序的目标扩展性和可维护性,要求对扩展开放,对修改关闭:即在不修改原有代码的情况下改变模块的行为.该原则是面向对象程序设计的总原则,也是度量程序设计的好与坏的唯一标准 实现 开闭原则的实现策略主要在面向对象的封装性和多态性的基础上,利用面向对象的其他原则完成的. 1.使用多态机制解决问题. 如:远程监控系统使用数据传输使用427版本的协议,一年

  • 微服务架构之服务注册与发现实践示例详解

    目录 1 服务注册中心 4种注册中心技术对比 2 Spring Cloud 框架下实现 2.1 Spring Cloud Eureka 2.1.1 创建注册中心 2.1.2 创建客户端 2.2 Spring Cloud Consul 2.2.1 Consul 的优势 2.2.2 Consul的特性 2.2.3 安装Consul注册中心 2.2.4 创建服务提供者 3 总结 微服务系列前篇 详解微服务架构及其演进史 微服务全景架构全面瓦解 微服务架构拆分策略详解 微服务架构之服务注册与发现功能详解

  • Spring Data Jpa框架最佳实践示例

    目录 前言 扩展接口用法 SPRINGDATAJPA最佳实践 一.继承SIMPLEJPAREPOSITORY实现类 二.集成QUERYDSL结构化查询 1.快速集成 2.丰富BaseJpaRepository基类 3.最终的BaseJpaRepository形态 三.集成P6SPY打印执行的SQL 结语 前言 Spring Data Jpa框架的目标是显著减少实现各种持久性存储的数据访问层所需的样板代码量. Spring Data Jpa存储库抽象中的中央接口是Repository.它需要领域实

  • 新浪开源轻量级分布式RPC框架motan简单示例解析

    目录 前言 概述 功能 简单调用示例 在pom中添加依赖 为调用方和服务方创建公共接口 编写业务接口逻辑.创建并启动RPCServer 创建并执行RPCClient 集群调用示例 使用CONSUL作为注册中心 Motan-Consul配置 使用ZOOKEEPER作为注册中心 Motan-ZooKeeper配置 前言 好消息,支撑微博千亿调用的轻量级 RPC 框架 Motan 在2016年5月份正式开源了,业界现在除了Dubbo 和 DubboX典型的分布式RPC服务治理型框架外,又多了一个优秀的

  • SpringBoot扩展点EnvironmentPostProcessor实例详解

    目录 一.背景 二.需求 三.分析 1.什么时候向SpringBoot中加入我们自己的配置属性 2.获取配置属性的优先级 3.何时加入我们自己的配置 四.实现 1.引入SpringBoot依赖 2.在application.properties中配置属性 3.编写自定义属性并加入Spring Environment中 4.通过SPI使自定义的配置生效 5.编写测试类,输出定义的 username 属性的值 6.运行结果 五.注意事项 1.日志无法输出 3.日志系统如何初始化 六.完整代码 七.参

  • TDesign在vitest的实践示例详解

    目录 起源 痛点与现状 vitest 迁移 配置文件改造 开发环境 集成测试 ssr 环境 csr 环境 配置文件 兼容性 结果 CI测试速度提升 更清爽的日志信息 起源 在 tdesign-vue-next 的 CI 流程中,单元测试模块的执行效率太低,每次在单元测试这个环节都需要花费 6m 以上.加上依赖按照,lint 检查等环节,需要花费 8m 以上. 加上之前在单元测试这一块只是简单的处理了一下,对开发者提交的组件也没有相应的要求,只是让它能跑起来就好.另一方面单元测试目前是 TD 发布

随机推荐