gRPC 通信机制

引言

在微服务架构中，服务与服务之间的通信方式直接决定了系统的整体吞吐量和网络开销。相比于传统的 HTTP/JSON RESTful API，gRPC 凭借其高性能的二进制协议，成为了云原生应用中不可或缺的底层通信框架。

Protocol Buffers 二进制编码

Protobuf 的定义

Protocol Buffers（简称 Protobuf）是 Google 开发的一种语言无关、平台无关的可扩展序列化结构数据格式。

syntax = "proto3";

message UserRequest {
  int32 id = 1;
  string name = 2;
}

为什么比 JSON 更快

JSON 是一种文本格式，不仅体积庞大（包含了大量的花括号、引号及字段名），而且解析时需要耗费可观的 CPU 资源进行字符串解析。而 Protobuf 会直接将其编译为紧凑的二进制字节流，传输时甚至不需要传输字段名，只通过“标签号”（Tag）来标识字段，极大地节省了带宽并加速了反序列化过程。

HTTP/2 协议底座

gRPC 完全基于 HTTP/2 协议构建，因此能够共享 HTTP/2 带来的所有技术突破：

多路复用 (Multiplexing)

在同一个 TCP 连接上，HTTP/2 允许并发双向发送多个请求和响应，而无需像 HTTP/1.1 那样为每个请求单独建立 TCP 连接或排队等待，从而彻底解决了“队头阻塞（Head-of-Line Blocking）”问题。

头部压缩 (HPACK)

微服务间的调用极其频繁，请求头通常高度重复。HTTP/2 在客户端和服务器两端维护了一个静态和动态的头部索引表，传输时只需发送头部字段在表中的索引即可，大幅降低了首部信息的开销。

双向流式传输

gRPC 支持四种通信模式：

• 简单 RPC：一问一答模式。
• 服务端流式 RPC：客户端发送一个请求，服务端回以一个数据流。
• 客户端流式 RPC：客户端发送一个数据流，服务端处理后回以一个响应。
• 双向流式 RPC：双方建立全双工通道，可自由向对方发送数据流。

gRPC 在微服务中的实践建议

连接池管理

虽然 HTTP/2 允许单个连接并发多个请求，但在极高并发场景下，单个连接可能会受到 TCP 窗口大小或内核线程的限制。建议在客户端维护一个轻量级的 gRPC 连接池（Channel Pool），以实现负载均衡和容灾。