Dubbo基础知识

我们公司目前还没怎么用分布式的架构，所以关于dubbo的相关知识都是通过我自学而来，然后分享给大家，同时记录给自己复习，如果有什么问题，请大家指正，谢谢。

首先我们先明白dubbo是啥？dubbo说白了，是一种RPC（远程调用）框架，其重点在于分布式的治理，就是本地进行接口调用，然后dubbo会代理这个调用请求，跟远程机器网络通信，给你处理负载均衡、服务实例上下线自动感知、超时重试等等问题的服务框架。

Dubbo核心功能

首先我们先来了解dubbo在分布式治理方面的三种核心功能：

1、Remoting：远程通讯，提供对多种NIO框架抽象封装，包括“同步转异步”和“请求-响应”模式的信息交换方式。

2、Cluster：服务框架，提供基于接口方法的透明远程过程调用，包括多协议支持，以及软负载均衡，失败容错，地址路由，动态配置等集群支持。

3、Registry： 服务注册中心，基于注册中心目录服务，使服务消费方能动态的查找服务提供方，使地址透明，使服务提供方可以平滑增加或减少机器。

Dubbo组件角色

其次我们再来了解dubbo的基本组件角色：

组件角色	说明
Provider	暴露服务的服务提供方
Consumer	调用远程服务的服务消费方
Registry	服务注册与发现的注册中心
Monitor	统计服务的调用次调和调用时间的监控中心
Container	服务运行容器

他们之间的调用关系说明如下：

服务容器（Container）：负责启动，加载，运行服务提供者。

服务提供者（Provider）：在启动时，向注册中心注册自己提供的服务。

服务消费者（Consumer）：在启动时，向注册中心订阅自己所需的服务。

注册中心（Registry）：返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。

服务消费者（Consumer）：从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。

服务消费者（Consumer）和提供者（Provider）：在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心Monitor。

Dubbo架构原理简析

然后我们简单的了解下dubbo的十层架构：

1、服务接口层（Service）：与实际业务逻辑相关的，根据服务提供方和服务消费方的业务设计对应的接口和实现。

2、配置层（Config）：对外配置接口，以ServiceConfig和ReferenceConfig为中心，可以直接new配置类，也可以通过Spring解析配置生成配置类。

3、服务代理层（Proxy）：服务接口透明代理，生成服务的客户端Stub和服务器端Skeleton，以ServiceProxy为中心，扩展接口为ProxyFactory。
4、服务注册层（Registry）：封装服务地址的注册与发现，以服务URL为中心，扩展接口为RegistryFactory、Registry和RegistryService。可能没有服务注册中心，此时服务提供方直接暴露服务。

5、集群层（Cluster）：封装多个提供者的路由及负载均衡，并桥接注册中心，以Invoker为中心，扩展接口为Cluster、Directory、Router和LoadBalance。将多个服务提供方组合为一个服务提供方，实现对服务消费方来透明，只需要与一个服务提供方进行交互。

6、监控层（Monitor）：RPC调用次数和调用时间监控，以Statistics为中心，扩展接口为MonitorFactory、Monitor和MonitorService。

7、远程调用层（Protocol）：封将RPC调用，以Invocation和Result为中心，扩展接口为Protocol、Invoker和Exporter。Protocol是服务域，它是Invoker暴露和引用的主功能入口，它负责Invoker的生命周期管理。Invoker是实体域，它是Dubbo的核心模型，其它模型都向它靠扰，或转换成它，它代表一个可执行体，可向它发起invoke调用，它有可能是一个本地的实现，也可能是一个远程的实现，也可能一个集群实现。

8、信息交换层（Exchange）：封装请求响应模式，同步转异步，以Request和Response为中心，扩展接口为Exchanger、ExchangeChannel、ExchangeClient和ExchangeServer。

9、网络传输层（Transport）：抽象mina和netty为统一接口，以Message为中心，扩展接口为Channel、Transporter、Client、Server和Codec。

10、数据序列化层（Serialize）：可复用的一些工具，扩展接口为Serialization、 ObjectInput、ObjectOutput和ThreadPool。

结构图如下所示：

根据官方提供的，对于上述各层之间关系的描述，如下所示

1、在RPC中，Protocol是核心层，也就是只要有Protocol + Invoker + Exporter就可以完成非透明的RPC调用，然后在Invoker的主过程上Filter拦截点。

2、Consumer和Provider是抽象概念，只是想让大家更直观的了解哪些类分属于客户端与服务器端，不用Client和Server的原因是Dubbo在很多场景下都使用Provider、Consumer、Registry、Monitor划分逻辑拓普节点，保持统一概念。

3、而Cluster是外围概念，所以Cluster的目的是将多个Invoker伪装成一个Invoker，这样其它人只要关注Protocol层Invoker即可，加上Cluster或者去掉Cluster对其它层都不会造成影响，因为只有一个提供者时，是不需要Cluster的。

4、Proxy层封装了所有接口的透明化代理，而在其它层都以Invoker为中心，只有到了暴露给用户使用时，才用Proxy将Invoker转成接口，或将接口实现转成Invoker，也就是去掉Proxy层RPC是可以Run的，只是不那么透明，不那么看起来像调本地服务一样调远程服务。

5、而Remoting实现是Dubbo协议的实现，如果你选择RMI协议，整个Remoting都不会用上，Remoting内部再划为Transport传输层和Exchange信息交换层，Transport层只负责单向消息传输，是对Mina、Netty、Grizzly的抽象，它也可以扩展UDP传输，而Exchange层是在传输层之上封装了Request-Response语义。

6、Registry和Monitor实际上不算一层，而是一个独立的节点。

Dubbo服务调用流程

最后我来简单的阐述下dubbo的服务调用大致是怎么样的：

1、先是启动dubbo，然后启动多个服务提供者（provider），提供者会在注册中心（Registry）注册自己提供的服务，同时dubbo将给每个提供者生成一个代理，监听网络请求。

2、消费者（Consumer）启动之后，消费者会去访问注册中心，并订阅自己所需的服务，然后注册中心将返回服务提供者地址列表给消费者，然后消费者会记录提供者的相关信息到本地。

3、当用户进行请求的时候，首先会访问消费者，在这之前dubbo会给每个消费者生成一个代理。

4、消费者会通过代理转发请求，然后通过dubbo提供的负载均衡将请求转发给提供者的代理，提供者的代理再转发给提供者进行处理。

5、提供者将请求处理之后的结果发给自己的代理，然后提供者的代理将结果转发给消费者的代理，消费者的代理再将结果返回给消费者，最后消费者将结果返回给用户。

dubbo架构与相关演示如下图所示：

附：注册中心挂了通信问题

这里再提一点，因为某些原因，当我们的注册中心挂了，消费者和提供者还可以互相通信吗？

答案是可以的，因为刚开始初始化的时候，消费者会将提供者的地址等信息拉取到本地缓存，所以注册中心挂了可以继续通信。

参考：

猿码道：https://juejin.im/post/5ab09943f265da238f125ee8

石杉码农学院推文