📚 课程目录第2章 gRPC基础回顾

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

在深入探讨拦截器与安全权限集成方案之前，必须牢固掌握 gRPC 的两大基石：Protocol Buffers（protobuf） 接口定义语言，以及 gRPC 的四种通信模式。本节将系统性地回顾这些核心概念，为后续章节的架构设计打下坚实基础。

2.1 Protocol Buffers：服务契约与数据序列化

Protocol Buffers 是 gRPC 默认的接口定义语言（IDL）与数据序列化协议。它通过 .proto 文件定义服务接口和消息结构，实现跨语言、跨平台的服务契约。

2.1.1 核心定义要素

要素	关键字/语法	说明
消息类型	`message`	定义请求/响应的数据结构，包含字段编号、类型与名称。
服务接口	`service`	定义 RPC 方法签名，包括方法名、输入消息与输出消息。
字段规则	`optional` / `repeated` / `required`（已弃用）	控制字段的基数：可选、重复列表或必填。
标量类型	`int32`, `string`, `bool`, `bytes` 等	跨语言映射的基础数据类型。
包与导入	`package` / `import`	组织命名空间，复用已有 proto 定义。

  关键设计原则： proto 文件是服务提供方与消费方之间的唯一契约。任何对消息字段的增删改，都必须遵循向后兼容规则（如不得修改已有字段编号），否则将导致序列化异常或通信断裂。

2.1.2 典型 proto 定义示例

syntax = "proto3";

package security.auth;

// 定义认证请求消息
message AuthRequest {
  string token = 1;          // JWT 令牌
  string service_name = 2;   // 目标服务标识
  int32 request_id = 3;      // 请求追踪 ID
}

// 定义认证响应消息
message AuthResponse {
  bool allowed = 1;          // 是否授权通过
  string role = 2;           // 用户角色
  int64 expires_at = 3;      // 令牌过期时间戳
}

// 定义认证服务接口
service AuthService {
  // 一元 RPC：验证令牌并返回授权结果
  rpc ValidateToken (AuthRequest) returns (AuthResponse);
}

2.2 gRPC 四种通信模式

gRPC 基于 HTTP/2 流式传输，支持四种通信模式。理解这些模式是设计拦截器逻辑（如认证、鉴权、限流）的前提，因为不同模式下的请求/响应生命周期差异显著。

模式选择依据： 一元模式适用于请求-响应原子操作；服务端流适用于推送数据（如日志、监控指标）；客户端流适用于批量上传或聚合请求；双向流适用于实时交互（如聊天、协同编辑）。

2.2.1 模式对比总览

模式	客户端请求	服务端响应	典型场景	拦截器关注点
Unary（一元）	单条消息	单条消息	用户登录、查询订单	请求/响应头拦截，一次鉴权
Server Streaming	单条消息	多条消息流	实时推送、日志订阅	请求头鉴权 + 流上下文权限校验
Client Streaming	多条消息流	单条消息	文件上传、批量数据提交	流开始鉴权 + 每条消息校验
Bidirectional Streaming	多条消息流	多条消息流	实时聊天、协同白板	全双工上下文权限持续校验

2.2.2 四种模式交互流程（SVG 架构图）

下图展示了四种通信模式下客户端与服务端之间的消息流方向与生命周期差异。拦截器在每种模式下的挂载点（箭头起点/终点）将直接影响安全策略的执行粒度。

2.3 四种模式在安全权限场景下的关键差异

在后续章节中，我们将基于拦截器实现安全权限集成。不同通信模式对拦截器的实现方式有直接影响，以下是需要重点关注的差异点：

上下文生命周期： 一元模式中，ServerContext 在单个请求-响应周期内有效；流模式中，上下文在流建立时创建，在流关闭时销毁。拦截器必须正确处理流生命周期内的权限缓存与清理。
鉴权时机： 一元模式只需在请求入口鉴权一次；流模式可能需要在每条消息到达时重新校验（如令牌是否在流传输过程中过期）。
错误传播： 流模式中，拦截器抛出的错误（如权限不足）会中断整个流，而不仅仅是当前消息。设计时需考虑错误码与流关闭语义的匹配。
性能开销： 双向流场景下，拦截器对每条消息的校验会增加延迟。需要权衡安全粒度与吞吐量，必要时引入批量校验或令牌缓存机制。

常见陷阱： 在流模式拦截器中，不要假设 context.Deadline() 或 context.Done() 的行为与一元模式完全一致。流上下文的超时控制通常由客户端发起，服务端拦截器应主动监听 ctx.Done() 以释放资源，避免 goroutine 泄漏。

2.4 小结

本节回顾了 Protocol Buffers 的定义语法与 gRPC 四种通信模式的核心交互流程。理解这些基础概念是后续实现拦截器安全方案的前提：proto 文件定义了服务契约与权限字段，而通信模式决定了拦截器的挂载点与校验粒度。在下一阶段，我们将基于这些知识，设计能够适配多种通信模式的统一拦截器架构。