RPC 原理：序列化、协议、服务发现、负载均衡。让远程方法用起来像本地方法，背后是四件事

需求（假设场景）：工作里用 gRPC 或 Dubbo 调服务，要能看懂超时、重试、分流不均这类问题出在哪一层；面试也常让人讲“自己写一个 RPC 要几步”。所以 ⑤ 用一个 400 行的纯 JDK 迷你 RPC 把四层亲眼跑一遍，⑥ 先讲事故最多的坑，最后附几道面试题。

String url = "http://10.0.3.17:8080/inventory/reserve"; // 地址写死
String body = "{\"orderId\":" + orderId + ",\"skuId\":" + skuId
            + ",\"qty\":" + qty + "}";                  // 字段名手敲
HttpRequest req = HttpRequest.newBuilder(URI.create(url))
    .timeout(Duration.ofMillis(300))
    .header("Content-Type", "application/json")
    .POST(BodyPublishers.ofString(body)).build();
HttpResponse<String> resp = http.send(req, BodyHandlers.ofString());
if (resp.statusCode() != 200) { /* 重试？换一台？*/ }
ReserveReply r = mapper.readValue(resp.body(), ReserveReply.class);

// 契约：双方共同依赖的接口（或 .proto 生成的类）
public interface InventoryService {
    ReserveReply reserve(ReserveRequest req);
}

// 调用方
ReserveReply r = inventory.reserve(new ReserveRequest(9527, 88, 2));

不懂精华时的典型误用：把远程调用当成本地方法用。在 for 循环里逐个调 getSku(id)，100 个商品就是 100 次网络往返（N+1）；在 @Transactional 方法里调远程，对面慢 300 ms，本地的数据库行锁就多占 300 ms；超时了就重试，可对面其实已经扣过库存（⑥ 坑 1 实测）。本地方法要么成功要么抛异常，远程调用还有第三种结果：不知道成没成功。

选择规则：新系统、要跨语言或对外暴露，选 gRPC；Java 为主、用 Nacos 一类国内生态和服务治理，选 Dubbo；已经是 Spring Cloud HTTP 体系、调用量不大，用 OpenFeign。三者的四件事原理相同，换框架只是换默认值，所以先把四件事本身学透。

本页学 RPC 四件事的原理：用一个纯 JDK 写的迷你 RPC 把每一件拆开看，再对照 gRPC 1.84 和 Dubbo 3.3 的真实做法。

④-0 一次调用的全程

④-1 Stub：动态代理把方法调用变成数据

return (T) Proxy.newProxyInstance(api.getClassLoader(), new Class<?>[]{api},
    (proxy, method, args) -> call(api.getName(), method.getName(), args));
// inventory.reserve(req) → call("…InventoryService", "reserve", [req])

方法调用本来是“跳到一段代码去执行”，到这里变成了一份数据：服务名、方法名、参数。数据可以序列化、可以发到任何地方。gRPC 不用运行时代理，而是从 .proto 编译期生成 InventoryServiceGrpc，做的事一样。Stub 也是最危险的一层：它让远程调用和本地调用长得一模一样（④-6）。

④-2 序列化：要不要把“结构”写进字节里

Dubbo 默认的 hessian2 和 JSON 一样是自描述的，不用 IDL，Java 对象直接传，所以大小在两者之间。选哪种是一组取舍：约定结构小、快、跨语言，但要先写 IDL；自描述拿来就用、可读，但更大，而且反序列化时要按字节流里写的类名去创建对象，这正是反序列化漏洞的来源（⑥ 坑 7）。

④-3 协议：帧头里每个字段都在防一件事

④-4 服务发现：名字换地址，而且地址是活的

④-5 负载均衡：每次调用挑一台，看不看对方忙不忙

为什么“在途请求数”能反映快慢：慢的实例每个请求要占 30 ms，发过去的请求还没回来就在那攒着，它的在途数总是偏高，于是少分。它不需要知道对方的 CPU、队列长度，只看自己这边的计数，这是它便宜又有效的原因。同一个原因也是它的盲区：一台坏掉、立刻报错的实例，在途数永远是 0，看起来最闲（⑥ 坑 2）。

④-6 为什么这样设计

决定胜负的约束：服务间调用是海量的小请求，在两个固定的端点之间反复发生。连接是贵的、请求是便宜的，所以连接要复用到极致，就必须有请求 id。

决定胜负的约束：④-6 上面那个选择：长连接 + 多路复用。请求都在少数几条长连接里，只有发请求的那一方能按“每次调用”来分，所以均衡必须放在客户端（或贴着客户端的 sidecar）。

还有一个更老的教训：上世纪 90 年代的 CORBA、RMI 想做到“远程对象和本地对象完全一样”。1994 年 Sun 实验室的《A Note on Distributed Computing》指出这条路走不通：延迟、部分失败、没有共享内存，这些差别藏不住，藏起来只会让人写出错的程序。今天的 gRPC 因此把差别摆在明面上：每次调用都可以带 deadline，失败返回明确的状态码（DEADLINE_EXCEEDED、UNAVAILABLE……）。Stub 只负责让写法像本地调用，超时、失败和重试仍要在代码里明确处理。

④-7 最少的 API：真实框架里这四件事写在哪

// gRPC：Stub 由 .proto 生成；发现写在 target 里，均衡和超时显式配
ManagedChannel ch = ManagedChannelBuilder.forTarget("dns:///inventory:50051") // 服务发现
    .defaultLoadBalancingPolicy("round_robin")                             // 不配就是 pick_first
    .usePlaintext().build();                                               // 内网明文 HTTP/2
ReserveReply r = InventoryServiceGrpc.newBlockingStub(ch)                   // Stub
    .withDeadlineAfter(300, TimeUnit.MILLISECONDS)                         // 不配就无限等
    .reserve(ReserveRequest.newBuilder().setOrderId(9527).setSkuId(88).setQty(2).build());

// Dubbo：Java 接口就是契约；注册中心写在配置里，策略写在注解上
@DubboReference(timeout = 300, retries = 0, loadbalance = "leastactive")
private InventoryService inventory;          // 注入的是代理
// application.yml: dubbo.registry.address: nacos://127.0.0.1:8848

String addr = lb.pick(addresses.get(service), active);        // 3 本地列表 + 负载均衡
active.get(addr).incrementAndGet();                             // 在途 +1，最少活跃就看它
try {
    Connection c = connections.computeIfAbsent(addr, Connection::open);  // 每个地址一条长连接
    long id = nextId.incrementAndGet();
    byte[] body = serializer.write(new RpcMessage.Request(service, method, args));  // 2
    CompletableFuture<Frame> f = c.send(new Frame(REQUEST, serializer.id(), id, body)); // 4 登记 pending 再写
    try {
        Frame resp = f.get(timeoutMs, TimeUnit.MILLISECONDS);   // 8 读线程按 id 唤醒这里
        ...
    } catch (TimeoutException e) {
        c.pending.remove(id);         // 不等了；但对面可能已经在做，甚至做完了
        throw ...;
    }
} finally {
    active.get(addr).decrementAndGet();
}

short magic = in.readShort();
if (magic != MAGIC) throw new IOException("魔数不对，不是本协议的连接");
in.readByte();                                   // 版本
byte type = in.readByte(), ser = in.readByte();
long id = in.readLong();
int len = in.readInt();
if (len < 0 || len > MAX_BODY) throw new IOException("体长度异常：" + len);
byte[] body = new byte[len];
in.readFully(body);                              // TCP 分几段送来都没关系，凑够 len 字节才返回

git clone https://github.com/archeu/study-labs.git && cd study-labs/java
mvn -q -pl network/rpc-serialization-discovery-lb compile exec:java \
  -Dexec.mainClass=labs.network.rpc_serialization_discovery_lb.MiniRpcDemo

JDK 17.0.20.1

== 1. 序列化：同一个 ReserveRequest(9527, 88, 2) 变成多少字节 ==
JDK 序列化 127 字节 | JSON 35 字节 | Compact 9 字节：51 08 b7 4a 10 58 18 02 00
JDK 字节流里能读到的字符串：>labs.network.rpc_serialization_discovery_lb.Api$ReserveRequest | orderIdI | qtyJ | skuIdxp |
整条 RPC 请求（服务名 + 方法名 + 参数）：JDK 397 字节，Compact 86 字节
一帧 = 17 字节头 + 86 字节体 = 103 字节
头：ca fe 01 00 02 00 00 00 00 00 00 00 01 00 00 00 56  ← 魔数 cafe | 版本 01 | 类型 00=请求 | 序列化 02 | 请求 id 8 字节 | 体长度 4 字节

== 2. 一次调用，看起来像本地方法 ==
inventory 的真实类型：jdk.proxy1.$Proxy0
reserve(9527, 88, 2) → ReserveReply{ok=true, instance=A}

== 3. 轮询：1000 次顺序调用 ==
{A=500, B=500}

== 4. 服务发现：C 上线，A 下线 ==
C 注册后 300 次：{A=100, B=100, C=100}
A 摘除并关闭后 300 次：{B=150, C=150}

== 5. 一台变慢：fast 2 ms，slow 30 ms，16 线程共 2400 次 ==
轮询   fast 1200 次 / slow 1200 次 | 平均  16.3 ms | p90  30.2 ms | p99  31.5 ms
随机   fast 1214 次 / slow 1186 次 | 平均  16.1 ms | p90  30.2 ms | p99  31.1 ms
最少活跃 fast 2214 次 / slow  186 次 | 平均   4.4 ms | p90   2.8 ms | p99  30.3 ms

== 5b. 一台坏了但还在注册中心里：它立刻报错，16 线程共 2400 次 ==
轮询   a  800 次 / b  800 次 / bad  800 次 | 错误率 33.3%
最少活跃 a  465 次 / b  476 次 / bad 1459 次 | 错误率 60.8%

== 6. 超时：客户端等 100 ms，库存要 300 ms ==
101 ms 后客户端收到：java.util.concurrent.TimeoutException: reserve 超过 100 ms 没回复，地址 127.0.0.1:33339
此刻库存已扣次数：0
再等 400 ms，库存已扣次数：1  ← 超时不等于没做

本机 2 核 ARM，JDK 17.0.20，跑了 3 次：第 1～4、6 段每次相同（端口除外）；第 5 段每次差几个百分点；5b 的最少活跃错误率三次分别是 67.4%、61.3%、60.8%。Compact 比 protobuf 多 2 个字节：开头 1 字节类型标记 51（'Q'）和结尾的 00，中间 7 个字节和 protobuf 一模一样。

实验台：哪种负载均衡最扛事

• 注册中心本身：ZooKeeper（CP）和 Nacos / Eureka（AP）为什么选择不同（J10 服务治理）
• 一致性哈希和虚拟节点：加一台机器时，只有多少比例的 key 要搬家
• 用 Netty 重写 ⑤ 的迷你 RPC：读线程换成 EventLoop，帧解码换成 LengthFieldBasedFrameDecoder
• gRPC 的流式调用和流量控制：HTTP/2 窗口怎么做到背压
• 泛化调用：网关不依赖接口包，怎么调任意服务（以及 CVE-2023-23638 为什么出在这里）
• 全链路 deadline 和链路追踪：trace id 怎么跟着元数据一路传下去