S17-B03 · 服务调用：RPC、负载均衡与 Dubbo

适用读者：用过 Feign/Dubbo 但不知道"像调本地方法"背后发生了什么的人。
前置：S17-B02、S04-J04（动态代理）。
覆盖旧文：1051(83) 1052(90) 1055(85) 912(78) 479(41) 1047(92) 1048(43) + Dubbo 六卡 = 1,020 点。
覆盖扩展：E-S17-013（RPC 的四个环节）。
上一篇：S17-B02 · 服务注册与发现
下一篇：S17-B04 · 网关。

1. 一句话结论

RPC 的"像本地调用"是假的：背后一定有"代理 → 序列化 → 网络 → 反序列化 → 反射调用"五步，每一步都可能失败或变慢。

调用方 method() → 动态代理 → 序列化 → 网络 → 反序列化 → 提供方反射调用

这与 S04-B05 的"动态代理"、S04-J04 的"反射"完全同源——RPC 框架只是把这几块拼起来。

2. 五个环节（E-S17-013）

环节	关键决策	影响
代理	JDK 动态代理/字节码生成	调用开销
序列化	JSON/Hessian/Protobuf	体积与兼容性
协议	HTTP/Dubbo/TCP	跨语言与性能
负载均衡	随机/轮询/一致性哈希/最少活跃	分布均匀度
容错	重试/熔断/降级	雪崩防控

判据："要跨语言吗？" 要 → HTTP + Protobuf/JSON；不跨 → 私有协议（Dubbo）性能更好。

3. 序列化的取舍（A-1054）

方式	体积	跨语言	兼容性
JSON	大	✅	好
Hessian	中	⚠️	一般
Protobuf	小	✅	需 schema 演进纪律

S09（Go）的实测：Protobuf 比 JSON 小 2.51×（batch 场景）——这条在 RPC 场景同样成立。

4. 负载均衡：四种策略

策略	特点
随机	简单，量小时不均
轮询	均匀但不感知负载
最少活跃	感知处理能力（推荐）
一致性哈希	缓存亲和

"重试会不会放大故障"：会——重试必须配熔断与限流（A01），否则故障时把流量翻倍打过去。

5. Dubbo 与 Feign 的差别（A-912）

维度	Dubbo	Feign（Spring Cloud）
协议	私有 TCP（默认）	HTTP
性能	高（二进制）	中
跨语言	较弱（生态）	强
服务发现	自带（可接 Nacos/ZK）	依赖注册中心
适用	Java 内部高并发	多语言/对外 API

判据："内部服务且全 Java？" 是 → Dubbo；否则 → HTTP 系。

6. 五个误区

误区	真相
"RPC 和本地调用一样快"	有序列化与网络开销
"重试能提升成功率"	故障时会放大
"JSON 一定比 Protobuf 差"	跨语言/可读性更好
"Dubbo 一定比 Feign 好"	取决于是否跨语言
"负载均衡能解决不均"	需感知负载的策略

7. 自检

RPC 的五个环节？
序列化的三个权衡维度？
四种负载均衡策略的差异？
为什么"重试要配熔断"？
Dubbo 与 Feign 怎么选？

8. 下一篇

S17-B04 · 网关：统一入口与跨域

调用讲完，下一篇讲"外部流量怎么进来"：网关与 Nginx 的分工。

本篇属于系列《S17 · 分布式与消息队列》。旧文来源：A-1051/1052/1055/912/479/1047/1048 + Dubbo 六卡；扩展点 E-S17-013。Protobuf 对比引用 S09 实测。