Dubbo源码解析
文章平均质量分 82
Dubbo源码解析
恐龙弟旺仔
保持热爱,保持进步
展开
-
Dubbo源码解析-隐式参数传递
前言:在Dubbo中,为provider和consumer提供了一种被称为隐式参数传递的策略,可用于在两者之间传递参数。本文先通过一个示例来展示下其使用过程,后续通过源码来分析下其传递过程。1.示例分析1.1 consumer示例public class Application { // 服务提供者代码有所精简,本质上还是与之前的示例一样 public static void main(String[] args) throws Exception { Refe原创 2021-12-12 20:01:26 · 2616 阅读 · 1 评论 -
Dubbo源码协议-Filter的使用
前言:Filter的功能我们之前一直都是一笔带过的,在本文中,我们就好好说明下Filter的创建以及其功能。其实Filter在各个中间件框架中基本都存在的,主要作为拦截层,在真正执行操作之前,先执行Filter中的功能,以实现特定功能的扩展。1.Filter链的创建在provider创建时,交由Protocol$Adaptive.export()方法暴露服务时,便会执行ProtocolFilterWrapper.export()方法(这块是SPI相关的知识点)。Filter链的创建就是在原创 2021-12-12 19:58:08 · 662 阅读 · 0 评论 -
Dubbo源码解析-服务提供者线程池模型分析
前言:紧接上文,在上文中,我们提到了Dispatcher的各种实现方案。通过AllDispatcher(默认)的设定,provider针对接收到的请求会转交由线程池来执行。那么针对线程池而言,Dubbo是怎样创建的呢?有没有提供不同的创建方案呢?1.创建线程池入口同样,我们先来从源码中了解下创建线程池的代码入口。以AllDispatcher为例,在处理connected()请求时,执行代码如下public class AllChannelHandler extends Wrap原创 2021-12-12 19:55:24 · 1891 阅读 · 0 评论 -
Dubbo源码解析-服务提供者线程模型分析
前言:通过之前对provider启动过程的学习,我们知道,提供者默认是以Netty来启动对应协议端口来提供服务的。Netty的标准启动模式下有两个线程组:boss和work线程组。在接收到具体的请求后,如果服务提供者对该请求处理时间比较短,那么直接在work线程上处理即可;如果服务提供者对该请求处理时间比较长,那么如果还在work线程上处理,则会阻塞其他请求的处理,降低了整个provider的处理能力。如何解决这种问题呢?可以通过自定义一个线程池,将work线程接收到的请求,交由原创 2021-12-10 12:23:31 · 1740 阅读 · 0 评论 -
Dubbo源码解析-序列化的实现
前言:前文中介绍了有关Dubbo协议的相关知识。Dubbo协议是Dubbo框架自定义的一种协议,类似于HTTP协议,也是一种应用层协议。从Dubbo框架结构来看(参考:https://dubbo.apache.org/zh/docsv2.7/dev/design/),其位于如下位置:服务消费者和提供者依据协议的模式来进行消息的发送和接收。在消息发送的过程中,需要对消息体进行序列化操作,而Dubbo本身提供了多种序列化方式,本文就来简单了解下这些序列化方式。1.获取序列化方式.原创 2021-12-09 12:25:51 · 1369 阅读 · 0 评论 -
Dubbo源码解析-Transporter的实现
前言:Transporter在Dubbo架构中,属于比较底层的存在。主要用于请求、响应的传输。其在Dubbo架构中的位置如下:而关于Transporter的实现,主要有以下几种:本文主要来了解下NettyTransporter(默认传输方式)的相关知识点。1.NettyTransporter的那些方法/** * 默认使用Netty4实现 */public class NettyTransporter implements Transporter { pub原创 2021-12-08 12:24:52 · 478 阅读 · 0 评论 -
Dubbo源码解析-Exchanger的实现
前言:在介绍完Protocol层之后,下面来到Exchanger层。它在整个Dubbo架构中如下所示:主要作用:作为信息交换层,封装请求响应模式,同步转为异步。将Server包装为ExchangeServer;将client包装为ExchangeClient。本文就来分析下这几个重点类。1.ExchangeClient 客户端的创建先来看下其入口:DubboProtocol.initClient() 来创建ExchangeClient,最终交由HeaderExchan原创 2021-12-07 12:31:11 · 656 阅读 · 0 评论 -
Dubbo源码解析-Http协议解析
前言:在前文介绍完Dubbo协议的传输之后,我们了解了Dubbo协议主要是定义了head+body,通过head中对每个字节的设置来区分具体的系列化方式,body长度,然后获取对应的body,并反序列化为一个可用的Request对象之后,交由对应的server来处理即可。本文再来介绍一种协议,一种我们都熟悉的协议:http协议,了解下在该协议下请求是如何传输和响应的。1.http协议的示例有关于接口和实现类如之前的示例一样:public interface DemoService原创 2021-12-06 12:40:42 · 1520 阅读 · 0 评论 -
Dubbo源码解析-Dubbo协议解析
前言:Dubbo提供了多种协议来进行服务消费者和提供者之间的交互。从Dubbo框架层次来看(参考:https://dubbo.apache.org/zh/docsv2.7/dev/design/),Dubbo协议位于以下位置:如何理解这些协议呢?我觉得可以按照HTTP协议的方式来理解,他们都是位于TCP协议之上的应用层协议。可以把他们理解为一份交流的说明书,每个字节都有其特定含义,服务消费者和提供者按照这份说明书来发送数据、接收数据,按照说明书的指示,解析出每个字节的含义,最终拼接.原创 2021-12-06 12:36:23 · 830 阅读 · 0 评论 -
Dubbo源码解析-集群容错策略解析
前言:消费者在真正发起对provider的调用之前,会先经过Cluster层,里面就是我们常说的集群容错方案。从Dubbo整体设计图上来看(参考:https://dubbo.apache.org/zh/docsv2.7/dev/design/),集群容错层位于以下位置:为什么会需要容错方案呢?当消费者在调用provider(一般会有多个提供者)时,有可能因为网络或其他原因导致失败,这时,框架需要能捕获到对应异常,并重新发起对其他provider的调用。这个就被称为集群容错方案。下面一原创 2021-12-03 18:54:17 · 1692 阅读 · 0 评论 -
Dubbo源码解析-Zookeeper注册中心解析
前言:在多服务提供者的情况下,如果消费者需要获取一个特定的提供者来进行消费,则需要注册中心的帮助。在Dubbo中,服务提供者启动时向注册中心注册当前provider_url,消费者在启动时也从注册中心中拉取当前接口的所有提供者信息,缓存到当前应用。而当服务提供者发生变动时(新的提供者上线或者已有提供者下线),注册中心也会将变动消息推送到各个消费者,以实现注册信息的及时更新。有关于注册中心,接口为Registry,Dubbo中提供的注册中心有如下:本文就来看下Zookeepe.原创 2021-12-03 18:48:25 · 902 阅读 · 0 评论 -
Dubbo源码解析-RegistryDirectory层的解析
前言:在分析完Dubbo的整体架构之后,我们对每个层次来单独分析下。我们的消费者在启动时,会去查询其所有对应的provider,并将URL转换为Invoker保存到当前内存,并启动对provider的监听,当其发生变动时,可以及时反馈到当前,对Invoker列表进行更新。那么以上是如何实现的呢?作为注册中心层,我们可以看到结构如下图:从RegistryProtocol开始,在RegistryFactory中获取到对应的Registry(示例中采取的是ZookeeperRegist原创 2021-12-02 12:25:11 · 1431 阅读 · 0 评论 -
Dubbo源码解析-Dubbo架构的实现
前言:在经过前面的学习之后,我们对Dubbo consumer、provider处理请求的过程有了一个基本了解。从本文开始,我们就要对Dubbo框架进行拆解,讲解每一个具体的技术点了。这样从使用到每层的技术点分析,可以完整的掌握整个Dubbo框架。本文就先从框架的整体面貌讲起,逐层来分析,后续针对每一个层次都会有专门的文章来说明。1.Dubbo架构图Dubbo的相关架构比较复杂,主要是分层次比较多。每层之间基本都是通过SPI的方式来生成调用的。通过SPI方式的调用,具有高度的灵活原创 2021-12-02 12:22:07 · 1435 阅读 · 0 评论 -
Dubbo源码解析-Provider处理请求全过程
前言:紧接着前一篇文章。上文分析了消费者发送请求的全过程,最终通过NettyChannel将请求发送到Provider,当然中间经过了一系列的处理。本文就从Provider的视角来看下,当服务提供者接收到了请求之后,是如何处理这个请求的。1.代码示例Provider示例如前文public class ProviderApplication { public static void main(String[] args) throws Exception {原创 2021-12-01 12:31:13 · 715 阅读 · 0 评论 -
Dubbo源码解析-Consumer发送请求全过程
前言:之前的文章已经从调用结构方面从前到后整个梳理了一下全过程。本篇就从实战调用角度来分析下整个过程,之前是抽象,现在就是实战。1.示例代码代码的话跟之前是一样的,笔者在这里再贴一下1.1 providerpublic class ProviderApplication { public static void main(String[] args) throws Exception { ServiceConfig<DemoServiceImpl&原创 2021-11-30 12:18:38 · 672 阅读 · 0 评论 -
Dubbo源码解析-Dubbo服务消费_Dubbo协议(二)
上一篇文章中,介绍了Dubbo协议的服务消费者的创建过程。其中有很重要的一个点就是消费者会创建对服务端对应协议端口的长连接,后续的调用发起就是通过这个连接来发起的。 本文就来看下客户端长连接创建的过程。1.DubboProtocol.refer() 故事还是要从DubboProtocol开始说起public class DubboProtocol extends AbstractProtocol { public <T> Invoker<T>...原创 2021-11-29 12:30:41 · 939 阅读 · 0 评论 -
Dubbo源码解析-Dubbo服务消费者_Dubbo协议(一)
前言: 在介绍完Dubbo 本地模式(Injvm协议)下的服务提供与消费后,上文我们又介绍了Dubbo远程模式(dubbo协议)下的服务暴露过程,本质上就是通过Netty将dubbo协议端口暴露出去,然后将provider_url添加到对应的注册中心去。 在dubbo服务暴露出去之后,dubbo协议的消费者是怎么从注册中心获取到服务提供者的地址?又是怎么创建连接发起调用的呢?本文我们就一起来看下。 按照之前关于Injvm模式下的服务暴露和消费,Dubbo协议的消费者理论上也...原创 2021-11-29 12:25:11 · 1627 阅读 · 0 评论 -
Dubbo源码解析-Dubbo服务提供者_Dubbo协议(二)
前言: 在介绍完基于Dubbo协议的服务提供者,暴露服务的整个过程后,本文重点介绍下Exchange层是如何将Url服务暴露出去。 之前笔者有提示过,是通过Netty的方式启动本地端口来暴露服务的,那么我们通过这篇文章来具体看下暴露的整个过程。1.Exchangers.bind(url,handler) 接着上文的示例来说,我们分析到Exchangers.bind()方法后便没有继续后续的分析。public class Exchangers { publ...原创 2021-11-24 20:18:33 · 798 阅读 · 0 评论 -
Dubbo源码解析-Dubbo服务提供者_Dubbo协议(一)
前言: 前面两篇文章分别讲述了本地模式下的协议暴露(InjvmProtocol)和协议消费(InjvmInvoker)。实际到这里的话,协议暴露只讲述了一半,因为协议的暴露默认还会以DubboProtocol的模式暴露出去。本文就来了解下Dubbo如何向外暴露服务。 强烈建议读者可以先看下Dubbo源码解析-Dubbo服务提供者_Injvm协议(二)_恐龙弟旺仔的博客-CSDN博客这篇文章,对local模式的服务暴露有一个了解后(最主要是对PROXY_FACTORY和PROXY的分析...原创 2021-11-24 20:14:32 · 932 阅读 · 0 评论 -
Dubbo源码解析-Dubbo服务消费者_Injvm协议(一)
前言: 前两篇我们分析了Dubbo服务提供者,在创建时的基本配置属性,如ServiceConfig、ApplicationConfig、RegistryConfig等。基本了解了基于API方式来创建Dubbo服务提供者的套路。 同时第二篇我们分析了在injvm(本地)模式下,dubbo服务如何向外注册(本质上还是注册在本地的map中,就是InjvmProtocol.exporterMap中),等待同进程中的服务消费者来调用(这个很重要,笔者基于Dubbo-demo源码中测试代码进行测试时...原创 2021-11-23 12:28:25 · 1485 阅读 · 0 评论 -
Dubbo源码解析-Dubbo服务提供者_Injvm协议(二)
前言: 在前一篇文章中介绍了Dubbo服务提供者的基本创建过程,同时分析了其基本配置信息。本文就来介绍下dubbo服务提供者暴露在本地模式下的经过。1.ServiceConfig之scope 之前的示例中,我们没有设置scope属性。scope属性默认有:local和remote,如果不设置的话,那么就是默认的none。 这个scope属性,决定了该服务提供者的服务范围。 local:只暴露在本地,不向外部提供服务,那么通过协议(dubbo等)过来的请求则无...原创 2021-11-23 12:21:15 · 1635 阅读 · 0 评论 -
Dubbo源码解析-动态编译javaAssist的使用
前言: 在Dubbo中,大量使用动态代理相关技术。动态代理主要是基于JDK的动态代理和Javassist的动态代理。 有关于JDK动态代理的使用及源码解析可以参考上文。 本文着重来介绍下Javassist的使用,及其动态代理的实现。1.Javassist简介 Javassist是一个开源的分析、编辑和创建Java字节码的类库。是由东京工业大学的数学和计算机科学系的 Shigeru Chiba (千叶 滋)所创建的。它已加入了开放源代码JBoss 应用服务器项...原创 2021-11-22 12:24:09 · 998 阅读 · 0 评论 -
Dubbo源码解析-动态代理JDK篇
前言: 有关于动态代理,是一个长盛不衰的话题。无论是面试还是各个框架的应用,都是热点话题。 而关于Dubbo的动态代理,有两种实现方式:一种是JDK,另一种是Javassist。 本文来介绍下JDK动态代理的使用方式,并简单分析下其源码实现。1.JDK动态打理示例1.1 创建接口及实现类// 接口public interface Subject { String say(String name);}// 实现类public class Rea...原创 2021-11-22 12:20:18 · 1044 阅读 · 0 评论 -
Dubbo源码解析-SPI的应用
前言: Dubbo中大量使用了SPI的技术,实现各调用层之间的解耦。所以,了解SPI技术的实现还是很有必要的。 JDK本身也有SPI的实现,Dubbo对该技术实现了增强。1.SPI SPI(Service Provider Interface),是java提供的一套用来被第三方实现或扩展的接口。而SPI技术就是用来查找这些扩展实现。 概念相对比较难懂,读者可以参考这篇博文(笔者是没太读懂):https://www.cnblogs.com/happyframew...原创 2021-11-19 12:34:07 · 1186 阅读 · 2 评论 -
Dubbo源码解析-Dubbo服务提供者_Injvm协议(一)
前言: 根据前面两篇自定义RPC框架的文章,我们带着问题来学习Dubbo。 学习Dubbo是如何解决这些服务调用、注册中心、序列化、集群容错等问题。 注意:笔者使用的Dubbo版本为2.7.7,源码地址为:https://github.com/apache/dubbo; 控制台为Dubbo-admin,源码地址为:https://github.com/apache/dubbo-admin 本文主要集中在Dubbo服务端,使用最原始的API方式来构建一个可...原创 2021-11-19 12:24:14 · 1981 阅读 · 0 评论 -
自定义一个简单的RPC框架(二)
前言: 上一篇文章中,我们通过一个简单的示例来模拟了RPC的调用。后续通过Netty改造了服务端框架,适当的提高了服务端性能。 但是改造后的可以作为一个底层RPC框架来使用吗?显然是不能,还缺了很多东西,性能还有很多需要优化的地方。 本篇文章我们就一起来分析下如果想做成一个成熟点的RPC框架,还需要做哪些工作。1.面临的挑战 * 服务端是单机的,单机的应用永远都会有单点故障的问题,所以需要做成集群模式 * 如果服务端是集群的,那么客户端在调用的时...原创 2021-11-18 19:10:13 · 785 阅读 · 0 评论 -
自定义一个简单的RPC框架(一)
前言: 在学习Dubbo之前,我们先使用目前已知的知识点(非RPC框架),来创建一个最简单的RPC调用。 我们在开发工作中,常用的CS架构中,调用方式以HTTP居多,浏览器发起一起HTTP调用,我们的服务端接收请求并返回响应。 一直以来有一个问题萦绕在笔者心头,既然已经有了HTTP调用这么简单的方式,为什么还要开发出那么多RCP框架? 大家可以思考下,下面我们直接切入正文,来创建一次最简单的RCP调用1.准备工作 * 我们准备一个接口,并创建其实...原创 2021-11-17 20:09:27 · 732 阅读 · 0 评论