2. gRPC 基础入门
在微服务链路中，服务间通信的效率和可靠性直接影响整体架构的稳定性。gRPC 作为高性能、开源的远程过程调用框架，已成为云原生微服务通信的首选方案。本节将系统讲解 gRPC 的核心定义、序列化协议、底层传输机制以及四种服务模型，为后续重试机制与通信配置打下坚实基础。
2.1 gRPC 定义与核心特性
gRPC 是由 Google 开发并开源的高性能 RPC 框架，基于 HTTP/2 协议传输，默认使用 Protocol Buffers 作为接口定义语言和序列化工具。它支持多种编程语言，提供双向流、流控、认证等高级特性。
| 特性 | 说明 | 优势 |
|---|---|---|
| 基于 HTTP/2 | 多路复用、头部压缩、服务器推送 | 降低延迟，减少连接开销 |
| Protocol Buffers | 强类型 IDL + 二进制序列化 | 体积小、解析快、向前兼容 |
| 双向流 | 客户端流、服务端流、双向流 | 适合实时推送、大数据传输 |
| 多语言支持 | Java、Go、Python、C++ 等 11+ 语言 | 异构系统无缝集成 |
| 内置认证 | SSL/TLS、Token、自定义认证 | 安全通信开箱即用 |
核心认知：gRPC 不是简单的 HTTP API 替代品，而是面向服务间通信设计的 RPC 框架。在微服务链路中，gRPC 的强类型契约和高效序列化能显著降低接口联调成本。
2.2 Protocol Buffers 简介
Protocol Buffers（简称 Protobuf）是 gRPC 的默认序列化协议。它通过 .proto 文件定义数据结构和服务接口，然后生成各语言的代码。相比 JSON/XML，Protobuf 序列化后的体积小 3~10 倍，解析速度快 20~100 倍。
2.2.1 基本语法示例
syntax = "proto3";
package order.v1;
// 订单服务定义
service OrderService {
rpc CreateOrder (CreateOrderRequest) returns (CreateOrderResponse);
rpc GetOrder (GetOrderRequest) returns (GetOrderResponse);
}
// 创建订单请求
message CreateOrderRequest {
string user_id = 1;
repeated string product_ids = 2;
double total_amount = 3;
}
// 创建订单响应
message CreateOrderResponse {
string order_id = 1;
int32 status_code = 2;
string status_message = 3;
}2.2.2 Protobuf 与 JSON 对比
| 对比维度 | Protocol Buffers | JSON |
|---|---|---|
| 序列化格式 | 二进制 | 文本 |
| 数据体积 | 极小（约 JSON 的 1/3~1/10） | 较大 |
| 解析速度 | 极快（无需字符串解析） | 较慢 |
| 类型安全 | 强类型（编译期检查） | 弱类型（运行时检查） |
| 可读性 | 需工具查看 | 人类可读 |
| 版本兼容 | 内置向前/向后兼容 | 需手动处理 |
实践要点：字段编号（如
= 1、= 2）是 Protobuf 二进制编码的关键标识，一旦发布不应修改。新增字段时使用新编号，删除字段时使用 reserved 关键字避免冲突。
2.3 gRPC 与 HTTP/2 的关系
gRPC 选择 HTTP/2 作为底层传输协议，并非偶然。HTTP/2 的多路复用、流控、头部压缩等特性，与 gRPC 的高性能通信需求高度契合。
注意：gRPC 要求 HTTP/2 必须使用 TLS 加密（生产环境），但在开发调试时可通过
grpc.WithInsecure() 禁用 TLS。生产部署务必启用 TLS，否则数据明文传输存在安全风险。
2.4 gRPC 四种服务类型
gRPC 根据数据流的方向和模式，定义了四种服务类型。理解这些类型是设计微服务接口的基础。
2.4.1 类型对比总览
| 服务类型 | 客户端流 | 服务端流 | 典型场景 | 示例 |
|---|---|---|---|---|
| 一元 RPC | 1 次请求 | 1 次响应 | 传统请求-响应 | 用户登录、订单查询 |
| 服务端流 RPC | 1 次请求 | 多次响应 | 数据推送、日志流 | 实时监控指标 |
| 客户端流 RPC | 多次请求 | 1 次响应 | 批量上传、数据聚合 | 文件分片上传 |
| 双向流 RPC | 多次请求 | 多次响应 | 实时交互、聊天 | 即时通讯、游戏同步 |
2.4.2 四种类型定义示例
syntax = "proto3";
package streaming.v1;
service StreamService {
// 一元 RPC：单请求 + 单响应
rpc UnaryCall (Request) returns (Response);
// 服务端流 RPC：单请求 + 流式响应
rpc ServerStreaming (Request) returns (stream Response);
// 客户端流 RPC：流式请求 + 单响应
rpc ClientStreaming (stream Request) returns (Response);
// 双向流 RPC：流式请求 + 流式响应
rpc BidirectionalStreaming (stream Request) returns (stream Response);
}2.4.3 四种服务类型交互流程
2.4.4 流式 RPC 的典型应用场景
- 服务端流 RPC：监控系统实时推送 CPU/内存指标；新闻订阅推送；大数据查询结果分批返回。
- 客户端流 RPC：IoT 设备批量上报传感器数据；日志聚合系统收集多行日志；文件分片上传。
- 双向流 RPC：即时通讯聊天；实时多人游戏状态同步；AI 对话流式交互。
设计原则：在微服务链路中，优先使用一元 RPC 保持简单性；当需要推送或批量处理时，再升级为流式 RPC。流式 RPC 虽然灵活，但会增加连接管理和背压处理的复杂度。