Dubbo原理解析(非常透彻)

V2AS问路

Dubbo原理解析(非常透彻)

阅读原文时间：2023年07月11日阅读：1

一.概述

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 来做配置，以 ServiceConfig, ReferenceConfig 为中心
proxy 服务代理层：调用远程方法像调用本地的方法一样简单的一个关键，真实调用过程依赖代理类，以 ServiceProxy 为中心。
registry 注册中心层：封装服务地址的注册与发现。
cluster 路由层：封装多个提供者的路由及负载均衡，并桥接注册中心，以 Invoker 为中心。
monitor 监控层：RPC 调用次数和调用时间监控，以 Statistics 为中心。
protocol 远程调用层：封装 RPC 调用，以 Invocation, Result 为中心。
exchange 信息交换层：封装请求响应模式，同步转异步，以 Request, Response 为中心。
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 implements LoadBalance {
public Invoker select(List> invokers, Invocation invocation) throws RpcException {
// …
}
}

三.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常见的容错机制