一、什么是gRPC
gRPC 是由 Google 于 2015 年开源的高性能、跨语言远程过程调用（RPC）框架，基于 HTTP/2 传输协议与 Protocol Buffers（Protobuf）序列化协议，提供强类型、流式调用、低延迟等特性，是现代微服务间通信的事实标准之一。gRPC 适合服务间高频、低延迟、强契约的通信需求，与 REST 面向公开 API、Message Queue 面向异步事件形成互补。
二、原理
1. Protobuf IDL：用 .proto 文件定义强类型接口 → 2. 代码生成：protoc 生成多语言客户端/服务端 stub → 3. HTTP/2 传输：基于 HTTP/2 多路复用与头部压缩 → 4. 四种通信模式：Unary、Server Streaming、Client Streaming、Bidi Streaming → 5. 拦截器与元数据：横切关注点统一处理 → 6. 负载均衡与重试：客户端负载均衡策略
三、信息卡片
| 中文名 | gRPC 远程过程调用框架 |
| 英文名 | gRPC |
| 缩写 | — |
| 别名 | gRPC 框架、Google RPC、Protobuf RPC |
| 提出者 | Google（基于 Stubby 内部 RPC 框架） |
| 提出时间 | 2015 年开源 |
| 所属类别 | IT 基础架构 > 软件架构 > RPC 框架 |
| 核心技术 | Protobuf IDL、HTTP/2 传输、流式调用、代码生成 |
| 主要应用 | 微服务通信、移动端 API、Service Mesh、低延迟通信 |
四、历史时间线
- 2015 年：Google 开源 gRPC 1.0
- 2016 年：gRPC 成为 CNCF 孵化项目
- 2018 年：gRPC-Web 让浏览器支持 gRPC（通过 Envoy 代理）
- 2020 年：gRPC 集成 Service Mesh，Envoy 原生支持
- 2022 年：Connect-RPC（gRPC 简化版）发布，降低 gRPC 使用门槛
- 2024-2025 年：gRPC 已成为云原生微服务通信的事实标准之一，主流 Service Mesh 与 API Gateway 均原生支持
五、分类
按通信模式：Unary vs Server Streaming vs Client Streaming vs Bidi Streaming
- 按语言：Go、Java、Python、C++、Node、Ruby、Rust 等原生支持
- 按传输：HTTP/2（默认）vs HTTP/3 实验支持
- 按使用形态：原生 gRPC vs gRPC-Web vs Connect-RPC
- 按生态：gRPC 官方 vs grpc-dotnet vs grpc-spring
六、应用场景
- 微服务通信：服务间高频、低延迟、强契约通信
- 移动端 API：移动 App 与后端服务通信
- Service Mesh：Envoy、Istio 等原生支持 gRPC 协议
- 跨语言协作：多语言微服务统一通信
- 实时流式：音视频、AI 推理流式响应
七、优缺点
优点：高性能：HTTP/2 + Protobuf 比 REST/JSON 性能提升 5-10 倍；强类型契约：Protobuf 接口即文档，编译期错误检查；流式通信：原生支持双向流，适合实时场景；跨语言：10+ 语言代码生成，跨语言协作无缝；云原生友好：与 Service Mesh、Envoy 等深度集成
- 缺点：浏览器支持弱：浏览器原生无法直接调用 gRPC（需 gRPC-Web）；可读性差：二进制格式调试不如 JSON 直观；学习成本：Protobuf IDL 与四种通信模式需要学习；工具链：相比 REST 生态略小
八、常见误区
- gRPC 取代 REST（错：gRPC 适合内部服务通信，REST 适合公开 API）
- gRPC 必须用 Protobuf（部分对：也支持 JSON、FlatBuffers 等替代编码）
- gRPC 浏览器可直接调用（错：浏览器原生不支持，需要 gRPC-Web 或 Envoy 代理）
- gRPC 性能一定优于 REST（部分对：在高频、低延迟场景优势明显，但简单 CRUD 差距不大）
九、关联概念
- 父概念：RPC 远程过程调用、Microservices · 微服务
- 子概念：Protobuf、HTTP/2、Streaming
- 兄弟概念：RESTful API、GraphQL、Thrift
- 对比概念：gRPC vs REST、gRPC vs GraphQL、gRPC vs Thrift
- 应用相关：Service Mesh服务网格、Microservices · 微服务、Envoy
