注册中心、服务发现与负载均衡 on Apache Dubbo

注册中心概述

Mon, 01 Jan 0001 00:00:00 +0000

注册中心是 Dubbo 服务治理的核心组件，Dubbo 依赖注册中心的协调实现服务（地址）发现，自动化的服务发现是微服务实现动态扩缩容、负载均衡、、流量治理的基础。Dubbo 的服务发现机制经历了 Dubbo2 时代的接口级服务发现、Dubbo3 时代的应用级服务发现，具体可参见服务发现机制解析了解具体演进过程。

基本使用

开发应用时可以指定 Dubbo 注册中心（registry）组件，配置很简单，只需指定注册中心的集群地址即可：

以 Spring Boot 开发为例，在 application.yml 增加 registry 配置项目

dubbo
 registry
 address: {protocol}://{cluster-address}

其中，protocol 为选择的配置中心类型，cluster-address 为访问注册中心的集群地址，如

address: nacos://localhost:8848

如需集群格式地址可使用 backup 参数

address: nacos://localhost:8848?backup=localshot:8846,localshot:8847

流的语义保证

3.3.0 及之后的版本可不配置注册中心。而在 3.3.0 版本之前的 Dubbo 应用必须指定注册中心配置，即使不启用注册中心也要配置（可通过设置地址为空 address=‘N/A’ ）。

每个注册中心组件有自己特有的配置，可以用来控制命名空间、分组、鉴权等，具体可以参考 registry 配置参考手册或通过 parameters 参数进行扩展。

配置中心与元数据中心

配置中心、元数据中心是实现 Dubbo 高阶服务治理能力会依赖的组件，如流量管控规则等，相比于注册中心通常这两个组件的配置是可选的。

需要注意的是，对于部分注册中心类型（如 Zookeeper、Nacos 等），Dubbo 会默认同时将其用作元数据中心和配置中心（建议保持默认开启状态）。

dubbo
 registry
 address: nacos://localhost:8848

框架解析后的默认行为：

dubbo
 registry
 address: nacos://localhost:8848
 config-center
 address: nacos://localhost:8848
 metadata-report
 address: nacos://localhost:8848

如果您不想使用 nacos 作为配置中心，可以通过以下两个参数来调整或控制默认行为：

使用 Zookeeper 作为注册中心实现自动服务发现

Mon, 01 Jan 0001 00:00:00 +0000

本示例演示 Zookeeper 作为注册中心实现自动服务发现，示例基于 Spring Boot 应用展开，可在此查看完整示例代码

1 基本配置

1.1 增加 Maven 依赖

添加 dubbo、zookeeper 等依赖。dubbo-spring-boot-starter 将自动为应用增加 Zookeeper 相关客户端的依赖，减少用户使用 Zookeeper 成本，如使用中遇到版本兼容问题，用户也可以选择自行添加 Curator、Zookeeper Client 等依赖。

对于 Spring Boot 应用而言，可使用如下依赖：

<dependency>
 <groupId>org.apache.dubbo</groupId>
 <artifactId>dubbo-spring-boot-starter</artifactId>
 <version>${dubbo.version}</version>
</dependency>
<!-- 推荐 Zookeeper Server 3.8.0+ 版本 -->
<dependency>
 <groupId>org.apache.dubbo</groupId>
 <artifactId>dubbo-zookeeper-curator5-spring-boot-starter</artifactId>
 <version>${dubbo.version}</version>
</dependency>
<!-- 仅当 Zookeeper Server 版本是 3.4.x 及以下时，使用此依赖
<dependency>
 <groupId>org.apache.dubbo</groupId>
 <artifactId>dubbo-zookeeper-spring-boot-starter</artifactId>
 <version>${dubbo.version}</version>
</dependency>
-->

其中，dubbo-zookeeper-spring-boot-starter 或 dubbo-zookeeper-curator5-spring-boot-starter 负责管理 zookeeper 相关依赖。

注意

如果您不使用 Spring Boot，也可以使用以下方式管理依赖

使用 Nacos 作为注册中心实现自动服务发现

Mon, 01 Jan 0001 00:00:00 +0000

本示例演示 Nacos 作为注册中心实现自动服务发现，示例基于 Spring Boot 应用展开，可在此查看完整示例代码

1 基本配置

1.1 增加依赖

对于 Spring Boot 应用，可以使用如下 spring-boot-starter：

<dependency>
 <groupId>org.apache.dubbo</groupId>
 <artifactId>dubbo-spring-boot-starter</artifactId>
 <version>3.3.0</version>
</dependency>
<dependency>
 <groupId>org.apache.dubbo</groupId>
 <artifactId>dubbo-nacos-spring-boot-starter</artifactId>
 <version>3.3.0</version>
</dependency>

非 Spring Boot 用户，可以自行增加 dubbo、nacos-client 依赖：

<dependencies>
 <dependency>
 <groupId>org.apache.dubbo</groupId>
 <artifactId>dubbo</artifactId>
 <version>3.3.0</version>
 </dependency>
 <dependency>
 <groupId>com.alibaba.nacos</groupId>
 <artifactId>nacos-client</artifactId>
 <version>2.1.0</version>
 </dependency>
</dependencies>

1.2 Nacos 版本

Nacos 版本映射关系：

Dubbo	推荐 Nacos 版本	Nacos 兼容范围
3.3.0	2.3.0	2.x
3.2.21	2.1.0	2.x
3.1.11	2.0.9	2.x
3.0.10	2.0.9	2.x
2.7.21	1.x最新版本	1.x
2.6.0	1.x最新版本	1.x

1.3 配置并启用 Nacos

# application.yml (Spring Boot)
dubbo
 registry
 address: nacos://localhost:8848

或

多注册中心

Mon, 01 Jan 0001 00:00:00 +0000

1 关联服务与多注册中心

1.1 全局默认注册中心

Dubbo 注册中心和服务是独立配置的，通常开发者不用设置服务和注册中心组件之间的关联关系，Dubbo 框架会将自动执行以下动作：

对于所有的 Service 服务，向所有全局默认注册中心注册服务地址。
对于所有的 Reference 服务，从所有全局默认注册中心订阅服务地址。

# application.yml (Spring Boot)
dubbo
 registries
 beijingRegistry
 address: zookeeper://localhost:2181
 shanghaiRegistry
 address: zookeeper://localhost:2182

@DubboService
public class DemoServiceImpl implements DemoService {}

@DubboService
public class HelloServiceImpl implements HelloService {}

以上以 Spring Boot 开发为例（XML、API 方式类似）配置了两个全局默认注册中心 beijingRegistry 和 shanghaiRegistry，服务 DemoService 与 HelloService 会分别注册到两个默认注册中心。

除了上面讲到的框架自动为服务设置全局注册中心之外，有两种方式可以灵活调整服务与多注册中心间的关联。

1.2 设置全局默认注册中心

# application.yml (Spring Boot)
dubbo
 registries
 beijingRegistry
 address: zookeeper://localhost:2181
 default: true
 shanghaiRegistry
 address: zookeeper://localhost:2182
 default: false

default 用来设置全局默认注册中心，默认值为 true 即被视作全局注册中心。未指定注册中心 id 的服务将自动注册或订阅全局默认注册中心。

应用级服务发现 vs 接口级服务发现

Mon, 01 Jan 0001 00:00:00 +0000

Dubbo3 目前支持接口级的服务发现

应用级服务发现

设计目标

显著降低服务发现过程的资源消耗，包括提升注册中心容量上限、降低消费端地址解析资源占用等，使得 Dubbo3 框架能够支持更大规模集群的服务治理，实现无限水平扩容。
适配底层基础设施服务发现模型，如 Kubernetes、Service Mesh 等。

对比接口级

我们从 Dubbo 最经典的工作原理图说起，Dubbo 从设计之初就内置了服务地址发现的能力，Provider 注册地址到注册中心，Consumer 通过订阅实时获取注册中心的地址更新，在收到地址列表后，consumer 基于特定的负载均衡策略发起对 provider 的 RPC 调用。

在这个过程中：

每个 Provider 通过特定的 key 向注册中心注册本机可访问地址；
注册中心通过这个 key 对 provider 实例地址进行聚合；
Consumer 通过同样的 key 从注册中心订阅，以便及时收到聚合后的地址列表；

这里，我们对接口级地址发现的内部数据结构进行详细分析。

首先，看右下角 provider 实例内部的数据与行为。Provider 部署的应用中通常会有多个 Service，也就是 Dubbo2 中的服务，每个 service 都可能会有其独有的配置，我们所讲的 service 服务发布的过程，其实就是基于这个服务配置生成地址 URL 的过程，生成的地址数据如图所示；同样的，其他服务也都会生成地址。

然后，看一下注册中心的地址数据存储结构，注册中心以 service 服务名为数据划分依据，将一个服务下的所有地址数据都作为子节点进行聚合，子节点的内容就是实际可访问的ip地址，也就是我们 Dubbo 中 URL，格式就是刚才 provider 实例生成的。

这里把 URL 地址数据划分成了几份：

首先是实例可访问地址，主要信息包含 ip port，是消费端将基于这条数据生成 tcp 网络链接，作为后续 RPC 数据的传输载体
其次是 RPC 元数据，元数据用于定义和描述一次 RPC 请求，一方面表明这条地址数据是与某条具体的 RPC 服务有关的，它的版本号、分组以及方法相关信息，另一方面表明
下一部分是 RPC 配置数据，部分配置用于控制 RPC 调用的行为，还有一部分配置用于同步 Provider 进程实例的状态，典型的如超时时间、数据编码的序列化方式等。
最后一部分是自定义的元数据，这部分内容区别于以上框架预定义的各项配置，给了用户更大的灵活性，用户可任意扩展并添加自定义元数据，以进一步丰富实例状态。

结合以上两页对于 Dubbo2 接口级地址模型的分析，以及最开始的 Dubbo 基本原理图，我们可以得出这么几条结论：