dubbo中SPI接口的定义如下: @Documented @Retention(RetentionPolicy.RUNTIME) @Target({ElementType.TYPE}) public @interface SPI { /** * 缺省扩展点名. */ String value() default ""; } dubbo默认的情况下,会依次从下面几个文件中读取扩展点.1.META-INF/dubbo/internal/   //dubbo内部实现的各种扩展都放在了这个目

写在前面 最近接触了 gRPC 体会到虽然众多 RPC 框架各有各的特点但是他们提供的特性和功能有很多的相似之处 , 这就说明他们面对同样的分布式系统带来的问题.从 2016 年左右开始接触到 dubbo ,基本停留在使用的层面,对 dubbo 的设计以及着重要解决的问题都没有系统的研究过,通过对 dubbo 和其他类似 RPC 产品的系统学习 ,学习分布式系统中面临的共同问题以及解决之道. 微内核架构 微内核架构 (Microkernel architecture) 模式也被称为插件架构 (P

写在前面 最近接触了 gRPC 体会到虽然众多 RPC 框架各有各的特点但是他们提供的特性和功能有很多的相似之处 , 这就说明他们面对同样的分布式系统带来的问题.从 2016 年左右开始接触到 dubbo ,基本停留在使用的层面,对 dubbo 的设计以及着重要解决的问题都没有系统的研究过,通过对 dubbo 和其他类似 RPC 产品的系统学习 ,学习分布式系统中面临的共同问题以及解决之道. 微内核架构 微内核架构 (Microkernel architecture) 模式也被称为插件架构 (P

SPI 全称为 Service Provider Interface,是一种服务发现机制.当程序运行调用接口时,会根据配置文件或默认规则信息加载对应的实现类.所以在程序中并没有直接指定使用接口的哪个实现,而是在外部进行装配. 要想了解 Dubbo 的设计与实现,其中 Dubbo SPI 加载机制是必须了解的,在 Dubbo 中有大量功能的实现都是基于 Dubbo SPI 实现解耦,同时也使得 Dubbo 获得如此好的可扩展性. Java SPI 通过完成一个 Java SPI 的操作来了解它的机

文章目录 引言 正文 一.什么是SPI? 1. Java SPI的实现 2. Dubbo SPI实现原理 由配置文件得到的猜想 SPI源码 二.自适应扩展机制 三.Dubbo IOC 总结 引言 Dubbo虽然已交由apache管理,并且社区活跃度也不如SpringCloud,但也是国内应用比较广泛的RPC框架,其背后的设计思想非常值得我们学习借鉴.鉴于Dubbo官方文档对于基础的使用配置已经讲解的非常清楚了,这里就不再赘述.本系列文章将基于Dubbo2.5.3版本的源码做分析.而Dubbo中最

SPI 全称为 Service Provider Interface,是一种服务发现机制.SPI 的本质是将接口实现类的全限定名配置在文件中,并由服务加载器读取配置文件,加载实现类.这样可以在运行时,动态为接口加载实现类.其实这有有点像IOC的思想,将装配的控制权移到程序之外 Java SPI 示例 首先定义一个接口: public interface Robot { void sayHello(); } 再定义两个实现类: public class OptimusPrime implement

最近抽空开始了 Dubbo 源码的阅读之旅,希望可以通过写文章的方式记录和分享自己对 Dubbo 的理解.如果在本文出现一些纰漏或者错误之处,也希望大家不吝指出. Dubbo SPI 介绍 Java SPI 在阅读本文之前可能需要你对 Java SPI(Service Provider Interface) 机制有过简单的了解.这里简单介绍下:在面向对象的设计中,我们提倡模块之间基于接口编程.不同模块可能会有不同的具体实现,但是为了避免模块的之间的耦合过大,我们需要一种有效的服务(服务实现)发现

1. 什么叫SPI? 简单总结就是一种使用类名字符串来动态实例化java类的方式,也就是反射. 2. java SPI与Dubbo SPI有什么区别 (此图来自网上,我没有刻意去截图) 然后在这个文件里面写入实现类 com.blueskykong.javaspi.serializer.KryoSerializer com.blueskykong.javaspi.serializer.JavaSerializer 但是dubbo的SPI格式变了,也就意味着不能直接使用java SPI了 文件的目录

前言 阅读本文需要具备java spi的基础,本文不讲java spi,please google it. 一.Dubbo SPI 简介 SPI(Service Provider Interface)是服务发现机制,Dubbo没有使用jdk SPI而对其增强和扩展: jdk SPI仅通过接口类名获取所有实现,但是Duboo SPI可以根据接口类名和key值获取具体一个实现 可以对扩展类实例的属性进行依赖注入,即IOC 可以采用装饰器模式实现AOP功能 你可以发现Dubbo的源码中有很多地方都用到

目录 0.Java SPI示例 1.Dubbo SPI示例 2.Dubbo SPI源码分析 ​ SPI英文全称为Service Provider Interface.它的作用就是将接口实现类的全限定名写在指定目录的配置文件中,使框架读取配置文件,从而加载实现类.这样我们就可以动态的为接口替换实现类,使得框架拓展性更高.Java其实也有原生的SPI机制,但是Dubbo并未使用它.学习Dubbo源码的前提就是得弄懂Dubbo SPI机制. 0.Java SPI示例 public interface

SPI(Service Provider Interface)是JDK内置的一种服务提供发现机制.本质是将接口实现类的全限定名配置在文件中,并由服务加载器读取配置文件,加载实现类.这样可以在运行时,动态为接口替换实现类. 在Java中SPI是被用来设计给服务提供商做插件使用的.基于策略模式来实现动态加载的机制.我们在程序只定义一个接口,具体的实现交个不同的服务提供者:在程序启动的时候,读取配置文件,由配置确定要调用哪一个实现.有很多组件的实现,如日志.数据库访问等都是采用这样的方式,最常用的就是

Dubbo SPI 机制涉及到 @SPI.@Adaptive.@Activate 三个注解,ExtensionLoader 作为 Dubbo SPI 机制的核心负责加载和管理扩展点及其实现.本文以 ExtensionLoader 的源码作为分析主线,进而引出三个注解的作用和工作机制. ExtensionLoader 被设计为只能通过 getExtensionLoader(Class<T> type) 方法获取到实例,参数 type 表示拿到的这个实例要负责加载的扩展点类型.为了避免在之后的源码

JDK SPI JDK 标准的 SPI 会一次性加载所有的扩展实现,如果有的扩展吃实话很耗时,但 也没用上,很浪费资源. 所以只希望加载某个的实现,就不现实了 DUBBO SPI 1,对 Dubbo 进行扩展,不需要改动 Dubbo 的源码 2,延迟加载,可以一次只加载自己想要加载的扩展实现. 3,增加了对扩展点 IOC 和 AOP 的支持,一个扩展点可以直接 setter 注入其 它扩展点. 3,Dubbo 的扩展机制能很好的支持第三方 IoC 容器,默认支持 Spring Bean.

dubbo 常见错误 1. Caused by: java.lang.reflect.MalformedParameterizedTypeException 启动时报错,原因是dubbo 依赖 spring 2.5.6.SEC03,而我项目中有用spring 3.2.4.RELEASE,所以导致冲突. 在maven中把dubbo中的spring依赖去除就可以了. 如果你们项目中也报这个错,很可能也是因为jar包冲突造成的 1 2 3 4 5 6 7 8 9 10 <dependency>   

当一个接口实现,出现不兼容升级时,可以用版本号过渡,版本号不同的服务相互间不引用. 可以按照以下的步骤进行版本迁移: 在低压力时间段,先升级一半提供者为新版本 再将所有消费者升级为新版本 然后将剩下的一半提供者升级为新版本 老版本服务提供者配置: <dubbo:service interface="com.foo.BarService" version="1.0.0" /> 新版本服务提供者配置: <dubbo:service interface=

前言:2019年09月23日临下班,产品的一个变更需求临近尾声阶段.本地测试OK,兴致冲冲的想着发布到测试环境,验证一下没有问题,五分钟结束战斗,明天就开始下个需求了.随在CE(公司的devOps系统)上切换到hotfix/xxx分支,部署上线.部署没有问题,跑了一通单测,呃呃呃呃呃.莫名的一堆错误.怎么可能,再deploy ,再重启,还是这个错误,难道是公司的CE有问题(以前会莫名其妙的出问题),释放掉重新申请服务器部署.忙了一通还是不行.绝望,后悔.公司的什么烂逼环境.本地明明没有问题,怎么

JDK标准中SPI机制的一个问题就是其一次性实例化扩展点所有实现,如果有扩展实现初始化很耗时,但如果没用上也加载,会很浪费资源:扩展点加载失败,其他扩展点都用不了了.Dubbo是如何解决该问题动态的选择具体的扩展点呢?使用@Adaptive. Dubbo中的Adaptive功能,主要解决的问题是如何动态的选择具体的扩展点.通过getAdaptiveExtension同一对知道接口对于的所有扩展点进行封装,同时通过URL的方式对扩展点来进行动态选择(dubbo中所有的注册信息都是通过URL的形式进

一致性哈希算法原理以及做分布式存储.一定先看:一致性哈希算法 dubbo提供了四种负载均衡实现:权重随机算法,最少活跃调用数算法,一致性哈希算法,加权轮询算法. 本文基于开源项目:guide-rpc-framework的一致性哈希算法做的负载均衡,这个项目的负载均衡是dubbo一致性哈希的简化版. 代码如下: /** * refer to dubbo consistent hash load balance: https://github.com/apache/dubbo/blob/2d9583

首先简单阐述下什么是SPI:SPI 全称为 (Service Provider Interface) ,是JDK内置的一种服务提供发现机制.目前有不少框架用它来做服务的扩展发现,简单来说,就是一种动态替换发现的机制.使用SPI机制的优势是实现解耦,使得第三方服务模块的装配控制逻辑与调用者的业务代码分离. SPI遵循如下约定: 1.当服务提供者提供了接口的一种具体实现后,在META-INF/services目录下创建一个以"接口全限定名"为命名的文件,内容为实现类的全限定名: 2.接口实

源码分析: /** * 获取扩展类 */ @SuppressWarnings("unchecked") public T getExtension(String name) { if (StringUtils.isEmpty(name)) { throw new IllegalArgumentException("Extension name == null"); } // 获取默认的拓展实现类 if ("true".equals(name))

前言 在上一篇的末尾,我们提到了dubbo的spi中增加了IoC和AOP的功能.那么本篇就讲一下这个增加的IoC,spi部分预计会有四篇,因为这东西实在是太重要了.温故而知新,我们先来回顾一下,我们之前都讲了什么. spi(1) 主要讲了spi的基本概念,简单的入门,并以spi为线索讲解了双亲委托模式的弊端以及解决方案 spi(2) 主要以dubbo改进了jdk的spi为线索,重点讲分析问题的思路,从实际案例实战从哪里着手分析问题这个大家最喜欢问的问题. 提到IoC,大家第一个想到的就是Spri