引言
作为分布式服务框架的标杆，Dubbo凭借其高性能RPC通信、灵活的服务治理能力和丰富的容错机制，成为Java技术栈中微服务领域的核心考点。本文系统梳理Dubbo高频面试核心知识点，涵盖容错策略、负载均衡、注册中心原理、服务上下线感知等关键技术细节，助您深入理解Dubbo设计思想，从容应对分布式服务架构面试挑战。无论是服务注册发现流程，还是ZooKeeper节点监听机制，这里提供清晰的技术脉络与场景化解析。
Dubbo 容错策略（调用失败处理方式）
- 默认额外重试2次。
- 只请求一次，失败直接抛异常。
- 只请求一次，失败吞掉异常 不做任何处理。
- 记录失败请求，后台定时任务进行重发。
- 广播给服务提供者集群 ，只要有一个节点返回，则成功。
- 逐个调用服务提供者集群，只要有一个节点失败，则失败。
Dubbo 核心功能
- 面向接口的高性能RPC调用。
- 服务自动注册和发现。
- 负载均衡策略。
- 多样的容错策略。
- 可视化服务治理和运维。
Dubbo 负载均衡策略
- 随机
- 轮询
- 加权随机
- 加权轮询
- 一致性hash
- 最小活跃数：当一个新的请求到达时，负载均衡器会检查所有可用服务实例的活跃请求数，并选择活跃请求数最少的实例来处理该请求。如果有多个服务实例的活跃请求数相同且都是最少的，负载均衡器会在这些实例中随机选择一个来处理请求，以避免所有请求都集中到某一个实例上。
Dubbo 工作流程
- 服务启动后，provider和consumer根据配置信息，连接到注册中心，分别进行服务注册和服务订阅。
- 注册中心根据订阅关系，将provider信息发送给consumer，consumer会将provider信息缓存再本地。如果信息有变化，consumer会收到注册中心的消息推送。
- 服务调用时，consumer会生成代理对象，根据负载均衡策略，选择一台provider进行接口调用，同时定时向monitor发送接口调用次数以及耗时。
- provider收到请求后对数据进行反序列化，通过代理对象调用具体接口。
Dubbo 如何感知服务下线？
- Dubbo通过ZK来实现服务注册和发现，通过ZK来维护提供者和消费者的地址。
- /dubbo/services/providers和/dubbo/services/consumers节点维护提供者和消费者地址。
- ZK通过心跳检测机制（客户端主动定期向ZooKeeper服务器发送心跳消息，也称为Ping请求），判断Dubbo的服务提供者的运行状态，来决定是否从服务列表中移除，当出现故障时ZK会剔除这个服务地址。
- Dubbo的服务消费端通过Watch机制来对/providers节点进行监控，一旦节点下的子节点发生变化，ZK就会发送事件通知Dubbo的服务消费端，消费端收到后会将变更本地缓存的服务地址。
Dubbo 注册中心Zookeeper结构
/dubbo
└── com.example.DemoService
├── providers
├── consumers
├── configurators
└── routers- /dubbo/com.example.DemoService：这个节点是具体的服务接口节点，以服务接口的全限定类名命名。每个服务对应一个这样的节点。
- /dubbo/com.example.DemoService/providers：这个节点下存储的是所有提供该服务的提供者信息。节点的内容通常是 URL 格式，包含服务提供者的 IP、端口、协议、版本、方法等信息。
- /dubbo/com.example.DemoService/consumers：这个节点下存储的是所有订阅了该服务的消费者信息。节点内容也是 URL 格式，包含消费者的 IP、端口、应用名、版本、时间戳等信息。
感谢您的阅读！如果文章中有任何问题或不足之处，欢迎及时指出，您的反馈将帮助我不断改进与完善。期待与您共同探讨技术，共同进步！
