Dubbo（二）：注册中心、负载均衡、集群容错与 SPI 扩展
导语：Dubbo 面试真正的主战场在这里——注册中心、负载均衡、集群容错、SPI 四件套几乎是逢面必考，而且很容易问到源码级深度。本篇把 5 种负载均衡（含一致性哈希虚拟节点）、6 种集群容错（含"重试放大流量"的坑）、Dubbo SPI 为何优于 Java SPI（含 Adaptive / Wrapper / Activate 三要素）、协议选型与报文结构，以及超时重试的配置优先级与服务降级一次讲透，并补上 Dubbo 3 的关键变化，共 7 题。
一、注册中心
1. Dubbo 支持哪些注册中心？Zookeeper 和 Nacos 怎么选？注册中心挂了还能调用吗？
答：
① 支持的注册中心
Dubbo 通过 SPI 插件化支持多种注册中心：Nacos、Zookeeper、Redis、Multicast（广播，仅本地测试）、etcd、Consul（Dubbo 3 还强化了 Kubernetes 原生服务发现——直接用 K8s API Server 作为注册中心）。
⚠️ 一个常见误区：很多人认为 Dubbo 深度绑定 Zookeeper。不是的。Dubbo 3 官方推荐的是 Nacos，新项目基本都用 Nacos 了。
② Zookeeper vs Nacos 选型（高频对比题）
| 维度 | Zookeeper | Nacos |
|---|---|---|
| CAP 取向 | CP（ZAB 协议，保证一致性与分区容错） | 默认 AP + 支持切换 CP（临时实例走 AP/ distro 协议，持久化实例走 CP/Raft） |
| 健康检查 | 临时节点 + session 心跳：断连即删除节点 | 临时实例心跳（默认 5s，15s 不健康、30s 剔除） |
| 变更推送 | Watch 机制（事件通知，实时性好） | UDP 推送 + 定时拉取（1.x）；2.x 起走 gRPC 长连接双向流 |
| 一致性保证 | 强一致 | AP 模式下短暂不一致可接受（更符合服务发现场景） |
| 配套能力 | 只有注册发现 | 注册中心 + 配置中心一体化（动态配置/灰度全靠它） |
| 运维体验 | 需自行搭建 + 无控制台（依赖第三方） | 自带 Web 控制台，权重、上下线、元数据可视化操作 |
| 选型建议 | 对强一致有硬要求、或者已有 ZK 集群（如同时用 Kafka） | ✅ 绝大多数微服务项目的首选 |
面试加分句：服务发现这个场景，"可用性"比"强一致"更重要——注册中心短暂返回旧一点的地址列表，Consumer 侧的容错机制会兜住；但注册中心如果为了保一致性而不可用，整个微服务的扩容/上线都会卡住。这就是为什么 Nacos 用 AP 作为默认模式。
③ 注册中心挂了，还能调用吗？（必问）
答：能，但有限制。
| 场景 | 结论 |
|---|---|
| 注册中心宕机，Consumer/Provider 已在运行 | ✅ 已有调用不受影响：Consumer 本地已缓存 Provider 地址列表，且 TCP 长连接也已建立，流量是直连的，不经过注册中心 |
| 注册中心宕机期间 Provider 下线/扩容 | ❌ 无法感知：Consumer 拿到的地址是旧的，对已下线的 Provider 调用会失败（靠容错机制 failover 换一台） |
| 注册中心宕机期间 Consumer 重启 | ⚠️ 走本地磁盘缓存（~/.dubbo/dubbo-registry-*.cache）恢复地址列表；若缓存也没有则启动失败（可通过 check=false 放宽启动校验） |
| 注册中心宕机期间新服务上线 | ❌ 无法注册，别人发现不了它 |
三个配套知识点：
| 知识点 | 说明 |
|---|---|
| 为什么 Consumer 要缓存地址 | 正是因为注册中心是"旁路设施"，流量永远直连，所以短暂的注册中心不可用不该影响业务 |
check=false | 启动时不检查依赖服务是否可用（<dubbo:consumer check="false"/>），避免"A 依赖 B、B 未启动导致 A 起不来"的循环启动问题 |
subscribe 失败会重试 | Dubbo 会不断重试连接注册中心，恢复后自动重新订阅并刷新地址 |
⚠️ 对比易混点：这是 Dubbo 与 HTTP + Nginx/网关 模型的根本差异——网关是流量转发必经之路，网关挂了全站不可用；而注册中心是旁路"地址簿"，挂了只是"暂时看不到变化"。
二、负载均衡
2. Dubbo 有哪些负载均衡策略？默认用的是哪个？
答： Dubbo 提供 4 种经典策略（Dubbo 3 起新增第 5 种），默认是 Random（加权随机）：
| 策略 | 类名/配置名 | 原理 | 适用场景 | 缺点 |
|---|---|---|---|---|
| Random（默认） | random | 按权重随机 select 一台；roundrobin/leastactive/consistenthash | 常规场景；能自然体现机器权重差异 | 极端情况下短时分布不均 |
| RoundRobin | roundrobin | 加权轮询（平滑加权轮询）；普通轮询有权重时会不均匀 | 希望请求绝对均匀地摊到每台机器 | 慢机器会堆积请求（一台机器慢，它的请求还是照发） |
| LeastActive | leastactive | 最少活跃调用数：统计每台机器正在处理的请求数，挑最少的；相同则按权重随机 | ✅ 解决慢机器堆积：某台机器响应变慢后活跃数上升，新请求自动少给它 | 需要维护活跃计数 |
| ConsistentHash | consistenthash | 一致性哈希：相同参数的请求总是打到同一台机器 | 有状态服务、需要会话保持/缓存亲和性的场景 | 机器数量变化时仍有少部分 key 会被重分布 |
| ShortestResponse（Dubbo 3 新增） | shortestresponse | 挑最近一段时间内平均响应时间最短的节点（相似的 Experiences 加权） | 对响应速度敏感、机器性能差距大的场景 | 需要滑动窗口统计，实现更复杂 |
一致性哈希的两个关键细节（高频追问）：
| 追问 | 答案 |
|---|---|
| 为什么需要虚拟节点？ | 只用真实节点会在 Hash 环上分布不均，导致流量倾斜。Dubbo 把每个真实节点虚拟成 N 个节点（默认 160 个，可通过 hash.nodes 配置）均匀散布在环上，负载分布几乎均衡 |
| 按什么 hash？ | 默认对第一个参数（hash.arguments=0）做 md5 hash。可通过 <dubbo:parameter key="hash.arguments" value="0,1"/> 指定参与 hash 的参数索引 |
| 节点故障时？ | 请求顺时针走到下一个节点，只影响该节点负责的那一段环，其余节点 key 的映射不变（这是与普通取模哈希的最大区别） |
面试加分句：负载均衡是在消费端本地执行的（客户端负载均衡），不是靠集中的 Load Balancer 转发——这也是 RPC 与"HTTP + Nginx"的核心区别之一。所以即便注册中心挂了，负载均衡依然能在本地生效。
三、集群容错
3. Dubbo 的集群容错策略有哪些？默认是什么？（超高频）
答： Dubbo 提供 6 种集群容错策略，默认是 Failover Cluster（失败自动切换）。
先说清楚位置：容错发生在 Cluster 层。
Cluster#join(directory)返回一个ClusterInvoker，它把「多个 Provider Invoker」伪装成一个 Invoker 暴露给上层；所有的容错、负载均衡、路由都藏在这层里面。
六种策略全表：
| 策略 | 行为 | 适用场景 | 默认参数 |
|---|---|---|---|
| Failover Cluster（✅ 默认） | 失败自动切换，尝试其他服务器 | 读操作 / 幂等写操作 | retries=2 |
| Failfast Cluster | 快速失败，只调用一次，失败立即报错 | 非幂等的写操作（如新增记录、下单） | 无 |
| Failsafe Cluster | 失败安全，直接忽略异常，返回空结果 | 不重要的旁路调用，如写审计日志、发监控 | 无 |
| Failback Cluster | 失败自动恢复，后台记录失败请求，定时重发 | 消息通知类，强调"最终发出去" | 默认重发 5 次，间隔递增 |
| Forking Cluster | 并行调用多台，只要一个成功就返回 | 实时性要求高的读操作 | forks=2 |
| Broadcast Cluster | 广播逐个调用全部 Provider，任一失败则整体失败 | 通知所有节点刷新本地资源（如缓存、配置） | 无 |
配置方式：
<!-- 消费端：query 用 Failover，create 用 Failfast -->
<dubbo:reference id="orderService" interface="com.xx.OrderService">
<dubbo:method name="queryOrder" cluster="failover" retries="2"/>
<dubbo:method name="createOrder" cluster="failfast"/>
</dubbo:reference>⚠️ 必须掌握的"送命题"：重试会放大流量
【场景】下游服务因为压力大开始超时 → Consumer Failover 自动重试 2 次
→ 实际请求量变成 3 倍 → 下游压力剧增、更容易超时 → 更多重试
→ 最终雪崩（这就是传说中的"重试风暴"）| 追问 | 标准回答 |
|---|---|
| 默认重试几次？ | retries=2，不含第一次，所以最多尝试 3 次 |
| 哪些操作必须关重试？ | ❌ 所有非幂等的写操作（创建订单、扣款、发消息）——必须设 retries=0 或改用 Failfast，否则会重复下单/重复扣款 |
| 如何防止重试风暴？ | ① 写操作 retries=0；② 接口幂等（唯一单号）；③ 上游熔断限流（Sentinel）；④ 下游调优、隔离 |
| Forking 有什么代价？ | 并行 fork 多台，资源消耗翻 N 倍，只适合少量关键读接口 |
四、SPI 扩展机制
4. Dubbo 的 SPI 机制是什么？和 Java SPI 有什么区别？（高频源码题）
答： SPI（Service Provider Interface）是插件化扩展机制：框架定义接口，第三方按约定写好实现并配置，框架运行时自动发现并加载，从而做到"不改源码、增加 jar 即可扩展"。Dubbo 的全部核心能力（协议、序列化、负载均衡、注册中心、过滤器）都是基于 SPI 实现的。
① 为什么 Dubbo 不用 Java 原生 SPI？
| 问题 | Java SPI（ServiceLoader） | Dubbo SPI（ExtensionLoader） |
|---|---|---|
| 加载方式 | ❌ 一次性实例化全部实现类（很多是用不上的，浪费） | ✅ 按 key 按需加载，用到哪个实例化哪个 |
| 获取方式 | ❌ 只能遍历全部实现再挑想要的 | ✅ 按名字精确获取：ExtensionLoader.getExtensionLoader(X.class).getExtension("random") |
| IOC 能力 | ❌ 无（创建对象时的依赖应由调用方自己处理） | ✅ setter 注入同类的其它扩展实现 |
| AOP 能力 | ❌ 无 | ✅ Wrapper 类自动织入，天然做链式增强（如 Protocol 的 Filter 包装） |
| 自适应 | ❌ 无（只能在代码里写死用哪个实现） | ✅ @Adaptive 生成自适应代理，运行时根据 URL 参数决定实现类 |
| 自动激活 | ❌ 无 | ✅ @Activate 按条件（分组/参数）自动激活一组扩展（如 Filter 链） |
| 异常处理 | ❌ 加载失败只抛 ServiceConfigurationError，难以定位 | ✅ 携带详细的扩展名、类路径、异常栈，易于排查 |
| 配置文件 | META-INF/services/接口全限定名 | META-INF/dubbo/internal/、META-INF/dubbo/、META-INF/services/ |
【一句话总结】
Java SPI 只是"加载实现类清单"，Dubbo SPI 才是完整的"微内核 + 插件体系"：
按需加载 + IOC + AOP + 自适应 + 自动激活② Dubbo SPI 的三要素（重点）
| 要素 | 作用 | 示例 |
|---|---|---|
@SPI | 标注这是一个可扩展接口，@SPI("dubbo") 指定默认实现名 | @SPI("random") public interface LoadBalance |
@Adaptive | 标注在接口上或方法上。Dubbo 会动态生成代理类（Xxx$Adaptive），运行时从 URL 参数里取出真正的实现名再委派 | Protocol$Adaptive#export 会从 URL 的 protocol 参数决定用 DubboProtocol 还是其它协议 |
| Wrapper（包装类） | 一个类的构造参数是该扩展点类型时会被识别为包装类（3.x 起推荐显式加 @Wrapper 注解），ExtensionLoader 会自动把目标实现包一层再返回 | ProtocolFilterWrapper、ProtocolListenerWrapper 就是靠它为 Protocol 织入 Filter 链 |
@Activate | 标注在 Filter 类上，group = {PROVIDER, CONSUMER}、order 指定排序、value 指定激活条件（URL 上存在某个 key 才激活） | @Activate(group = CONSUMER, order = -10000) → Consumer ActiveFilter |
③ 一个完整例子（30 秒就能说清）：
// 1. 定义扩展点接口，指定默认实现
@SPI("random")
public interface LoadBalance {
@Adaptive("loadbalance") // 从 URL 的 loadbalance 参数决定实现
<T> Invoker<T> select(List<Invoker<T>> invokers, URL url, Invocation invocation);
}# 2. 在 resources/META-INF/dubbo/com.alibaba.dubbo.rpc.cluster.LoadBalance 写好映射
random=RandomLoadBalance # 默认
roundrobin=RoundRobinLoadBalance
leastactive=LeastActiveLoadBalance
consistenthash=ConsistentHashLoadBalance// 3. 使用 ExtensionLoader 获取（按需实例化，且会被 Wrapper 包装）
LoadBalance lb = ExtensionLoader.getExtensionLoader(LoadBalance.class)
.getExtension("leastactive");
LoadBalance adaptive = ExtensionLoader.getExtensionLoader(LoadBalance.class)
.getAdaptiveExtension(); // 代理类，运行时读 URL④ 面试常见追问
| 追问 | 答案 |
|---|---|
| SPI 实例会不会重复创建？ | 不会。ExtensionLoader 内部持有多级缓存，同一扩展名只实例化一次；getExtension(name) 是懒加载的 |
| @Adaptive 标注在类上和方法上有什么区别？ | 标注在类上：直接使用这个类作为适配类（人工 Xxx$Adaptive）；标注在方法上：由 Dubbo 动态生成代理类字节码 |
| SPI 与 Spring Bean 的扩展有什么区别？ | Spring 靠 IoC 容器管理 bean 并注入；Dubbo SPI 是独立机制，利用 URL 作为"配置总线"传递参数，不依赖 Spring（这也是为什么 Dubbo 可以脱离 Spring 单独使用） |
| 为什么 URL 是 Dubbo 的配置总线？ | 因为 SPI 决策需要参数来源——Dubbo 统一把协议、host、port、所有配置项都塞进 URL（形如 dubbo://10.0.0.1:20880/xxx?timeout=1000&loadbalance=leastactive），@Adaptive 方法从中取值，做到了"配置跟着服务走" |
五、协议与配置
5. Dubbo 支持哪些协议？dubbo 协议有什么特点？
答：
| 协议 | 传输层 | 特点 | 适用场景 |
|---|---|---|---|
| dubbo（✅ 默认） | TCP，单一长连接 + NIO 异步 | Hessian2 序列化、报文头小、吞吐高 | 小数据量、高并发的内部服务调用 |
| rmi | TCP | JDK 原生 java.rmi | 遗留互操作；很少用 |
| hessian | HTTP（短连接） | Hessian 序列化，可穿透防火墙 | 需走 HTTP 且要跨语言 |
| http | HTTP | 表单/JSON，浏览器可直接访问 | 需要被外部系统/浏览器直接调用 |
| rest（Dubbo 2.6+） | HTTP | JAX-RS 风格 RESTful | 对外提供 REST 接口 |
| webservice | HTTP + SOAP | SOAP/XML | 与异构旧系统对接 |
| grpc / Triple（Dubbo 3） | HTTP/2 | 兼容 gRPC、支持流式、可穿透网关 | 跨语言、云原生、流式场景 |
| thrift | TCP | Thrift 序列化 | Thrift 生态互操作 |
✅ dubbo 协议的核心特点（面试高频）：
| 特点 | 说明 |
|---|---|
| 单一长连接 | Consumer 到每个 Provider 只建 1 条 TCP 长连接，避免大量 TIME_WAIT 和握手开销 |
| NIO 异步 | 基于 Netty，一个 IO 线程可处理海量连接；业务请求丢给业务线程池执行 |
| 全双工复用 | 一条连接上并发多个请求，靠 requestId（8 字节）把响应和请求对上 |
| 默认端口 20880 | 可在 <dubbo:protocol port="20880"/> 调整 |
| 默认序列化 Hessian2 | 可通过 <dubbo:protocol serialization="kryo"/> 切换 |
| 不适合大数据包 | ⚠️ 单一长连接 + 大报文会堵住整条连接（类似"队头阻塞"）。官方建议单包 < 100KB；传文件/大对象要么分包/切片，要么换协议（如 hessian/http/rest） |
dubbo 协议的报文结构（16 字节头 + body）：
┌─────────────────────── 16 Byte Header ──────────────────────┐
│ magic(2B) │ flag(1B) │ status(1B) │ invokeId(8B) │ len(4B) │
├───────────┴──────────┴────────────┴─────────────┴───────────┤
│ magic = 0xdabb 魔数，标识这是 dubbo 协议包 │
│ flag = 请求/响应 + 是否心跳 + 序列化方式 ID │
│ status = 20(OK)/30(CLIENT_TIMEOUT)/31(SERVER_TIMEOUT)/50... │
│ invokeId = 请求 ID，用于把响应和请求配成一对（异步关键） │
│ len = 消息体 body 的长度，用于解决 TCP 粘包/拆包 │
├───────────────────── Body（序列化后的字节） ─────────────────┤
│ Dubbo 协议版本 + 接口名 + 方法名 + 参数类型 + 参数值 + 附件 │
└─────────────────────────────────────────────────────────────┘面试加分句：正是因为有了
len字段，Dubbo 才能解决 TCP 粘包 / 拆包问题——接收端先凑满 16 字节头、读出 body 长度，再按长度取 body。
6. Dubbo 的超时、重试、服务降级怎么配？配置优先级是什么？
答：
① 两大核心参数的默认值（务必背下来）
| 参数 | 默认值 | 说明 |
|---|---|---|
timeout | 1000 ms | 调用超时时间，Consumer 等待响应超过它就抛 TimeoutException |
retries | 2 | Failover 重试次数，不含第一次，所以最多尝试 3 次 |
② 配置的优先级（经典考题）
【两个维度：粒度 + 角色】
粒度维度： 方法级 > 接口级 > 全局级
角色维度： 消费端 Consumer > 提供端 Provider
综合优先级（由高到低）：
① Consumer 方法级 （<dubbo:reference><dubbo:method/>）
② Provider 方法级 （<dubbo:service><dubbo:method/>）
③ Consumer 接口级 （<dubbo:reference/>）
④ Provider 接口级 （<dubbo:service/>）
⑤ Consumer 全局 （<dubbo:consumer/>）
⑥ Provider 全局 （<dubbo:provider/>）✅ 为什么超时以 Consumer 为准？ Provider 最清楚自己"要多久"，但只有 Consumer 知道"我能等多久"。Provider 的配置通过注册中心下发，作为一种建议/兜底；Consumer 一旦显式配置就以 Consumer 的为准。
⚠️ 例外：Provider 端自己也会做超时控制（执行超过 timeout 会告警/记录），但真正的中断动作发生在 Consumer 侧——Consumer 不再等响应而已，正在 Provider 上执行的线程不会被"杀掉"，所以超时请求仍可能已生效（正是这个原因，超时重试必须配幂等）。
③ 服务降级（Mock）的几种写法
mock="return null" → 调用失败时返回 null（无条件降级）
mock="fail:return null" → 只有调用"失败"时才返回 null（等价上面）
mock="force:return null" → 强制执行本地伪装，压根不发起远程调用（大促"摘除"下游用）
mock="throw" → 直接抛异常
mock="com.xx.OrderServiceMock" → 走自定义 Mock 类（可返回兜底数据、查缓存、写降级日志）| 降级手段 | 说明 |
|---|---|
| Mock 本地伪装 | 服务不可用时返回兜底值，让主流程不崩 |
| 屏蔽（force） | 直接不调用该服务，直接走 mock，用于"摘流量" |
| 容错（fail） | 正常调用，失败才走 mock |
| Sentinel 熔断降级 | Dubbo 可集成 Sentinel 做熔断 / 流控 / 系统自适应保护，比静态 mock 更智能 |
④ 一个生产级推荐实践
# Provider 侧：给自己设一个稳妥的建议值
dubbo.provider.timeout=3000
# Consumer 侧：按接口分别配，写操作一律关重试
dubbo.consumer.timeout=500
# 读接口：允许重试
@DubboReference(retries = 2, timeout = 1000, cluster = "failover")
private OrderQueryService orderQueryService;
# 写接口：绝不允许重试（非幂等）
@DubboReference(retries = 0, timeout = 1000, cluster = "failfast")
private OrderCreateService orderCreateService;六、Dubbo 3 的关键变化
7. Dubbo 3 相比 Dubbo 2 有哪些重大升级？（2024+ 面试新热点）
答： Dubbo 3 的定位是「云原生微服务框架」，四个关键词：应用级服务发现、Triple 协议、统一路由规则、Kubernetes 原生。
| 变化 | Dubbo 2 | Dubbo 3 | 收益 |
|---|---|---|---|
| 服务发现粒度 | 接口级：每个接口注册一批 URL（元数据 + 地址） | 应用级：一个应用只注册一条记录，接口→应用的映射由消费端本地自行组装 | 注册数据减少约 90%+，注册中心压力骤降 |
| 协议 | dubbo 私有 TCP 协议 | Triple（基于 HTTP/2，兼容 gRPC） | 可穿透网关、支持流式通信、跨语言友好 |
| 流式通信 | ❌ 只有请求-响应 | ✅ Triple 支持 Stream（服务端流、双向流） | 支持 LLM 流式输出、实时推送 |
| 服务发现设施 | Nacos/ZK 等第三方 | K8s API Server 原生支持 | 不用额外部署注册中心 |
| 服务网格 | 需 Sidecar 改造 | Proxyless Mesh（Dubbo 直连 xDS 控制面） | 无 Sidecar 也能进 Service Mesh |
| 性能 | — | 单连接模型优化 + 原生支持 Reactive | 吞吐提升 |
必须记住的迁移问题：Dubbo 3 默认是应用级服务发现，与 Dubbo 2 的接口级模型不兼容。混部时要通过
dubbo.application.service-discovery.migration（如FORCE_INTERFACE/APPLICATION_FIRST/FORCE_APPLICATION）做平滑迁移。
本篇小结
| 题 | 一句话 |
|---|---|
| 1 | 注册中心是旁路设施——挂了不影响已有调用（本地缓存 + 长连接直连）；Nacos 优于 ZK（AP + 控制台 + 配置中心一体化） |
| 2 | 负载均衡默认 Random（加权随机），4 类经典策略；一致性哈希靠 160 虚拟节点均衡分布 |
| 3 | 容错默认 Failover（retries=2，最多 3 次）；非幂等写操作必须 retries=0 或 Failfast |
| 4 | Dubbo SPI = 按需加载 + IOC + Wrapper AOP + @Adaptive + @Activate，完胜 Java SPI |
| 5 | dubbo 协议 = 单一长连接 + Netty NIO + requestId 复用；16 字节头含 len 解决粘包；不适合大报文 |
| 6 | 默认 timeout=1000ms、retries=2；优先级 方法级 > 接口级 > 全局，同粒度消费端优先，超时要配幂等 |
| 7 | Dubbo 3 = 应用级服务发现 + Triple(HTTP/2) + 流式 + K8s 原生 + Proxyless Mesh |
下一篇：《Grpc（一）》换到 Google 阵营，从 HTTP/2 的多路复用与二进制分帧讲起，看清 gRPC 为什么选择了 HTTP/2；然后深挖 Protobuf 的编码原理（Tag-Length-Value、Varint、ZigZag）与字段演进规则，接着把 gRPC 四种通信模式、Metadata / Deadline / Interceptor / 状态码讲透，最后给出 Dubbo 与 gRPC 的完整对比与选型建议。