Dubbo的架构设计

Dubbo的架构设计

文章目录

Dubbo的架构图Dubbo的部署架构图

注册中心元数据中心配置中心

Dubbo是阿里巴巴在2012年开源的分布式服务治理框架，不仅是阿里巴巴在开源领域最出名的项目，也应该算称得上是国内影响力最大的开源大作。
​

服务发现是Dubbo的重要特性之一，服务发现，即消费端自动发现服务地址列表的能力，是微服务框架需要具备的关键能力，借助于自动化的服务发现，微服务之间可以在无需感知对端部署位置与ip地址的情况下实现通信。

Dubbo基于消费端的自动服务发现能力，工作原理如Dubbo的架构图。

Dubbo的架构图

Dubbo中的五个基础组件，图中的紫色线条代表了组件初始化的路径（init），蓝色虚线是异步通知流程(async)，蓝色实线则是同步阻塞调用(sync)。

Registry：注册中心Provider：服务提供方Consumer：向Provider发起远程调用的消费者Monitor：监控中心，用来统计服务调用的频率和响应时间Container：运行服务的容器

服务发现的其中一个核心组件是注册中心，Provider 注册地址到注册中心，Consumer 从注册中心读取和订阅 Provider 地址列表。那我们具体来看一下RPC调用的具体过程：

0.start

服务容器启动后初始化服务提供者

1.register

服务提供者在启动的过程中，向注册中心发起注册，进行地址的注册

2.subscribe

服务消费者在启动的同时，向注册中心订阅所需的服务。采用的是Pub/Sub模式，也就是发布订阅模型

3.notify

注册中心将Provider地址列表发送给消费者，对于服务下线之类的变更，注册中心会主动推送变更数据到Consumer(建立在长连接之上)

4.invoke

服务消费者发起远程调用，这个过程会使用负载均衡算法挑选目标服务器

5.count

Consumer和Provider每隔一段时间将统计信息发送到监控中心，平时这些信息就暂存于内存当中。 Dubbo的部署架构图

上图完整的描述了 Dubbo 微服务组件与各个中心的交互过程。

注册中心。协调Consumer 与Provider之间的地址注册与发现配置中心

存储Dubbo启动阶段的全局配置，保证配置的跨环境共享与全局一致性负责服务治理规则（路由规则、动态配置等）的存储与推送。 元数据中心

接收Provider上报的服务接口元数据，为Admin等控制台提供运维能力（如服务测试、接口文档等）作为服务发现机制的补充，提供额外的接口、方法级别的配置信息的同步能力，相当于注册中心的额外扩展。 注册中心

服务注册和服务发现。dubbo支持两种粒度的服务发现和服务注册，分别是接口级别和应用级别。

在传统的Dubbo SDK使用姿势中，如果仅仅提供直连模式的RPC服务，不需要部署注册中心。无论是接口级别还是应用级别，如果需要Dubbo SDK自身来做服务注册和服务发现，则可以选择部署注册中心，在Dubbo中集成对应的注册中心。在Dubbo + Mesh 的场景下，随着 Dubbo 服务注册能力的弱化，Dubbo内的注册中心也不再是必选项，其职责开始被控制面取代，如果采用了Dubbo + Mesh的部署方式，无论是ThinSDK的mesh方式还是Proxyless的mesh方式，都不再需要独立部署注册中心。 元数据中心

对于一个原先采用老版本Dubbo搭建的应用服务，在迁移到Dubbo 3时，Dubbo 3 会需要一个元数据中心来维护RPC服务与应用的映射关系（即接口与应用的映射关系），因为如果采用了应用级别的服务发现和服务注册，在注册中心中将采用**“应用 —— 实例列表”结构**的数据组织形式，不再是以往的“接口 —— 实例列表”结构的数据组织形式，而以往用接口级别的服务注册和服务发现的应用服务在迁移到应用级别时，得不到接口与应用之间的对应关系，从而无法从注册中心得到实例列表信息，所以Dubbo为了兼容这种场景，在Provider端启动时，会往元数据中心存储接口与应用的映射关系。

为了让注册中心更加聚焦与地址的发现和推送能力，减轻注册中心的负担，元数据中心承载了所有的服务元数据、大量接口/方法级别配置信息等，无论是接口粒度还是应用粒度的服务发现和注册，元数据中心都起到了重要的作用。

配置中心

在整个部署架构中，整个集群内的实例（无论是Provider还是Consumer）都将会共享该配置中心集群中的配置。
​

在这篇文章中，我们了解了Dubbo的架构图和部署架构图，如果对您有所帮助，欢迎添加关注，成为粉丝哦。

感谢您的阅读，如果本篇博客对您有一定的帮助，大家记得留言+点赞+收藏哈。~~