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

服务发现的工作方式、基本使用方法与配置细节

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

Dubbo 支持基于注册中心的自动实例发现机制，即 Dubbo 提供者注册实例地址到注册中心，Dubbo 消费者通过订阅注册中心变更事件自动获取最新实例变化，从而确保流量始终转发到正确的节点之上。Dubbo 目前支持 Nacos、Zookeeper、Kubernetes Service 等多种注册中心接入。

注册中心

以下是 Dubbo 服务发现接入的一些主流注册中心实现，更多扩展实现与工作原理请查看注册中心参考手册：

注册中心	配置值	服务发现模型	是否支持鉴权	spring-boot-starter
Nacos	nacos	应用级、接口级	是	dubbo-nacos-spring-boot-starter
Zookeeper	zookeeper	应用级、接口级	是	- dubbo-zookeeper-spring-boot-starter - dubbo-zookeeper-curator5-spring-boot-starter
Kubernetes Service	参考独立使用文档	应用级	是	无

延迟注册

如果你的服务需要预热时间，比如初始化缓存、等待相关资源就位等，可以使用 delay 参数进行延迟注册。如果是在 Spring 应用中，则 delay = n(n > 0) 延迟的时间是 Spring 上下文初始化完成后开始算起。

@DubboService(delay = 5000)
public class DemoServiceImpl implements DemoService {
}

以上配置后，应用将延迟 5 秒暴露此服务（应用启动 5s 后发布该服务到注册中心）。或者可以配置全局默认值，让所有服务都延迟 5s 后注册：

dubbo:
 provider:
 delay: 5000

手动注册

通过配置 delay = -1，可以禁止框架自动发布服务到注册中心，直到用户通过调用 online 等命令手动完成发布，可以用这个特性配合部署系统实现服务的优雅上线，让用户对上线时机有更好的控制。具体配置如下：

负载均衡策略与配置细节

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

Dubbo 内置了 client-based 负载均衡机制，如下是当前支持的负载均衡算法，结合上文提到的自动服务发现机制，消费端会自动使用 Weighted Random LoadBalance 加权随机负载均衡策略 选址调用。

如果要调整负载均衡算法，以下是 Dubbo 框架内置的负载均衡策略：

算法	特性	备注	配置值
Weighted Random LoadBalance	加权随机	默认算法，默认权重相同	random (默认)
RoundRobin LoadBalance	加权轮询	借鉴于 Nginx 的平滑加权轮询算法，默认权重相同	roundrobin
LeastActive LoadBalance	最少活跃优先 + 加权随机	背后是能者多劳的思想	leastactive
Shortest-Response LoadBalance	最短响应优先 + 加权随机	更加关注响应速度	shortestresponse
ConsistentHash LoadBalance	一致性哈希	确定的入参，确定的提供者，适用于有状态请求	consistenthash
P2C LoadBalance	Power of Two Choice	随机选择两个节点后，继续选择“连接数”较小的那个节点。	p2c
Adaptive LoadBalance	自适应负载均衡	在 P2C 算法基础上，选择二者中 load 最小的那个节点	adaptive

全局配置

Dubbo 框架的默认策略是 random 加权随机负载均衡。如果要调整策略，只需要设置 loadbalance 相应取值即可，每种负载均衡策略取值请参见文档最上方表格。

使用 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>3.3.0</version>
</dependency>
<!-- 仅当 Zookeeper Server 版本是 3.4.x 及以下时，使用此依赖 -->
<dependency>
 <groupId>org.apache.dubbo</groupId>
 <artifactId>dubbo-zookeeper-spring-boot-starter</artifactId>
 <version>3.3.0</version>
</dependency>
<!-- 仅当 Zookeeper Server 版本是 3.5.x 及以上时，使用此依赖
<dependency>
 <groupId>org.apache.dubbo</groupId>
 <artifactId>dubbo-zookeeper-curator5-spring-boot-starter</artifactId>
 <version>3.3.0</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 增加依赖

增加 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>

对于 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>

1.2 Nacos 版本

Nacos 版本映射关系：

Dubbo	推荐 Nacos 版本	Nacos 兼容范围
3.3.0	2.2.3	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
 register-mode: instance # 新用户请设置此值，表示启用应用级服务发现，可选值 interface、instance、all，默认值为 all，未来版本将切换默认值为 instance

或

基于 Kubernetes Service 的服务发现

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

上面两节我们分别讲解了 Nacos、Zookeeper 两种注册中心模式，它们更像是传统的注册中心解决方案。在 Kubernetes 部署环境下，Dubbo 支持基于 Kubernetes Service 的服务发现模式，其基本工作原理如下图所示：

在这种模式下，服务发现与用户的部署运维操作形成统一，用户定义标准的 Kubernetes Service、Deployment，并将其部署到 Kubernetes，之后 Control Plane 通过监控 APISERVER 资源并与 SDK 进程联动，形成一整套的服务发现体系。

关于使用 Kubernetes 作为注册中心的具体实践案例，请参考 Kubernetes Service 部署 一节了解更多细节。