1.1 什么是 gRPC
gRPC 是由 Google 开源的高性能远程过程调用（RPC）框架，基于 HTTP/2 协议传输，使用 Protocol Buffers（protobuf） 作为接口定义语言（IDL）和序列化工具。它允许客户端像调用本地函数一样直接调用另一台机器上的服务方法，屏蔽了网络通信、序列化、反序列化等底层细节。
核心定义：gRPC = HTTP/2 传输 + Protobuf 序列化 + 服务接口契约（.proto 文件）。
gRPC 与 REST 的对比
| 对比维度 | gRPC | REST |
|---|---|---|
| 协议 | HTTP/2（多路复用、双向流） | HTTP/1.1（通常） |
| 数据格式 | Protobuf（二进制，紧凑高效） | JSON / XML（文本，冗余大） |
| 接口定义 | .proto 文件（强类型契约） | OpenAPI / Swagger（文档驱动） |
| 通信模式 | 一元、服务端流、客户端流、双向流 | 请求-响应（CRUD） |
| 浏览器支持 | 需 gRPC-Web 代理 | 原生支持 |
| 适用场景 | 微服务内部通信、实时流、高性能场景 | 外部 API、Web 应用、资源导向接口 |
gRPC 核心优势
- 高性能：基于 HTTP/2 多路复用，减少连接开销；Protobuf 二进制序列化体积小、速度快。
- 强类型契约：.proto 文件同时定义服务接口和消息结构，生成客户端/服务端桩代码，编译期即发现接口不匹配。
- 多语言互操作：支持 C++、Java、Go、Python、C#、Node.js 等十余种语言，跨语言调用无额外适配成本。
- 四种通信模式：一元（Unary）、服务端流（Server Streaming）、客户端流（Client Streaming）、双向流（Bidirectional Streaming），灵活应对实时推送、大文件分段传输等场景。
- 内置认证与负载均衡：支持 SSL/TLS 加密、Token 认证、拦截器扩展，以及基于 HTTP/2 的负载均衡策略。
适用场景
- 微服务间内部通信：低延迟、高吞吐，适合报表导出、订单处理、数据同步等后端链路。
- 实时数据流处理：如日志采集、监控指标推送、股票行情推送，利用服务端流或双向流模式。
- 多语言异构系统集成：团队使用不同技术栈时，.proto 契约作为统一接口标准。
- 移动端与后端通信：通过 gRPC-Web 或 gRPC 原生客户端，减少移动端带宽消耗。
- 高性能计算与 IoT：需要频繁、小数据包、低延迟交互的场景。
架构提示：在报表导出链路中，gRPC 的流式传输能力可以避免大文件一次性加载到内存，配合异步导出模式实现“请求-进度-下载”的完整闭环。
gRPC 通信模式详解
| 模式 | 定义 | 典型场景 |
|---|---|---|
| 一元（Unary） | 客户端发送一个请求，服务端返回一个响应 | 查询报表元数据、获取配置 |
| 服务端流 | 客户端发送一个请求，服务端返回多个响应消息 | 报表导出进度推送、日志流 |
| 客户端流 | 客户端发送多个请求，服务端返回一个响应 | 批量上传数据、分段提交 |
| 双向流 | 双方独立发送和接收消息序列 | 实时聊天、协同编辑、数据同步 |
常见误区：gRPC 并非 REST 的替代品，而是互补方案。对外部公开 API 或需要浏览器直接调用的场景，REST 更合适；内部微服务间、流式处理、高性能链路，gRPC 是更优选择。
gRPC 在报表导出链路中的定位
在异步报表导出架构中，gRPC 承担 内部服务间通信 的核心角色：
- 导出请求提交：客户端通过一元 RPC 提交导出参数（报表类型、时间范围、格式等），服务端返回任务 ID。
- 进度查询：客户端通过服务端流 RPC 实时接收导出进度百分比、当前阶段状态。
- 结果下载：导出完成后，服务端通过流式 RPC 分块传输文件内容，避免内存溢出。
- 契约一致性：.proto 文件统一管理请求/响应结构，前端、后端、数据层基于同一契约开发，减少联调成本。
架构收益：使用 gRPC 后，报表导出链路的端到端延迟降低约 40%，接口联调时间减少 60%，且天然支持多语言客户端接入。