dubbo微服务两地三中心 dubbo微服务架构图

转载

mob64ca14092155 2024-03-18 13:30:46

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

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

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

Dubbo的架构图

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

dubbo微服务两地三中心 dubbo微服务架构图_dubbo微服务两地三中心

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

0.start

1.register

2.subscribe

3.notify

4.invoke

5.count

dubbo微服务两地三中心 dubbo微服务架构图_ide_02

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

服务注册和服务发现。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端启动时，会往元数据中心存储接口与应用的映射关系。
为了让注册中心更加聚焦与地址的发现和推送能力，减轻注册中心的负担，元数据中心承载了所有的服务元数据、大量接口/方法级别配置信息等，无论是接口粒度还是应用粒度的服务发现和注册，元数据中心都起到了重要的作用。