Dubbo实现源码分析

  • Dubbo概述
  • Dubbo是阿里巴巴开源出来的一个分布式服务框架,致力于提供高性能和透明化的RPC远程服务调用方案,以及作为SOA服务治理的方案。它的核心功能包括:

    #remoting:远程通讯基础,提供对多种NIO框架抽象封装,包括“同步转异步”和“请求-响应”模式的信息交换方式。 #Cluster: 服务框架核心,提供基于接口方法的远程过程调用,包括多协议支持,并提供软负载均衡和容错机制的集群支持。 #registry: 服务注册中心,使服务消费方能动态的查×××提供方,使地址透明,使服务提供方可以平滑增加或减少机器。

    这里我们只是补充一下从源码具体实现角度来看的某些细节方面,包括Invoker、ExtensionLoader等方面。任何官方已经介绍过的细节,我们不做画蛇添足,官方文档已经足够详实了,这篇文档的定位是补充实现的相关细节,是基于我在往Dubbo添加web service协议过程中,所碰到过的一些困难。

    1. 服务提供者暴露一个服务的详细过程

    上图是服务提供者暴露服务的主过程:

    首先ServiceConfig类拿到对外提供服务的实际类ref(如:HelloWorldImpl),然后通过ProxyFactory类的getInvoker方法使用ref生成一个AbstractProxyInvoker实例,到这一步就完成具体服务到Invoker的转化。接下来就是Invoker转换到Exporter的过程。

    Dubbo处理服务暴露的关键就在Invoker转换到Exporter的过程(如上图中的红色部分),下面我们以Dubbo和RMI这两种典型协议的实现来进行说明:

    #Dubbo的实现

    Dubbo协议的Invoker转为Exporter发生在DubboProtocol类的export方法,它主要是打开socket侦听服务,并接收客户端发来的各种请求,通讯细节由Dubbo自己实现。

    #RMI的实现

    RMI协议的Invoker转为Exporter发生在RmiProtocol类的export方法,它通过Spring或Dubbo或JDK来实现RMI服务,通讯细节这一块由JDK底层来实现,这就省了不少工作量。

    1. 服务消费者消费一个服务的详细过程

    上图是服务消费的主过程:

    首先ReferenceConfig类的init方法调用Protocol的refer方法生成Invoker实例(如上图中的红色部分),这是服务消费的关键。接下来把Invoker转换为客户端需要的接口(如:HelloWorld)。

    关于每种协议如RMI/Dubbo/Web service等它们在调用refer方法生成Invoker实例的细节和上一章节所描述的类似。

    1. 满眼都是Invoker

    由于Invoker是Dubbo领域模型中非常重要的一个概念,很多设计思路都是向它靠拢。这就使得Invoker***在整个实现代码里,对于刚开始接触Dubbo的人,确实容易给搞混了。

    下面我们用一个精简的图来说明最重要的两种Invoker:服务提供Invoker和服务消费Invoker:

    为了更好的解释上面这张图,我们结合服务消费和提供者的代码示例来进行说明:

    #服务消费者代码

    #服务消费者代码 public class DemoClientAction { private DemoService demoService; public void setDemoService(DemoService demoService) { this.demoService = demoService; } public void start() { String hello = demoService.sayHello("world" + i); } }

    上面代码中的’DemoService’就是上图中服务消费端的proxy,用户代码通过这个proxy调用其对应的Invoker(DubboInvoker、 HessianRpcInvoker、 InjvmInvoker、 RmiInvoker、 WebServiceInvoker中的任何一个),而该Invoker实现了真正的远程服务调用。

    #服务提供者代码 public class DemoServiceImpl implements DemoService { public String sayHello(String name) throws RemoteException { return "Hello " + name; } }

    上面这个类会被封装成为一个AbstractProxyInvoker实例,并新生成一个Exporter实例。这样当网络通讯层收到一个请求后,会找到对应的Exporter实例,并调用它所对应的AbstractProxyInvoker实例,从而真正调用了服务提供者的代码。

    Dubbo里还有一些其他的Invoker类,但上面两种是最重要的。

    1. ExtensionLoader的完整分析

    ExtensionLoader是Dubbo中一个非常重要的类,刚接触Dubbo源码的人看这个类的时候也多少会有点困惑,这个类非常重要,它就像是厨房里的“大厨”,按照用户的随时需要把各种“食材”烹调出来。

    我们结合具体代码详细说一下ExtensionLoader的实现,下面是ServiceConfig类里的一行代码:

    private static final Protocol protocol = ExtensionLoader.getExtensionLoader(Protocol.class).getAdaptiveExtension();

    上面代码的程序流程图如下所示(假定是第一次执行这行代码):

    在这个过程中最重要的两个方法是getExtensionClasses和createAdaptiveExtensionClass(图中红色部分),下面详细对这两个方法进行分析:

    #getExtensionClasses

    这个方法主要读取META-INF/services/目录下对应文件内容,在本示例代码中,是读取META-INF/services/com.alibaba.dubbo.rpc.Protocol文件中的内容,具体内容如下:

    com.alibaba.dubbo.registry.support.RegistryProtocol com.alibaba.dubbo.rpc.protocol.ProtocolFilterWrapper com.alibaba.dubbo.rpc.protocol.ProtocolListenerWrapper com.alibaba.dubbo.rpc.protocol.dubbo.DubboProtocol com.alibaba.dubbo.rpc.protocol.injvm.InjvmProtocol com.alibaba.dubbo.rpc.protocol.rmi.RmiProtocol com.alibaba.dubbo.rpc.protocol.hessian.HessianProtocol com.alibaba.dubbo.rpc.protocol.webservice.WebServiceProtocol

    它分析该文件中的每一行(每一行对应一个类),分析这些类,如果发现有哪个类的Annotation是@Adaptive,则找到对应的AdaptiveClass了,但由于Protocol文件里没有哪个类的Annotation是@Adaptive,所以在这个例子中该方法没找到对应的AdaptiveClass。

    #createAdaptiveExtensionClass

    该方法是在getExtensionClasses方法找不到AdaptiveClass的情况下被调用,该方法主要是通过字节码的方式在内存中新生成一个类,它具有AdaptiveClass的功能,Protocol就是通过这种方式获得AdaptiveClass类的。

    原文地址:http://blog.51cto.com/14028890/2322874

    时间: 2024-10-12 00:48:08

    Dubbo实现源码分析的相关文章

    dubbo客户端源码分析(一)

    rpc框架有很多,公司自研.开源的thrift.dubbo.grpc等.我用过几个框架,了解了一下实现原理,客户端基本都是用代理实现,jdk动态代理.cglib等.最近一段时间想了解一下dubbo源码,看下工作原理.今天看了一下客户端初始化源码 <?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans&q

    Dubbo源码分析系列-服务的发布

    RPC简化类图 RPC模块核心接口和抽象实现 默认实现Dubbo协议的接口和抽象实现 服务发布过程 调用过程 上图是服务提供者暴露服务的主过程: 首先ServiceConfig类拿到对外提供服务的实际类ref(如:HelloWorldImpl),然后通过ProxyFactory类的getInvoker方法使用ref生成一个AbstractProxyInvoker实例,到这一步就完成具体服务到Invoker的转化.接下来就是Invoker转换到Exporter的过程. Dubbo处理服务暴露的关键

    dubbo源码分析6-telnet方式的管理实现

    dubbo源码分析1-reference bean创建 dubbo源码分析2-reference bean发起服务方法调用 dubbo源码分析3-service bean的创建与发布 dubbo源码分析4-基于netty的dubbo协议的server dubbo源码分析5-dubbo的扩展点机制 dubbo提供了telnet的方式,直接用命令查看服务信息等.怎么实现的呢. 1. 编解码器 com.alibaba.dubbo.remoting.transport.netty.NettyCodecA

    Dubbo 源码分析 - 自适应拓展原理

    1.原理 我在上一篇文章中分析了 Dubbo 的 SPI 机制,Dubbo SPI 是 Dubbo 框架的核心.Dubbo 中的很多拓展都是通过 SPI 机制进行加载的,比如 Protocol.Cluster.LoadBalance 等.有时,有些拓展并非想在框架启动阶段被加载,而是希望在拓展方法被调用时,根据运行时参数进行加载.这听起来有些矛盾.拓展未被加载,那么拓展方法就无法被调用(静态方法除外).拓展方法未被调用,就无法进行加载,这似乎是个死结.不过好在也有相应的解决办法,通过代理模式就可

    Dubbo 源码分析 - 服务导出全过程解析

    1.服务导出过程 本篇文章,我们来研究一下 Dubbo 导出服务的过程.Dubbo 服务导出过程始于 Spring 容器发布刷新事件,Dubbo 在接收到事件后,会立即执行服务导出逻辑.整个逻辑大致可分为三个部分,第一是前置工作,主要用于检查参数,组装 URL.第二是导出服务,包含导出服务到本地 (JVM),和导出服务到远程两个过程.第三是向注册中心注册服务,用于服务发现.本篇文章将会对这三个部分代码进行详细的分析,在分析之前,我们先来了解一下服务的导出过程. Dubbo 支持两种服务导出方式,

    Dubbo 源码分析 - 集群容错之 Directory

    1. 简介 前面文章分析了服务的导出与引用过程,从本篇文章开始,我将开始分析 Dubbo 集群容错方面的源码.这部分源码包含四个部分,分别是服务目录 Directory.服务路由 Router.集群 Cluster 和负载均衡 LoadBalance.这几个部分的源码逻辑比较独立,我会分四篇文章进行分析.本篇文章作为集群容错的开篇文章,将和大家一起分析服务目录相关的源码.在进行深入分析之前,我们先来了解一下服务目录是什么.服务目录中存储了一些和服务提供者有关的信息,通过服务目录,服务消费者可获取

    Dubbo 源码分析 - 集群容错之 Router

    1. 简介 上一篇文章分析了集群容错的第一部分 – 服务目录 Directory.服务目录在刷新 Invoker 列表的过程中,会通过 Router 进行服务路由.上一篇文章关于服务路由相关逻辑没有细致分析,一笔带过了,本篇文章将对此进行详细的分析.首先,先来介绍一下服务目录是什么.服务路由包含一条路由规则,路由规则决定了服务消费者的调用目标,即规定了服务消费者可调用哪些服务提供者.Dubbo 目前提供了三种服务路由实现,分别为条件路由 ConditionRouter.脚本路由 ScriptRo

    Dubbo 源码分析 - 集群容错之 LoadBalance

    1.简介 LoadBalance 中文意思为负载均衡,它的职责是将网络请求,或者其他形式的负载"均摊"到不同的机器上.避免集群中部分服务器压力过大,而另一些服务器比较空闲的情况.通过负载均衡,可以让每台服务器获取到适合自己处理能力的负载.在为高负载的服务器分流的同时,还可以避免资源浪费,一举两得.负载均衡可分为软件负载均衡和硬件负载均衡.在我们日常开发中,一般很难接触到硬件负载均衡.但软件负载均衡还是能够接触到一些的,比如 Nginx.在 Dubbo 中,也有负载均衡的概念和相应的实现

    dubbo源码分析01:SPI机制

    一.什么是SPI SPI全称为Service Provider Interface,是一种服务发现机制,其本质是将接口实现类的全限定名配置在文件中,并由服务加载器读取配置文件.这样可以在运行时,动态为该接口替换实现类. JDK提供了默认的SPI实现,但是Dubbo并未使用JDK提供的SPI,而是自己封装了一套.我们先来通过Dubbo官网给的两个例子简单了解下JDK和Dubbo的SPI是如何使用的. 1.1.JDK SPI示例 首先定义一个接口以及它的两个实现类 1 public interfac