1. gRPC 基础概念

gRPC 是 Google 开源的高性能远程过程调用（RPC）框架，基于 HTTP/2 协议传输，使用 Protocol Buffers 作为接口定义语言（IDL）与序列化工具。它支持多种编程语言，在微服务架构、移动端-服务端通信、IoT 等场景中广泛应用。本章从定义、对比、序列化协议、服务类型四个维度建立 gRPC 的基础认知。

1.1 gRPC 定义

gRPC 的全称是 gRPC Remote Procedure Calls，其核心思想是：客户端像调用本地函数一样直接调用远端服务器上的方法，框架负责参数序列化、网络传输、反序列化及错误处理。gRPC 默认使用 Protocol Buffers（protobuf）定义服务接口和消息结构，通过 protoc 编译器生成客户端桩（Stub）和服务器骨架（Skeleton）代码。

1.2 gRPC 与 REST 对比

REST 是资源导向的 HTTP API 风格，gRPC 是函数/服务导向的 RPC 框架。两者在协议、序列化、性能、适用场景上有显著差异。下表从多个维度进行对比：

1.3 Protocol Buffers 简介

Protocol Buffers（简称 protobuf）是 Google 开发的与语言无关、平台无关的序列化结构化数据机制。开发者通过 .proto 文件定义消息结构和服务接口，然后使用 protoc 编译器生成目标语言的代码。

一个典型的 .proto 文件示例：

syntax = "proto3";

package helloworld;

// 定义请求消息
message HelloRequest {
  string name = 1;
}

// 定义响应消息
message HelloReply {
  string message = 1;
}

// 定义服务
service Greeter {
  rpc SayHello (HelloRequest) returns (HelloReply);
}

protobuf 相比 JSON 的核心优势：

• 体积小： 二进制编码，无冗余字段名，典型体积为 JSON 的 1/3 ~ 1/10
• 速度快： 序列化/反序列化无需反射解析，CPU 开销低
• 强类型： 字段类型、编号、默认值在编译期确定，减少运行时错误
• 向后兼容： 字段编号机制支持新增/废弃字段而不破坏现有代码

1.4 gRPC 四大服务类型

gRPC 基于 HTTP/2 的流式能力，定义了四种服务通信模式。理解这些模式是设计 gRPC 接口和后续压测模型的基础。

1. Unary RPC（一元 RPC）： 客户端发送一个请求，服务器返回一个响应。语义与普通函数调用一致，是最常用的模式。
2. Server Streaming RPC（服务端流式 RPC）： 客户端发送一个请求，服务器返回一个响应流（多条消息）。适用于大文件下载、事件推送、日志流等场景。
3. Client Streaming RPC（客户端流式 RPC）： 客户端发送一个请求流（多条消息），服务器返回一个响应。适用于批量上传、数据聚合、长连接上报等场景。
4. Bidirectional Streaming RPC（双向流式 RPC）： 客户端和服务器各自独立发送流，双方可以同时读写。适用于实时聊天、游戏同步、协同编辑等场景。

下表总结了四种模式的特征：