2. gRPC 基础回顾：Protocol Buffers 定义与四种通信模式

在深入熔断降级与接口通信设计之前，必须牢固掌握 gRPC 的两大基石：Protocol Buffers（protobuf）接口定义语言与四种通信模式。本章将系统梳理这两部分核心知识，为后续架构设计打下坚实基础。

2.1 Protocol Buffers 定义与核心语法

Protocol Buffers 是 gRPC 默认的接口定义语言（IDL）与序列化协议。它通过 .proto 文件定义服务接口和消息结构，具备语言中立、平台无关、序列化体积小、解析速度快等优势。

2.1.1 消息结构定义

一个典型的 .proto 文件包含消息类型（message）和字段定义。每个字段由类型、字段名和唯一编号组成。

syntax = "proto3";

package order.v1;

// 订单请求消息
message OrderRequest {
  string order_id = 1;
  string user_id = 2;
  repeated string product_ids = 3;
  double total_amount = 4;
  map<string, string> metadata = 5;
}

// 订单响应消息
message OrderResponse {
  string order_id = 1;
  string status = 2;
  int64 created_at = 3;
}

2.1.2 服务接口定义

使用 service 关键字定义 RPC 服务，每个 RPC 方法需指定输入消息类型和输出消息类型。

service OrderService {
  // 一元 RPC
  rpc CreateOrder(OrderRequest) returns (OrderResponse);

  // 服务端流式 RPC
  rpc ListOrders(OrderListRequest) returns (stream OrderResponse);

  // 客户端流式 RPC
  rpc BatchCreateOrder(stream OrderRequest) returns (OrderBatchResponse);

  // 双向流式 RPC
  rpc ProcessOrder(stream OrderRequest) returns (stream OrderResponse);
}

2.1.3 标量类型与常用修饰符

Protobuf 类型	对应语言（Java）	对应语言（Go）	说明
double	double	float64	64 位浮点数
float	float	float32	32 位浮点数
int32	int	int32	可变长编码，负数效率低
int64	long	int64	可变长编码，负数效率低
string	String	string	UTF-8 编码字符串
bytes	ByteString	[]byte	任意字节序列
repeated	List<T>	[]T	可变长度数组（列表）
map<K,V>	Map<K,V>	map[K]V	键值对映射

2.2 四种通信模式详解

gRPC 基于 HTTP/2 流式传输，支持四种 RPC 通信模式。理解每种模式的数据流特征和适用场景，是设计高可用接口的前提。

2.2.1 一元 RPC（Unary RPC）

客户端发送一个请求消息，服务端返回一个响应消息。这是最基础的请求-响应模式，行为与传统的 HTTP REST 接口类似。

• 数据流：客户端 → 服务端（1 次请求），服务端 → 客户端（1 次响应）
• 适用场景：创建资源、查询单条记录、简单计算
• 熔断考量：超时阈值通常设为 500ms~5s，熔断器基于请求成功率或延迟触发

2.2.2 服务端流式 RPC（Server Streaming RPC）

客户端发送一个请求，服务端返回多个响应消息（流）。客户端持续读取流直到服务端关闭。

• 数据流：客户端 → 服务端（1 次请求），服务端 → 客户端（N 次响应）
• 适用场景：批量查询、日志推送、实时数据订阅
• 熔断考量：需监控流建立成功率与消息传输延迟，避免因慢流导致连接池耗尽

2.2.3 客户端流式 RPC（Client Streaming RPC）

客户端发送多个请求消息（流），服务端返回一个响应。客户端主动关闭流后，服务端开始处理并返回结果。

• 数据流：客户端 → 服务端（N 次请求），服务端 → 客户端（1 次响应）
• 适用场景：批量上传、文件分片上传、聚合计算
• 熔断考量：流建立后若客户端发送过慢，可能触发服务端空闲超时；熔断器需感知流生命周期

2.2.4 双向流式 RPC（Bidirectional Streaming RPC）

客户端和服务端同时发送多个消息流，双方可以独立读写，顺序由应用层保证。

• 数据流：客户端 ↔ 服务端（双向 N 次消息交换）
• 适用场景：实时聊天、游戏状态同步、流式数据处理管道
• 熔断考量：双向流对连接复用和背压（backpressure）要求最高，熔断策略需结合流控与资源隔离

2.3 四种通信模式对比

通信模式	请求次数	响应次数	连接复用度	典型延迟敏感度	熔断复杂度
一元 RPC	1	1	高	高	低
服务端流式	1	N	中	中	中
客户端流式	N	1	中	中	中
双向流式	N	N	低	低	高

2.4 四种通信模式数据流示意图

下图展示了四种通信模式中客户端与服务端之间的消息交换时序与流方向。

2.5 通信模式选择与熔断降级的关系

不同的通信模式对熔断降级策略有直接影响。下表总结了各模式在熔断设计中的关键关注点：

通信模式	熔断触发条件	降级策略	恢复检测方式
一元 RPC	请求失败率 > 阈值，或 P99 延迟 > 超时	返回默认响应、缓存结果、快速失败	半开状态发送探测请求
服务端流式	流建立失败率 > 阈值，或流中断率 > 阈值	降级为轮询模式、返回静态数据流	探测流建立成功率
客户端流式	流建立失败，或服务端处理超时	本地缓存请求、批量降级为单次请求	探测小批量请求处理能力
双向流式	流建立失败、消息吞吐下降、背压堆积	断开流、切换为单向模式、降级为轮询	探测双向流建立与消息交换延迟

2.6 本章小结

• Protocol Buffers 通过 .proto 文件定义消息结构与服务接口，字段编号直接影响序列化效率。
• gRPC 支持四种通信模式：一元、服务端流、客户端流、双向流，每种模式对应不同的数据流特征。
• 通信模式的选择直接影响熔断降级策略的复杂度：一元 RPC 最简单，双向流式最复杂。
• 流式 RPC 的熔断设计需要额外关注流建立成功率、消息吞吐和背压控制。