Dubbo——dubboX3.0原理概述

摘要

DubboX3.0框架设计概览,本博文将对dubbox3.0原理进行相关的梳理。

Dubbo模块简介

dubbo-registry——注册中心模块

官方文档的解释：基于注册中心下发地址的集群方式，以及对各种注册中心的抽象。dubboX3.0的注册中心实现有dns注册中心、kubernetes注册中心、multicast注册中心、multiple注册中心、nacos注册中心、xds注册中心、zookeeper注册中心，这个模块就是封装了dubbo所支持的注册中心的实现。

dubbo-registry-api：抽象了注册中心的注册和发现，实现了一些公用的方法，让子类只关注部分关键方法。 

以下几个包是分别是四种注册中心实现方法的封装，其中dubbo-registry-default就是官方文档里面的Simple注册中心

dubbo-cluster——集群模块

官方文档的解释：将多个服务提供方伪装为一个提供方，包括：负载均衡, 容错，路由等，集群的地址列表可以是静态配置的，也可以是由注册中心下发。

它就是一个解决出错情况采用的策略，这个模块里面封装了多种策略的实现方法，并且也支持自己扩展集群容错策略，cluster把多个Invoker伪装成一个Invoker，并且在伪装过程中加入了容错逻辑，失败了，重试下一个。

• configurator包：配置包，dubbo的基本设计原则是采用URL作为配置信息的统一格式，所有拓展点都通过传递URL携带配置信息，这个包就是用来根据统一的配置规则生成配置信息。
• directory包：Directory 代表了多个 Invoker，并且它的值会随着注册中心的服务变更推送而变化 。这里介绍一下Invoker，Invoker是Provider的一个调用Service的抽象，Invoker封装了Provider地址以及Service接口信息。
• loadbalance包：封装了负载均衡的实现，负责利用负载均衡算法从多个Invoker中选出具体的一个Invoker用于此次的调用，如果调用失败，则需要重新选择。
• merger包：封装了合并返回结果，分组聚合到方法，支持多种数据结构类型。
• router包：封装了路由规则的实现，路由规则决定了一次dubbo服务调用的目标服务器，路由规则分两种：条件路由规则和脚本路由规则，并且支持可拓展。
• support包：封装了各类Invoker和cluster，包括集群容错模式和分组聚合的cluster以及相关的Invoker。

dubbo-common——公共逻辑模块

这个应该很通俗易懂，工具类就是一些公用的方法，通用模型就是贯穿整个项目的统一格式的模型，比如URL，上述就提到了URL贯穿了整个项目。

dubbo-config——配置模块

是 Dubbo 对外的 API，用户通过 Config 使用Dubbo，隐藏 Dubbo 所有细节。用户都是使用配置来使用dubbo，dubbo也提供了四种配置方式，包括XML配置、属性配置、API配置、注解配置，配置模块就是实现了这四种配置的功能。

• dubbo-config-api：实现了API配置和属性配置的功能。
• dubbo-config-spring：实现了XML配置和注解配置的功能

dubbo-rpc——远程调用模块

抽象各种协议，以及动态代理，只包含一对一的调用，不关心集群的管理。远程调用，最主要的肯定是协议，dubbo提供了许许多多的协议实现，这个模块依赖于dubbo-remoting模块，抽象了各类的协议。

• dubbo-rpc-api：抽象了动态代理和各类协议，实现一对一的调用
• 另外的包都是各个协议的实现

dubbo-remoting——远程通信模块

相当于 Dubbo 协议的实现，如果 RPC 用 RMI协议则不需要使用此包。提供了多种客户端和服务端通信功能，比如基于Grizzly、Netty、Tomcat等等，RPC用除了RMI的协议都要用到此模块。

• dubbo-remoting-api：定义了客户端和服务端的接口。
• dubbo-remoting-http：基于Jetty或Tomcat实现的Client和Server。
• dubbo-remoting-netty：基于Netty3实现的Client和Server。
• Dubbo-remoting-netty4：基于Netty4实现的Client和Server。
• dubbo-remoting-zookeeper：封装了Zookeeper Client ，和 Zookeeper Server 通信。

dubbo-container——容器模块

是一个 Standlone 的容器，以简单的 Main加载 Spring 启动，因为服务通常不需要 Tomcat/JBoss 等 Web 容器的特性，没必要用 Web 容器去加载服务。因为后台服务不需要Tomcat/JBoss 等 Web 容器的功能，不需要用这些厚实的容器去加载服务提供方，既资源浪费，又增加复杂度。服务容器只是一个简单的Main方法，加载一些内置的容器，也支持扩展容器。

dubbo-monitor——监控模块

统计服务调用次数，调用时间的，调用链跟踪的服务。就是对服务的监控。

dubbo-filter——过滤器模块

这个模块提供了内置的一些过滤器。

dubbo-plugin——插件模块

该模块提供了内置的插件。

dubbo-serialization——序列化模块

该模块中封装了各类序列化框架的支持实现。

RPC简介

RPC，Remote Procedure Call 即远程过程调用，远程过程调用其实对标的是本地过程调用，相对于本地过程调用来说，就是你的自己的项目中的调用自己写的类和方法。

• 第一种方法利用远程调用就是你在你的项目中需要调用的你的同学的写的功能，但是不能拿到他的项目的情况的操作。那就只能通过网络将对象的项目的方法和对象传送到你的项目中，你才能调用到。
• 第二中方法前提是对象的项目中有相关的API接口给你调用。发送你的请求到到相关的AP接口。如果没有相关API接口是不允许调用的。

所以说 RPC 对标的是本地过程调用，至于 RPC 要如何调用远程的方法可以走 HTTP、也可以是基于 TCP 自定义协议。所以说你讨论 RPC 和 HTTP 就不是一个层级的东西。而 RPC 框架就是要实现像那小助手一样的东西，目的就是让我们使用远程调用像本地调用一样简单方便，并且解决一些远程调用会发生的一些问题，使用户用的无感知、舒心、放心、顺心，它好我也好，快乐没烦恼。

设计一个 RPC框架

服务消费者

• 我们先从消费者方(也就是调用方)来看需要些什么，首先消费者面向接口编程，所以需要得知有哪些接口可以调用，可以通过公用 jar 包的方式来维护接口。
• 现在知道有哪些接口可以调用了，但是只有接口啊，具体的实现怎么来？这事必须框架给处理了！所以还需要来个代理类，让消费者只管调，啥事都别管了，我代理帮你搞定。
• 对了，还需要告诉代理，你调用的是哪个方法，并且参数的值是什么。
• 虽说代理帮你搞定但是代理也需要知道它到底要调哪个机子上的远程方法，所以需要有个注册中心，这样调用方从注册中心可以知晓可以调用哪些服务提供方，一般而言提供方不止一个，毕竟只有一个挂了那不就没了。
• 所以提供方一般都是集群部署，那调用方需要通过负载均衡来选择一个调用，可以通过某些策略例如同机房优先调用啊啥的。
• 当然还需要有容错机制，毕竟这是远程调用，网络是不可靠的，所以可能需要重试什么的。
• 还要和服务提供方约定一个协议，例如我们就用 HTTP 来通信就好啦，也就是大家要讲一样的话，不然可能听不懂了。
• 当然序列化必不可少，毕竟我们本地的结构是“立体”的，需要序列化之后才能传输，因此还需要约定序列化格式。
• 并且这过程中间可能还需要掺入一些 Filter，来作一波统一的处理，例如调用计数啊等等。

这些都是框架需要做的，让消费者像在调用本地方法一样，无感知。

服务提供者

• 服务提供者肯定要实现对应的接口这是毋庸置疑的。
• 然后需要把自己的接口暴露出去，向注册中心注册自己，暴露自己所能提供的服务。
• 然后有消费者请求过来需要处理，提供者需要用和消费者协商好的协议来处理这个请求，然后做反序列化。
• 序列化完的请求应该扔到线程池里面做处理，某个线程接受到这个请求之后找到对应的实现调用，然后再将结果原路返回。

注册中心

• 我们都提到了注册中心，这东西就相当于一个平台，大家在上面暴露自己的服务，也在上面得知自己能调用哪些服务。
• 当然还能做配置中心，将配置集中化处理，动态变更通知订阅者

监控运维

• 面对众多的服务，精细化的监控和方便的运维必不可少。
• 这点很多开发者在开发的时候察觉不到，到你真正上线开始运行维护的时候，如果没有良好的监控措施，快速的运维手段，到时候就是睁眼瞎！

一个 RPC 框架需要做的就是约定要通信协议，序列化的格式、一些容错机制、负载均衡策略、监控运维和一个注册中心！

Dubbo 分层架构

总的而言 Dubbo 分为三层，如果每一层再细分下去，一共有十层。

分为大三层其实就是和我们知道的网络分层一样的意思，只有层次分明，职责边界清晰才能更好的扩展。而分 API 层和 SPI 层这是 Dubbo 成功的一点，采用微内核设计+SPI扩展，使得有特殊需求的接入方可以自定义扩展，做定制的二次开发。

Dubbo三层分别为 Business（业务层）、RPC 层、Remoting，并且还分为 API 层和 SPI 层。

Dubbo的每一层的功能介绍。

• Service，业务层，就是咱们开发的业务逻辑层。
• Config，配置层，主要围绕 ServiceConfig 和 ReferenceConfig，初始化配置信息。
• Proxy，代理层，服务提供者还是消费者都会生成一个代理类，使得服务接口透明化，代理层做远程调用和返回结果。
• Register，注册层，封装了服务注册和发现。
• Cluster，路由和集群容错层，负责选取具体调用的节点，处理特殊的调用要求和负责远程调用失败的容错措施。
• Monitor，监控层，负责监控统计调用时间和次数。
• Portocol，远程调用层，主要是封装 RPC 调用，主要负责管理 Invoker，Invoker代表一个抽象封装了的执行体，之后再做详解。
• Exchange，信息交换层，用来封装请求响应模型，同步转异步。
• Transport，网络传输层，抽象了网络传输的统一接口，这样用户想用 Netty 就用 Netty，想用 Mina 就用 Mina。
• Serialize，序列化层，将数据序列化成二进制流，当然也做反序列化。

Dubbo调用过程

服务注册原理

首先 Provider 启动，通过 Proxy 组件根据具体的协议 Protocol 将需要暴露出去的接口封装成 Invoker，Invoker 是 Dubbo 一个很核心的组件，代表一个可执行体。

然后再通过 Exporter 包装一下，这是为了在注册中心暴露自己套的一层，然后将 Exporter 通过 Registry 注册到注册中心。 这就是整体服务暴露过程。

服务消费原理

首先消费者启动会向注册中心拉取服务提供者的元信息，然后调用流程也是从 Proxy 开始，毕竟都需要代理才能无感知。

Proxy 持有一个 Invoker 对象，调用 invoke 之后需要通过 Cluster 先从 Directory 获取所有可调用的远程服务的 Invoker 列表，如果配置了某些路由规则，比如某个接口只能调用某个节点的那就再过滤一遍 Invoker 列表。

剩下的 Invoker 再通过 LoadBalance 做负载均衡选取一个。然后再经过 Filter 做一些统计什么的，再通过 Client 做数据传输，比如用 Netty 来传输。

传输需要经过 Codec 接口做协议构造，再序列化。最终发往对应的服务提供者。

服务提供者接收到之后也会进行 Codec 协议处理，然后反序列化后将请求扔到线程池处理。某个线程会根据请求找到对应的 Exporter ，而找到 Exporter 其实就是找到了 Invoker，但是还会有一层层 Filter，经过一层层过滤链之后最终调用实现类然后原路返回结果。

博文参考

《dubbo系列》-rpc、dubbo基础知识

框架设计 | Apache Dubbo

Dubbo 源代码分析 | Apache Dubbo

Dubbo 源代码分析 | Apache Dubbo

01 Dubbo 源码环境搭建：千里之行，始于足下.md

《Dubbo系列》-Dubbo常见面试题