架构

RPC 通信

Dubbo3 的 Triple 协议构建在 HTTP/2 协议之上，因此具有更好的穿透性和通用性。Triple 协议与 gRPC 兼容，并提供请求响应、请求流、响应流和双向流等通信模型；从 Triple 协议开始，Dubbo 也支持基于 IDL 的服务定义。

此外，Dubbo 还集成了业界主流协议，允许用户在 Dubbo 框架内使用这些通信协议，为用户提供统一的编程模型和服务治理模型，这些协议包括 rest、hessian2、jsonrpc、thrift 等，需要注意的是，不同语言 SDK 实现支持的范围会存在一些差异。

详情请查看

服务发现

服务发现，即消费者自动发现服务地址列表的能力，是微服务框架需要具备的关键能力。借助自动服务发现，微服务可以在不知道对等方部署位置和 IP 地址的情况下实现通信。

实现服务发现的方式有很多，Dubbo 提供了基于客户端的服务发现机制。通常需要额外部署第三方注册中心组件来协调服务发现过程，例如常用的 [Nacos](https:/ /nacos.io/)、Consul、Zookeeper 等。Dubbo 本身也提供了与各种注册中心组件的连接，用户可以灵活选择。

Dubbo 基于消费者的自动服务发现能力，其基本工作原理如下

architecture

在传统的部署架构下，服务发现涉及三个参与角色：提供者、消费者和注册中心。其中，提供者将 URL 地址注册到注册中心，注册中心负责聚合数据，消费者从注册中心订阅 URL 地址并进行更新。在云原生环境下，例如当应用部署在 Kubernetes 等平台上时，由于平台本身维护着应用/服务与实例的映射关系，注册中心和注册动作在一定程度上沉淀到基础设施层，因此框架自身的注册动作有时并不必要。

Dubbo3 提供了一种新的应用级服务发现模型，该模型在设计和实现上与 Dubbo2 的接口级服务发现模型不同。可以在这里查看

  • [应用级服务发现](/en/docs3-v2/java-sdk/concepts-and-architecture/service-discovery/#Introduction to application-level service discovery)

流量管理

从 Dubbo2 开始，Dubbo 就提供了丰富的服务治理规则，包括路由规则、动态配置等。

一方面，Dubbo3 通过对接 xDS，连接到 Istio 等主流 Mesh 产品中使用的 VirtualService 和 DestinationRule 所代表的治理规则；另一方面，Dubbo 正在寻求设计一套自己的规则来实现流量治理，并提供灵活的治理能力。

Dubbo Mesh

Dubbo Mesh 的目标是提供一套适配 Dubbo 系统的完整 Mesh 解决方案，包括定制化的控制平面 (Control Plane) 和定制化的数据平面解决方案。Dubbo 控制平面基于业界主流的 Istio 扩展，支持更丰富的流量治理规则、Dubbo 应用级服务发现模型等。Dubbo 数据平面可以使用 Envoy Sidecar，实现 Dubbo SDK + Envoy 的部署方案，或者使用 Dubbo 无代理模式，直接实现 Dubbo 与控制平面的通信。Dubbo Mesh 正在快速演进，我们会尽力保持文档内容的更新。

mix-mesh

查看 Dubbo Mesh 设计详情

部署架构

本节重点描述 Dubbo 在传统模式下的部署架构。在云原生背景下的部署架构会发生变化，主要体现在基础设施 (Kubernetes、Service Mesh 等) 会承担更多责任，注册中心、元数据中心、配置中心等集中式组件的职责会整合，运维会变得更简单，但通过强调这些集中式组件，更容易让我们理解 Dubbo 的工作原理。

作为微服务框架，Dubbo sdk 与微服务组件一起部署在分布式集群的每个位置。为了实现分布式环境下各种微服务组件之间的协作，Dubbo 定义了一些集中式组件，包括

  • 注册中心。协调消费者和提供者之间的地址注册和发现
  • 配置中心。
    • 存储 Dubbo 启动阶段的全局配置，以确保配置的跨环境共享和全局一致性
    • 负责服务治理规则 (路由规则、动态配置等) 的存储和推送。
  • 元数据中心。
    • 接收提供者上报的服务接口元数据，并为 Admin 等控制台提供运维能力 (例如服务测试、接口文档等)
    • 作为服务发现机制的补充，提供额外的接口/方法级配置信息的同步能力，相当于注册中心的额外扩展

threecenters

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

以上三个中心并非运行 Dubbo 的必要条件，用户可以根据自身业务情况决定只启用其中一个或多个，以简化部署。通常，所有用户都会注册一个独立的启动 Dubbo 服务开发，配置中心和元数据中心会在微服务演进过程中根据需求逐步引入。

注册中心

注册中心扮演着非常重要的角色，它承担着服务注册和服务发现的职责。目前 Dubbo 支持以下两种粒度的服务发现和服务注册，即接口级和应用级，注册中心可以根据需求部署

  • 在传统的 Dubbo SDK 使用姿势中，如果只提供直接连接模式下的 RPC 服务，则不需要部署注册中心。

  • 无论接口级还是应用级，如果需要 Dubbo SDK 本身进行服务注册和服务发现，可以选择部署注册中心，并在 Dubbo 中集成相应的注册中心。

  • 在 Dubbo + Mesh 场景下，随着 Dubbo 服务注册能力的弱化，Dubbo 中的注册中心不再是必须，其职责开始被控制平面取代。如果采用 Dubbo + Mesh 部署方式，无论是 ThinSDK 的 Mesh 方式还是 Proxyless 的 Mesh 方式，都不再需要独立部署注册中心。

注册中心不依赖配置中心和元数据中心，如下图所示

centers-registry

图中没有部署配置中心和元数据中心。在 Dubbo 中，注册中心的实例默认会同时充当配置中心和元数据中心。这是 Dubbo 的默认行为。如果真的不需要配置中心或元数据中心的功能，可以在配置中关闭。注册中心的配置中有两个配置，分别是 use-as-config-center 和 use-as-metadata-center。只需将配置设置为 false 即可。

元数据中心

元数据中心在 2.7.x 版本中得到支持。随着 Dubbo 中应用级服务注册和服务发现的实现，元数据中心变得越来越重要。在以下情况下需要部署元数据中心

  1. 对于最初使用旧版 Dubbo 构建的应用程序服务，在迁移到 Dubbo 3 时，Dubbo 3 需要一个元数据中心来维护 RPC 服务和应用程序之间的映射关系（即接口和应用程序之间的映射关系），因为如果采用应用程序级服务发现和服务注册，并且注册中心将采用“应用程序-实例列表”结构的数据组织形式，这不再是以前“接口-实例列表”结构的数据组织形式。当使用接口级服务注册和服务发现的应用程序服务迁移到应用程序级别时，无法获取接口和应用程序之间的对应关系，从而无法从注册中心获取实例列表信息。因此，为了兼容这种情况，Dubbo 在 Provider 端启动时，会将接口和应用程序之间的映射关系存储在元数据中心。
  2. 为了让注册中心更多地专注于地址发现和推送能力，减轻注册中心的负担，元数据中心承载了所有服务元数据，大量接口/方法级别的配置信息等，无论接口粒度还是应用程序粒度服务发现和注册，元数据中心都发挥着重要作用。

如果您有上述两种需求，可以选择部署元数据中心，并通过 Dubbo 配置集成元数据中心。

元数据中心不依赖于注册中心和配置中心，用户可以自由选择是否集成和部署元数据中心，如下图所示

centers-metadata

图中没有配置中心，意味着可能不需要全局管理配置的能力。图中没有注册中心，意味着可能采用了 Dubbo mesh 解决方案，或者不需要服务注册，只在直连模式下接收服务调用。

配置中心

配置中心不同于其他两个中心，它与接口级别或应用程序级别无关，与接口没有对应关系，只与配置数据相关。即使没有部署注册中心和元数据中心，也可以直接访问配置中心。进入 Dubbo 应用程序服务。在整个部署架构中，整个集群中的实例（无论是 Provider 还是 Consumer）都将共享配置中心集群中的配置，如下图所示

centers-config

图中没有注册中心，意味着可能采用了 Dubbo mesh 解决方案，或者不需要服务注册，只在直连模式下接收服务调用。

图中没有元数据中心，意味着 Consumer 可以从 Provider 暴露的 MetadataService 获取服务元数据，从而实现 RPC 调用

保证三大中心的**高可用**部署架构

虽然三大中心对于 Dubbo 应用程序服务不再是必需的，但在实际生产环境中，一旦三大中心已经集成和部署，三大中心仍然会面临可用性问题。Dubbo 需要支持三大中心的**高可用**解决方案。Dubbo 支持多个注册中心、多个数据中心和多个配置中心，以满足同城多活、两地三中心、异地多活等部署架构模型的需求。

Dubbo SDK 支持三大中心的**多模式**。

  • 多个注册中心：Dubbo 支持多个注册中心，即一个接口或一个应用程序可以注册到多个注册中心，例如 ZK 集群和 Nacos 集群，消费者也可以从多个注册中心订阅服务地址信息进行服务发现。通过支持多个注册中心，确保当一个注册中心集群不可用时，可以切换到另一个注册中心集群，从而保证服务正常提供，服务调用可以正常发起。这也满足了注册中心在部署中适应各种高可用部署架构模式的需求。

  • 多个配置中心：Dubbo 支持多个配置中心，以确保当一个配置中心集群不可用时，可以切换到另一个配置中心集群，以确保全局配置、路由规则等信息可以正常从配置中心获取。这也满足了配置中心在部署中适应各种高可用部署架构模式的需求。

  • 多个数据中心：Dubbo 支持多个数据中心：用于处理灾难恢复等情况，当一个元数据中心集群不可用时，可以切换到另一个元数据中心集群，以确保元数据中心可以正常提供相关服务元素。数据管理能力。

以注册中心为例，下面是多活场景的部署架构示意图

multiple-registry-deployment-architecture


上次修改时间：2023 年 1 月 2 日：增强英文文档 (#1798) (95a9f4f6c1c)