引言

作为分布式服务框架的标杆，Dubbo凭借其高性能RPC通信、灵活的服务治理能力和丰富的容错机制，成为Java技术栈中微服务领域的核心考点。本文系统梳理Dubbo高频面试核心知识点，涵盖容错策略、负载均衡、注册中心原理、服务上下线感知等关键技术细节，助您深入理解Dubbo设计思想，从容应对分布式服务架构面试挑战。无论是服务注册发现流程，还是ZooKeeper节点监听机制，这里提供清晰的技术脉络与场景化解析。

Dubbo 容错策略（调用失败处理方式）

1. 默认额外重试2次。
2. 只请求一次，失败直接抛异常。
3. 只请求一次，失败吞掉异常 不做任何处理。
4. 记录失败请求，后台定时任务进行重发。
5. 广播给服务提供者集群 ，只要有一个节点返回，则成功。
6. 逐个调用服务提供者集群，只要有一个节点失败，则失败。

Dubbo 核心功能

1. 面向接口的高性能RPC调用。
2. 服务自动注册和发现。
3. 负载均衡策略。
4. 多样的容错策略。
5. 可视化服务治理和运维。

Dubbo 负载均衡策略

1. 随机
2. 轮询
3. 加权随机
4. 加权轮询
5. 一致性hash
6. 最小活跃数：当一个新的请求到达时，负载均衡器会检查所有可用服务实例的活跃请求数，并选择活跃请求数最少的实例来处理该请求。如果有多个服务实例的活跃请求数相同且都是最少的，负载均衡器会在这些实例中随机选择一个来处理请求，以避免所有请求都集中到某一个实例上。

Dubbo 工作流程

1. 服务启动后，provider和consumer根据配置信息，连接到注册中心，分别进行服务注册和服务订阅。
2. 注册中心根据订阅关系，将provider信息发送给consumer，consumer会将provider信息缓存再本地。如果信息有变化，consumer会收到注册中心的消息推送。
3. 服务调用时，consumer会生成代理对象，根据负载均衡策略，选择一台provider进行接口调用，同时定时向monitor发送接口调用次数以及耗时。
4. provider收到请求后对数据进行反序列化，通过代理对象调用具体接口。

Dubbo 如何感知服务下线？

1. Dubbo通过ZK来实现服务注册和发现，通过ZK来维护提供者和消费者的地址。
2. /dubbo/services/providers和/dubbo/services/consumers节点维护提供者和消费者地址。
3. ZK通过心跳检测机制（客户端主动定期向ZooKeeper服务器发送心跳消息，也称为Ping请求），判断Dubbo的服务提供者的运行状态，来决定是否从服务列表中移除，当出现故障时ZK会剔除这个服务地址。
4. Dubbo的服务消费端通过Watch机制来对/providers节点进行监控，一旦节点下的子节点发生变化，ZK就会发送事件通知Dubbo的服务消费端，消费端收到后会将变更本地缓存的服务地址。

Dubbo 注册中心Zookeeper结构

/dubbo└── com.example.DemoService├── providers├── consumers├── configurators└── routers

1. /dubbo/com.example.DemoService：这个节点是具体的服务接口节点，以服务接口的全限定类名命名。每个服务对应一个这样的节点。
2. /dubbo/com.example.DemoService/providers：这个节点下存储的是所有提供该服务的提供者信息。节点的内容通常是 URL 格式，包含服务提供者的 IP、端口、协议、版本、方法等信息。
3. /dubbo/com.example.DemoService/consumers：这个节点下存储的是所有订阅了该服务的消费者信息。节点内容也是 URL 格式，包含消费者的 IP、端口、应用名、版本、时间戳等信息。

---

感谢您的阅读！如果文章中有任何问题或不足之处，欢迎及时指出，您的反馈将帮助我不断改进与完善。期待与您共同探讨技术，共同进步！