Dubbo原理解析(非常透彻)

x33g5p2x  于2022-02-12 转载在 其他  
字(4.4k)|赞(0)|评价(0)|浏览(321)

一.概述

dubbo是一款经典的rpc框架,用来远程调用服务的。

dubbo的作用:

  • 面向接口的远程方法调用
  • 智能容错和负载均衡
  • 服务自动注册和发现。
  • 自定义序列化协议

Dubbo 架构中的核心角色有哪些?

  • Container**:** 服务运行容器,负责加载、运行服务提供者。必须。
  • Provider**:** 暴露服务的服务提供方,会向注册中心注册自己提供的服务。必须。
  • Consumer**:** 调用远程服务的服务消费方,会向注册中心订阅自己所需的服务。必须。
  • Registry**:** 服务注册与发现的注册中心。注册中心会返回服务提供者地址列表给消费者。非必须。
  • Monitor: 统计服务的调用次数和调用时间的监控中心。服务消费者和提供者会定时发送统计数据到监控中心。非必须。

Dubbo 中的 Invoker 概念了解么?

  • Invoker 是 Dubbo 领域模型中非常重要的一个概念,你如果阅读过 Dubbo 源码的话,你会无数次看到这玩意。就比如下面我要说的负载均衡这块的源码中就有大量 Invoker 的身影。

  • 简单来说,Invoker 就是 Dubbo 对远程调用的抽象。分为2种:

  • 服务提供 Invoker

  • 服务消费 Invoker

  • 我们需要调用一个远程方法,我们需要动态代理来屏蔽远程调用的细节吧!我们屏蔽掉的这些细节就依赖对应的 Invoker 实现, Invoker 实现了真正的远程服务调用

Dobbo的分层架构(工作原理)

  • Service业务层:就是我们写代码的层,我们使用rpc只需要关注该层就行,主要是定义接口和实现类。
  • config 配置层:Dubbo 相关的配置。支持代码配置,同时也支持基于 Spring 来做配置,以 ServiceConfigReferenceConfig 为中心
  • proxy 服务代理层:调用远程方法像调用本地的方法一样简单的一个关键,真实调用过程依赖代理类,以 ServiceProxy 为中心。
  • registry 注册中心层:封装服务地址的注册与发现。
  • cluster 路由层:封装多个提供者的路由及负载均衡,并桥接注册中心,以 Invoker 为中心。
  • monitor 监控层:RPC 调用次数和调用时间监控,以 Statistics 为中心。
  • protocol 远程调用层:封装 RPC 调用,以 InvocationResult 为中心。
  • exchange 信息交换层:封装请求响应模式,同步转异步,以 RequestResponse 为中心。
  • transport 网络传输层:抽象 mina 和 netty 为统一接口,以 Message 为中心。
  • serialize 数据序列化层 :对需要在网络传输的数据进行序列化。
    ** 二.SPI**

Dubbo 的 SPI 机制了解么?

  • SPI(Service Provider Interface) 机制被大量用在开源项目中(比如Dubbo,SpringBoot...),它可以帮助我们进行功能扩展。
  • SPI 的具体原理是这样的:我们将接口的实现类放在配置文件中,我们在程序运行过程中读取配置文件,通过反射加载实现类。这样,我们可以在运行的时候,动态替换接口的实现类。
  • 一些配置类就可以使用SPI进行加载,如果我们需要进行扩展,就自定义类放在指定文件夹下。
  • Java 本身就提供了 SPI 机制的实现。不过,Dubbo 没有直接用,而是对 Java 原生的 SPI 机制进行了增强,以便更好满足自己的需求。

为什么 Dubbo 不用 JDK 的 SPI,而是要自己实现?

  • 因为 Java SPI 在查找扩展实现类的时候遍历 SPI 的配置文件并且将实现类全部实例化,假设一个实现类初始化过程比较消耗资源且耗时,但是你的代码里面又用不上它,这就产生了资源的浪费。
  • 因此 Dubbo 就自己实现了一个 SPI,给每个实现类配了个名字,通过名字去文件里面找到对应的实现类全限定名然后加载实例化,按需加载。

如果想深入研究Java SPI:请看一位大佬写的文章:SPI源码分析

如何扩展 Dubbo 中的默认实现?

  •  比如说我们想要实现自己的负载均衡策略,我们创建对应的实现类 XxxLoadBalance 实现 LoadBalance 接口或者 AbstractLoadBalance 类。
  • 我们将这个是实现类的路径写入到resources 目录下的 META-INF/dubbo/org.apache.dubbo.rpc.cluster.LoadBalance文件中即可。
public class XxxLoadBalance implementsLoadBalance {
    public <T> Invoker<T> select(List<Invoker<T>> invokers, Invocation invocation) throwsRpcException {
        //...
}
}

** 三.Dubbo 的负载均衡策略**

  • RandomLoadBalance:随机。随机的选择一个。是Dubbo的默认负载均衡策略。(加权/不加权)
  • RoundRobinLoadBalance:轮询。轮询选择一个。(加权/不加权)
  • LeastActiveLoadBalance:最少活跃数。每个服务维护一个活跃数计数器。当A机器开始处理请求,该计数器加1,此时A还未处理完成。若处理完毕则计数器减1。而B机器接受到请求后很快处理完毕。那么A,B的活跃数分别是1,0。当又产生了一个新的请求,则选择B机器去执行(B活跃数最小),这样使慢的机器A收到少的请求。
  • ConsistentHashLoadBalance:一致性哈希。相同参数的请求总是落在同一台机器上。
    四.服务暴露,服务引用,服务调用过程

服务暴露**:生成代理类,**将信息注册到ZK

  • 组装URL:Spring IOC 容器刷新完毕之后,会根据配置参数组装成 URL, 然后根据 URL 的参数来进行代理类的生成。

  • 生成代理类:会通过 proxyFactory.getInvoker,利用 javassist 来进行动态代理,封装真的实现类。

  • 根据协议生成暴露对象(exporter):通过 URL 参数选择对应的协议来进行 protocol.export,默认是 Dubbo 协议。

  • 自适应:代理类会根据 Invoker 里面的 URL 参数得知具体的协议,然后通过 Dubbo SPI 机制选择对应的实现类进行 export。

  • 注册到ZK:将 export 得到的 exporter 存入一个 Map 中,供之后的远程调用查找,然后会向注册中心注册提供者的信息。

想要深究源码的小伙伴可以看一位大佬写的文章:服务暴露源码分析。

服务引用:获取远程调用的类,生成代理类。可以看作服务引用的逆过程。

  • 组装URL:会根据配置参数组装成 URL, 然后根据 URL 的参数来进行代理类的生成。(2种时机)

  • 饿汉式:饿汉式是通过实现 Spring 的InitializingBean接口中的 afterPropertiesSet方法,容器通过调用 ReferenceBean的 afterPropertiesSet方法时引入服务。(在Spring启动时,给所有的属性注入实现类,包含远程和本地的实现类)

  • 懒汉式:只有当这个服务被注入到其他类中时启动引入流程,也就是说用到了才会开始服务引入。

  • 在应用的Spring Context初始化完成事件时触发,扫描所有的Bean,将Bean中带有@Reference注解的field获取到,然后创建field类型的代理对象,创建完成后,将代理对象set给此field。后续就通过该代理对象创建服务端连接,并发起调用。(dubbo默认)

  • 从ZK中获取需要的服务提供者的信息:得到Map。

  • 根据协议解析传过来的exporter:

  • 协议的不同,获取的路径也不同:本地,直接,从ZK。

  • 生成代理类:供消费者使用Netty进行远程调用。invoker。

想要深究源码的小伙伴可以看一位大佬写的文章:服务引用源码分析。

服务调用:

  • 服务调用是在生成代理对象后,使用Netty,生成Netty Client进行远程调用。Netty Server通过反射返回调用结果。

  • 在调用之前,就会进行智能容错和负载均衡。

  • 首先客户端调用接口的某个方法,实际调用的是代理类,代理类会通过 cluster 从 directory(invoker的集合) 中获取一堆 invokers(如果有一堆的话),然后进行 router 的过滤(其中看配置也会添加 mockInvoker 用于服务降级),然后再通过 SPI 得到 loadBalance 进行一波负载均衡。

补充:cluster 是什么?

  • 一个中间层,为消费者屏蔽了服务提供者的情况,简化了消费者的使用。
  • 它可以负责选择哪个invoker返回给调用者,比如选择一个 invoker ,调用出错了可以换一个等等。

想要深究源码的小伙伴可以看一位大佬写的文章:服务调用源码分析。

容错机制:先容错,再负载均衡。

  • 首先在服务引入的时候,将多个远程调用都塞入 Directory 中,然后通过 Cluster 来封装这个目录,封装的同时提供各种容错功能,比如 FailOver、FailFast 等等,最终暴露给消费者的就是一个 invoker。
  • 然后消费者调用的时候会目录里面得到 invoker 列表,当然会经过路由的过滤,得到这些 invokers 之后再由 loadBalance 来进行负载均衡选择一个 invoker,最终发起调用。

dubbo常见的容错机制

  • Failover Cluster(默认)

  • 失败自动切换,当出现失败,重试其它服务器。

  • 通常用于读操作,但重试会带来更长延迟。

  • Failfast Cluster

  • 快速失败,只发起一次调用,失败立即报错。

  • 通常用于非幂等性的写操作,比如新增记录。

  • Failsafe Cluster

  • 失败安全,出现异常时,直接忽略。

  • 通常用于写入审计日志等操作。

  • Failback Cluster

  • 失败自动恢复,后台记录失败请求,定时重发。

  • 通常用于消息通知操作。

  • Forking Cluster

  • 并行调用多个服务器,只要一个成功即返回。

  • 通常用于实时性要求较高的读操作,但需要浪费更多服务资源。

想要深究源码的小伙伴可以看一位大佬写的文章:dubbo智能容错源码分析
五.其他小问题

Dubbo 为什么默认用 Javassist?

  • 很简单,就是快,且字节码生成方便。

  • 其他常见的动态代理: JDK 的动态代理、ASM、cglib。

  • ASM 比 Javassist 更快,但是没有快一个数量级,而Javassist 只需用字符串拼接就可以生成字节码,而 ASM 需要手工生成,成本较高,比较麻烦。

Dubbo 支持多种序列化方式?

  • JDK 自带的序列化:不支持跨语言调用 ;性能差
  • JSON:性能差
  • ProtoBuf :支持跨语言
  • hessian2(默认):支持跨语言
  • Protostuff:支持跨语言
  • Kryo:新引入的,只支持JAVA
  • FST:新引入的,只支持JAVA

寄语:你所看到的惊艳,都曾被平庸历练 

相关文章

微信公众号

最新文章

更多