订单服务调库存服务的一次 RPC

1Stub：远程调用被包装成一个普通方法

InventoryServiceGrpc 是从 inventory.proto 生成的。它的 reserve(req) 不干业务，只做一件事：把“调 /inventory.InventoryService/Reserve 这个方法、参数是 req、deadline 300 ms”包成一次调用（ClientCall），交给通道，然后让当前的下单线程等结果。Dubbo 用动态代理做同一件事，Feign 用接口加注解。

为什么要它业务代码只管“我要预占库存”，不用知道下面是哪种协议、哪台机器。代价也在这里：它太像本地方法了，人很容易忘记它会慢、会超时、会失败一半。

往下一层RPC 原理：序列化、协议、服务发现、负载均衡（④-1 Stub、④-6 为什么不能完全“像本地”）

常出的事在循环里一次次调远程方法（N+1 次 RPC），或者在持有数据库事务和锁的时候调它：对面慢 300 ms，本地的锁就多拿 300 ms。

2发现与负载均衡：inventory 在哪，挑哪一台

通道的目标是 registry:///inventory，一个名字。名字解析器（NameResolver）去注册中心查，拿到 :50051、:50052 两个地址；负载均衡器（这里是 round_robin）给每个地址维护一个子通道，每次调用轮着挑一个。注册中心里的地址变了，解析器推新列表过来，负载均衡器跟着增删子通道。

实测 5000 次并发调用，实例 A 和 B 各 2501 次（含第一次和帧日志那一次）。不配策略时 gRPC 默认是 pick_first：所有调用都去第一个地址。

为什么要它实例会扩容、缩容、挂掉、换 IP。调用方写死地址，每次变动都要改配置、重启；有了发现，地址是活的。

往下一层RPC 原理：服务发现、负载均衡（含坏实例被最少活跃多分流量的实测） · 注册中心本身在 J10 微服务治理

常出的事实例已经挂了，注册中心还没摘掉它（心跳超时要几秒到几十秒），请求继续被分过去；或者忘了配策略，默认 pick_first，一台累死、一台闲着。

3连接：每台一条长连接，第一次要现建

子通道背后是一条 TCP 连接，上面跑 HTTP/2。连接已经在了，这一步就是“在这条连接上开一个新的 stream”，几乎不花时间。第一次调用时还没有：要 TCP 三次握手、发 HTTP/2 的开场白（连接前言 + SETTINGS 帧），再加上 JVM 第一次碰这些代码时加载类、解释执行。

实测 冷启动的第一次 312～329 ms，3 次里 2 次被自己的 300 ms deadline 判了超时；第二次 8.5～16.6 ms。类都加载过以后，再新建一条连接的第一次是 9～20 ms，HTTP/1.1 是 4.5～8 ms。所以冷启动那 300 ms 里，大头是类加载和 JIT 之前的解释执行，不是握手。

为什么要它建连接贵（跨机房一次握手就是一个 RTT，加 TLS 再多一两个），所以连接要复用。HTTP/1.1 靠连接池复用，HTTP/2 一条连接就够。

往下一层HTTP 客户端与连接池：超时怎么配（池子多大、拿连接超时、连接超时、空闲回收；第一圈在 网络 IO 模型） · TCP 握手：TCP：握手、挥手、TIME_WAIT 与粘包 · 类加载和预热：JIT 与逃逸分析

常出的事服务刚发布，流量一来，头几百个请求全部超时，触发熔断，看起来像“新版本有 bug”。修法是启动时先调几次预热、建好连接，再在注册中心上线。另一个坑：长连接被中间的防火墙或负载均衡器悄悄掐了，客户端不知道，下一次调用才发现，要靠 keepalive 探活（gRPC 客户端默认关着）。

4序列化：对象变成 7 个字节

protobuf 按 .proto 里的字段号编码：08 b7 4a 是“1 号字段，变长整数 9527”，10 58 是“2 号字段，88”，18 02 是“3 号字段，2”。不写字段名，整数用变长编码，小数字只占一两个字节。JSON 要把 "orderId" 这些名字每次都带上，还得按文本解析。

实测 同一个请求：protobuf 7 字节，JSON 35 字节。

为什么要它网络上只能传字节。编码越小、解析越快，同样的带宽和 CPU 能跑更多调用；靠字段号而不是字段名，两边可以各自加字段而不互相打断。

往下一层RPC 原理：序列化（protobuf、JSON、JDK 序列化对比，字段兼容规则）

常出的事改了 .proto 里已有字段的编号或类型，旧版本的调用方还在按老编号发，对面解出来是错的值，而且不报错。删字段要把编号保留下来（reserved），不能挪作他用。

5HTTP/2 帧：一次调用 = 一个 stream 上的两个帧

gRPC 把一次调用映射成 HTTP/2 的一个 stream。先发 HEADERS 帧：:path 是方法名，grpc-timeout 把剩下的 deadline 告诉对面；再发 DATA 帧：5 字节前缀（1 字节“是否压缩” + 4 字节长度 00000007）加 7 字节消息，共 12 字节，endStream=true 表示请求发完。头部用 HPACK 压缩，重复的头几乎不占字节。

实测 OUTBOUND HEADERS: streamId=5005 … grpc-timeout: 299936u（还剩 299.936 ms），OUTBOUND DATA: … length=12 bytes=000000000708b74a10581802。客户端发起的 stream 编号是奇数，每次加 2，所以 5005 说明这条连接上已经跑过两千多次调用。

为什么要它HTTP/1.1 一条连接同时只能有一个请求在途，想并发就得多开连接。HTTP/2 给每个请求一个 stream 编号，帧可以交错发，一条连接上同时跑很多个请求。

往下一层HTTP/1.1、HTTP/2 与 HTTPS（第一圈）

常出的事中间的代理或网关只会 HTTP/1.1，gRPC 过不去；或者负载均衡器按连接分流（四层），一条长连接把所有请求都钉在同一台后端上，扩容了也分不过去。

6客户端 Netty：EventLoop 线程把字节写进 socket

下单线程不自己写 socket。它把“发这两个帧”的任务交给这条连接绑定的 EventLoop 线程，然后阻塞等结果。EventLoop 依次经过 Pipeline 上的处理器：HTTP/2 编码器把帧变成字节，放进 ByteBuf（Netty 的字节缓冲，常用堆外内存、可以池化复用），最后一次 write 加 flush 交给内核。

实测 帧日志每一行都出自 grpc-default-worker-ELG-3-2，不是调用方线程。名字里的 default 表示用的是 epoll 版（grpc-netty-shaded 自带 Linux 的 epoll 本地库），否则会叫 grpc-nio-worker-ELG。

为什么要它一条连接只归一个 EventLoop 线程管，读写都在这个线程上，就不用加锁；几个 EventLoop 线程就能管成千上万条连接。

往下一层Netty：EventLoop、Pipeline、ByteBuf · IO 模型与 Reactor

常出的事自己写 Netty 处理器时用完 ByteBuf 不 release，堆外内存慢慢漏光，堆的监控却一切正常（呼应 J03 第 10 站：容器只看进程总内存）。

7TCP：可靠的字节流，没有“消息”这个概念

内核把字节放进这条连接的发送缓冲区，切成 TCP 段发出去；对面收到后回 ACK，丢了就重传，乱了就排好序，最后放进对面的接收缓冲区。TCP 只保证字节按顺序、不丢、不重，不管哪几个字节是一条消息：两次写可能被对面一次读到（粘包），一次写也可能分两次才读完（拆包）。所以上层协议必须自己标边界，第 5 站的长度前缀就是干这个的。

实测 对照组的 HTTP/1.1 服务端（JDK 的 HttpServer）默认不开 TCP_NODELAY，稳定后每次调用 p50 是 41.2 ms；打开以后是 0.84～0.91 ms。gRPC 的 Netty 默认就开着，不受影响。

为什么要它网络会丢包、乱序，应用自己处理太难。TCP 把这些藏起来，代价是握手、慢启动，以及 Nagle 算法这类“攒一攒再发”的优化。

往下一层TCP：握手、挥手、TIME_WAIT 与粘包（第一圈在 从 URL 到页面）

常出的事就是上面那 40 ms：Nagle 算法要等上一段的 ACK 才发下一小段，对面的延迟 ACK 又故意攒着不回，两边互等，等到对面的 ACK 定时器到点。请求响应式的小包协议都应该开 TCP_NODELAY。另一个常见坑是短连接调用量大时，主动关闭的一方堆满 TIME_WAIT。

8服务端 Reactor：epoll 叫醒 EventLoop，切出一条消息

库存服务的 EventLoop 线程平时睡在 epoll_wait 上，管着很多条连接。数据到了，内核把这条连接标成“可读”，线程醒来，一口气读出接收缓冲区里的字节，交给 Pipeline：HTTP/2 解码器认出 HEADERS 帧和 DATA 帧，gRPC 再按 5 字节前缀里的长度，从 DATA 里切出完整的 7 字节消息，凑不够就等下一次读。

实测 服务端记下的连接由 grpc-default-worker-ELG-3-1 接手；50 个线程的并发全落在每台一条连接上，也就是一个 EventLoop 线程在读。

为什么要它一个连接一个线程（BIO），一万条连接就是一万个线程，大部分时间在等数据。Reactor 让少数线程只在“有事”的时候干活，这就是 IO 多路复用。

往下一层IO 模型与 Reactor · Netty 线程模型：Netty：EventLoop、Pipeline、ByteBuf · 同一个模型在 Redis 里：Redis 线程模型与 IO

常出的事在 EventLoop 线程上做了耗时的事（查库、同步调别的服务、大 JSON 解析），这个线程管的所有连接一起卡住，表现是“所有接口一起慢，CPU 却不高”。

9业务线程池：反序列化，扣库存

gRPC 把“执行 reserve”这个任务从 EventLoop 交给服务端配置的 executor，这里是一个 16 线程的 inventory-biz 池。业务线程把 7 字节解回 ReserveRequest，扣 88 号商品 2 件，生成 ReserveReply 交回给 EventLoop 去写。不配 executor 时，gRPC 用一个不限大小的缓存线程池。

实测 业务代码跑在 inventory-biz-15 这类线程上，EventLoop 线程只管读写字节。

为什么要它业务可能会阻塞（等行锁、查数据库），不能占着 EventLoop。IO 线程少而快，业务线程多而慢，两边分开，就是 Netty 常说的“IO 线程和业务线程分离”。

往下一层IO 线程和业务线程分离：Netty：EventLoop、Pipeline、ByteBuf（坑 1） · 线程池怎么配：J02 全景：一个下单请求在线程池里

常出的事用默认的不限大小线程池，库存数据库一慢，请求越积越多，线程数涨到几千，最后 OOM 或者被上下文切换拖垮。业务池要有界，满了快速拒绝，让调用方降级。

10回程与超时：结果回来，或者 300 ms 一到就放弃

正常情况：库存服务回一个 HEADERS（:status 200）、一个 DATA（11 字节的 ReserveReply）、一个只有 grpc-status: 0 的 trailers 帧，沿第 8、7、6 站原路回来，下单线程被唤醒，拿到返回值。慢的情况：客户端的 deadline 到了，直接抛 DEADLINE_EXCEEDED，再给对面发一个 RST_STREAM 取消这个 stream。

实测 订单 9528 在库存那边要等 500 ms：客户端 302 ms 后收到 DEADLINE_EXCEEDED。库存服务 500 ms 后醒来，Context.isCancelled() 已经是 true，但业务代码没看它，库存照样扣了 2 件。

为什么要它没有 deadline，对面一卡，调用方的线程就跟着一直等，线程池被占满，故障从库存服务传染到订单服务。gRPC 默认没有 deadline，必须自己配。

往下一层HTTP 客户端与连接池：超时怎么配（四段超时、读超时不是总超时、总 deadline、超时后重试扣两次的实测） · 第一圈在 网络 IO 模型

常出的事“超时”不等于“没做”。客户端以为失败了，重试一次，库存就扣了 4 件。所以重试只能用在幂等的接口上：库存按 order_id 去重，同一个订单扣过就直接返回上次的结果。第二个坑是超时没有逐级变短：网关 1 s、订单 2 s、库存 3 s，上游早放弃了，下游还在白干。