dubbospi（dubbospi原理）

本篇文章给大家谈谈dubbospi，以及dubbospi原理对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。

本文目录一览：

• 1、Dubbo之SPI实现原理详解
• 2、dubbo的Filter机制
• 3、Dubbo SPI之Adaptive详解
• 4、Dubbo——服务调用、服务暴露、服务引用过程

Dubbo之SPI实现原理详解

 SPI全称为Service Provider Interface，是一种服务提供机制，比如在现实中我们经常会有这种场景，就是对于一个规范定义方而言（可以理解为一个渣档李或多个接口），具体的服务实现方是不可知的（可以理解为对这些接口的实现类），那么在定义这些规范的蠢兄时候，就需要规范定义方能够通过一定的方式来获取到这些服务提供方具体提供的是哪些服务，而SPI就是进行这种定如迟义的。

说明：

Dubbo 的扩展点加载是基于JDK 标准的 SPI 扩展点发现机制增强而来的，Dubbo 改进了 JDK 标准的 SPI 的以下问题：

dubbo对于SPI的实现主要是在ExtensionLoader这个类中，这个类主要有三个方法：

如下是getExtension()方法的源码：

createExtension()方法的源码：

在createExtension()方法中，其主要做了三件事：

关于wrapper对象，这里需要说明的是，其主要作用是为目标对象实现AOP。wrapper对象有两个特点：

getExtensionClasses()方法的源码

loadDirectory()方法的源码：

loadClass()方法的源码

loadClass()方法主要作用是对子类进行划分，这里主要划分成了三部分：

总结而言，getExtension()方法主要是获取指定名称对应的子类。在获取过程中，首先会从缓存中获取是否已经加载过该子类，如果没加载过则通过定义文件加载，并且使用获取到的wrapper对象封装目标对象返回。

getAdaptiveExtension()方法源码

dubbo的Filter机制

以dubbo官方demo为例，在provider端，从netty接收到消息，递交给业务线程池处理开始，到真正调用到业务方法sayHello()结束，中间经过了十几个Filter的处理。见下图

那么这些Filter是如何初始化的，调用的时候又是如何执行的呢？接下来一步一步介绍。

dubbo在进行服务导出时主要做了如下一些工作

可者核以看到：第二步中核心工作就包括Filter的初始化。见下ProtocolFilterWrapper#export方法

其中有一步是buildInvokerChain，从名字上也可以看出，这是初始化一个责任链，对应设计模式中的责任链模式。接着看这个责任链是怎么初始化的（ProtocolFilterWrapper#buildInvokerChain）

可以看到这个Filter的责任链初始化过程

1.通过dubbo spi机制，取得所有Filter实例形成一个ArrayListFilter

2.遍历这个ArrayList，以next指针初始化一个Invoker的链表InvokerList

3.Invoker执行逻辑即执行Filter的invoke方法的同时，将next指针作为参轮嫌侍数传入，以支持链式调用

整个过程结束之后，会有两个List，一个ArrayListFilter，一个以NEXT指针形成的InvokerList，这两个List就是dubbo Filter机制的基础。

Filter接口提供了一个invoke方法，另一个是Listener接口，有onResponse，onError两个方法。

这两部分对应着Filter对请求和响应的处理逻辑

请求的处理以AccessLogFilter#invoke的实现为例,可以看到，其首先进行AccessLog的处理，然后调用

invoker.invoke().这个invoker即之前Filter初始化的时候，以Next指针形成的那个InvokerList链表中的节点。这样一来，整个链表中的节点都会得到顺序执行。

响应的处理可以见CallbackRegistrationInvoker#invoke

之前Filter初始化的时候，会形成两个list，next指针形成的那个链表用于对请求的处理，另一个ArrayListFilter 就是在此时执行,拿到结果之后，遍历这腊吵个ArrayList，执行其onResponse或者onError方法，如此一来，请求和响应应就会经过所有生效的Filter处理。

总结：dubbo的Filter机制是一种典型的责任链模式，这个链的基础即上述两个list。如果我们在自己的业务场景中，需要对请求或者响应做一些通用的处理，那么也很简单，直接基于dubbo spi（

），自定义逻辑实现Filter接口的相应方法即可。

[img]

Dubbo SPI之Adaptive详解

为ThriftAdaptiveExt2类添加@Adaptive注解

下面我们带着上面的结论，看一下源码。首先我们从这句话开始讲起

下面是源码的注释

先检查有没有带SPI的注解，没有带，直接报错，从缓存中根据斗宏袭这个类型查询对应的ExtensionLoader，查不到就创建一个，再放入缓存中。dubbo中的空兄spi部分大量利用了本地缓存，后续出现，不再着重讲解了。我们可以看一下他的创建该类型的ExtensionLoader的方法。

关注点有两个，第一个构造方法是私有的，说明不想通过外部实例化，将实例化的过程统一收紧。第二个是objectFactory这个在后面的ioc部分会发挥它的作用，敬请期待。好了，目前为止，ExtensionLoaderAdaptiveExt2 loader = ExtensionLoader.getExtensionLoader(AdaptiveExt2.class) 说的差不多了，下面进入我们的大头getAdaptiveExtension

第一次从缓存中获取就创建

获取到适配器类的Class,利用反射创建适配器类的实例。injectExtension是dubbo的DI，依赖注入。如果适配器类有属性的set方法，会自动注入，这个后续会开一个章节进行解释。看来我们最终要关注的是getAdaptiveExtensionClass方法。大家跟紧了，大片开始了。

按照顺序来吧，看下getExtensionClasses

从缓存中取，也就是说，加载的流程只触发一次，然后放入缓存，后续从缓存取。

获取type上的SPI注解，如果里面有值赋给cachedDefaultName这个变量，相当于是个默认的值。随后从META-INF/dubbo/internal/，META-INF/dubbo/，META-INF/services/这三个路径下搜索对应的文件，什么是对应的？就是命名是这个type类的绝高全限定名称。下面这个方法有点长，希望不要看吐，还好加了注解，希望看起来会通畅点。

路径+文件名，组成了一个具体的文件名，根据 classLoader.getResources 方法获取到Enumerationjava.net.URL 类型的对象，随后就是遍历,文件里面的格式是这样的。

如果有 # ，按照 # 分割，前面的是我们需要的业务数据，后面是注释。我们所需要的数据中如果有 = ,那么就按照 = 进行分割,前面是这个扩展的名称，后面是这个扩展的全限定类名，方便利用反射加载进来。加载进来之后会判断下是不是传入类（type）类型的实例，不是的话，报错！如果有的类上带有@Adaptive注解，那么将这个类赋值给cachedAdaptiveClass，注意这个点，查询type类型适配器类的时候会优先寻找cachedAdaptiveClass，因为是系统指定的适配器类，优先级最高，可以看下我们上面的测试三，说的就是这种情况。如果有多个实现再类上都打上了@Adaptive注解，会报错：标准的适配器类只能有一个。如果这个扩展类没有打上@Adaptive注解就更有意思了。首先第一步会验证下有没有type这个类型作为入参的构造方法，为什么要这么做？因为Wrapper，有的类型需要包装一下，例如type=Protocol.class 就会看到有DubboProtocol真实的Protocal类,还会有ProtocolFilterWrapper和ProtocolListenerWrapper这种Wrapper类，这种Wrapper类的共同点就是构造函数的入参是type类型，所以在解析的时候有这么一步。如果有这种构造函数的就是Warpper类，将这些Warpper类型的数据放到cachedWrapperClasses这个集合中缓存。如果没有这种类型的构造函数，就是正常的type类型的实例了，如果在文件中没有声明这个扩展的名称（ = 左边的部分），就会根据这个类名创建一个名称。然后进入下一个环节@Activate数据的解析，这个本来是下一节的内容，我们提前了解下吧。查看type类上有没有@Activate注解，如果有的话，将名称与注解放到cachedActivates这个Map中进行缓存。将扩展类和名称放入cachedNames这个Map中进行缓存，将名称和扩展类的class放入传递进来的extensionClasses中，最后这个extensionClasses会被返回出来被使用。OK，到目前为止我们结束了getExtensionClasses方法的讲解，是不是很绕，东西很多。再回来我们看下剩下的。

如果cachedAdaptiveClass不为空就返回，什么情况下不为空？当扩展类上打上@Adaptive注解的时候，就会将这个类直接返回。如果没有上注解，怎么办，就得自己生成了，也就是createAdaptiveExtensionClass

思路很简单，将类以字符串的形式拼接出来，然后利用编译器进行编译，返回编译后的class对象。寻找编译器的过程和具体编译的过程不是我们此次所要关心的，我们关心的是这个createAdaptiveExtensionClassCode方法创建的字符串格式的数据是啥样的，用到了哪些数据。又是一个大方法，也是要走起的，come on

首先寻找这个类中所有的方法，查看方法中有没有打@Adaptive注解的，一个没有，直接报错！对于那些没有加@Adaptive注解的方法，直接在要创建的Adaptive类上增加此方法不支持操作的异常。在方法中的@Adaptive是可以加上value值的，如果用户填了，使用此值，没有填将使用程序根据类名创建的值作为value值，这个value值通URL中的参数名保持一致。defaultExtName是SPI中的value值，这里可以看一下我们的测试四的方法。最后我们看一下，他生成的String是什么样子的

将上面这个字符串编译成Class对象，作为适配器类，返回，然后实例化后，进行依赖注入需要的属性，随后缓存，备下次使用。

基本上所有类型的动态导入都是使用adaptive,使用范围极广。

dubbo-test测试源码

下一篇: Dubbo SPI 之Activate详解

END

Dubbo——服务调用、服务暴露、服务引用过程

1、InvokerInvocationHandler jdk动态代理

5、RegistryDirector返回Invokers

Router分为：Script 脚本路由、Condition 条件路由

6、通过MockInvokersSelector的route方法（getNormalInvokers）拿到能正常执行的invokers

8、当回到AbstractClusterInvoker后，执行首纳（默认FailoverClusterInvoker，根据配置的是，Failfast Cluster(快速失败) , Failsafe Cluster(失败安全) , Failback Cluster(失败自动恢复) , Forking Cluster(并行调用多个服务器，只要一个成功即返回) , Broadcast Cluster(广播调用所有提供者，逐个调用，任意一台报错则报错)）doInvoker方法

9、FailoverClusterInvoker调用AbstractClusterInvoker的select方法

10、执行doSelect方法

11、调用AbstractLoadbalance的select方法

12、根据配置的负载均衡策略调用对应的（如RoundRobinLoadBalance）类的doSelect方法

13、返回invokers.get()方法

14、调用FailoverClusterInvoker的invoke方法

均继承自抽象类AbstractDirectory

Directory 获取 invoker 是从 methodInvokerMap 中获取的，主要都是读操作,那它的写操作是在什么时候写的呢?就是在回调方法 notify 的时候操作的，也就是注册中心有变化,则更新 methodInvokerMap 和 urlInvokerMap 的值

根据dubbo-admin配置的路由规则来过滤相关的invoker，当我们对路由规则点击启用，就会触发 RegistryDirectory 类的 notify 方法。

notify方法调用refreshInvoker方法。

route方法的实现类为ConditionRoute 根据条件进行过滤

1、调用mathThen方法

2、调用matchCondition方法

3、调用isMatch判断

4、调用isMatchGlobPattern方法

集群模块是服务提供者和服务消费者的中间层，为服务消费者屏蔽了服务提供者的情况，这样服务消费者就可以专心处理远程调用相关事宜。比如发请求，接受服务提供者返回的数据等。这就是Dubbo Cluster集群的作用。

通过cluster来指定集群容错方式

其实就是应对出错情况采取的策略

用于芹磨有状态服务，尽可能让客户端总是向同一提供者发起调用，除非提供者挂了，再连另一台，自动开启延迟链接，以减少长接数

启动时服务提供者将当前进程启动时间注册到ZK；服务消费者发现该节点后计算服务启动时间（相对当前时间），在默认预热时间的前20%时间内，该节点权重始终固定为2，这样客户端的负载均衡器只会分发极少的请求至节点。

在预热时间之后的80%时间内，该节点权重将随着时间的推移而线性增长；待预热时间到期后，权重自动恢复为默认值100；负载均衡器的内核是一个标准的WLC算法模块，即加权最少连接算法；

如果某个节点Hang住或宕机，其权重会迅速自动调节降低，避免持续性影响；当节点下线时，服务端提前触发权重调节，重载默认权重至1并发布到注册中心，服务消费者将迅速感知到该事件；

服务提供者优雅下线步骤（注意这套逻辑仅在服务端执行）在ok.htm?down=true对应的controller中加入下列逻辑，注意嫌芹斗要判断down是否为true，因为正常来说false表示启动验证而不是关机

服务者消费者配置

dubbo服务支持参数动态调整，例如动态调整权重，但dubbo实现方式较为特殊，并不是常规思路。

ServiceConfig类拿到对外提供服务的实际类ref，然后通过ProxyFactory类的getInvoker方法使用ref生成一个AbstractProxyInvoker实例，到这一步就完成具体服务到Invoker的转换（javassistProxyFacory、JdkProxyFactory），接着要做Invoker转换到Export的过程

服务发布：本地暴露、远程暴露

为什么会有 本地暴露 和 远程暴露 呢?不从场景考虑讨论技术的没有意义是.在dubbo中我们一个服务可能既是 Provider ,又是 Consumer ,因此就存在他自己调用自己服务的情况,如果再通过网络去访问,那自然是舍近求远,因此他是有 本地暴露 服务的这个设计.从这里我们就知道这个两者的区别

1、spring启动，解析配置文件

2、创建dubbo标签解析器

3、解析dubbo标签

4、ServiceBean解析

5、容器创建完成，触发ContextRefrestEvent

6、export暴露服务

7、duExportUrls

8、doExportUrlsFor1Protocol

9、getInvoker

10、protocol.export

11、开启服务器 openServer()如nettyServer

12、注册服务到注册中心 registerProvider

Filter 在服务暴露前，做拦截器初始化，在加载所有拦截器时会过滤支队provider生效的数据。

可以。zookeeper的信息会缓存到本地作为一个缓存文件,并且转换成 properties 对象方便使用。建立线程池，定时检测并连接注册中心，失败了就重连。

注册服务到zk其实就是在zk上创建临时节点，当节点下线或者down掉时，即会删除临时节点，从而使服务从可用列表中剔除。

持久节点

临时节点

1、export的时候进行zk订阅

2、设置监听回调的地址，回调给FailbackRegistry的notify

3、创建持久节点

4、设置对该节点的监听

5、更新新的服务信息，服务启动和节点更新回调，都会调用到这里

6、更新缓存文件

7、对比新旧信息是否有变化，有则重新暴露服务

高并发大业务量情况下，暂时屏蔽边缘业务

MockClusterInvoker

SPI 全称为 Service Provider Interface，是一种服务发现机制。SPI 的本质是将接口实现类的全限定名配置在文件中，并由服务加载器读取配置文件，加载实现类。这样可以在运行时，动态为接口替换实现类。正因此特性，我们可以很容易的通过 SPI 机制为我们的程序提供拓展功能。SPI 机制在第三方框架中也有所应用，比如 Dubbo 就是通过 SPI 机制加载所有的组件。不过，Dubbo 并未使用 Java 原生的 SPI 机制，而是对其进行了增强，使其能够更好的满足需求。在 Dubbo 中，SPI 是一个非常重要的模块。基于 SPI，我们可以很容易的对 Dubbo 进行拓展。如果大家想要学习 Dubbo 的源码，SPI 机制务必弄懂。接下来，我们先来了解一下 Java SPI 与 Dubbo SPI 的用法，然后再来分析 Dubbo SPI 的源码。

关于dubbospi和dubbospi原理的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。