gRPC 与 REST 接口设计对比与选型实战

一、背景

微服务之间怎么通信，是架构设计绕不开的问题。最常见的选择是 REST（基于 HTTP/JSON） 与 gRPC（基于 HTTP/2 + Protobuf）。两者不是孰优孰劣，而是适配不同场景。本文从协议、性能、契约、工程实践几个角度讲清差异，给出选型建议。

二、REST 快速回顾

REST 以资源为中心，用 HTTP 动词（GET/POST/PUT/DELETE）操作资源，通常用 JSON 传输。

GET /users/123 HTTP/1.1
Host: api.example.com
Accept: application/json

{ "id": 123, "name": "Tom", "email": "tom@example.com" }

优点：

• 通用、直观，浏览器/移动端/curl 都能直接用。
• 生态成熟，网关、缓存、监控工具都天然支持 HTTP。
• 调试方便，人可读。

缺点：

• JSON 文本冗余、序列化开销大。
• 没有强类型契约（除非额外交 OpenAPI）。
• HTTP/1.1 下多路复用弱，高并发小请求效率一般。

三、gRPC 快速回顾

gRPC 用 Protobuf 定义服务与消息，基于 HTTP/2 传输二进制。

syntax = "proto3";

service UserService {
  rpc GetUser (GetUserRequest) returns (User);
}

message GetUserRequest { int64 id = 1; }
message User { int64 id = 1; string name = 2; string email = 3; }

优点：

• 强类型契约：.proto 就是接口定义，自动生成多语言客户端/服务端代码，天然防“接口对不上”。
• 高性能：二进制编码体积小、序列化快；HTTP/2 多路复用，单连接并发多个请求。
• 支持流式：unary、server streaming、client streaming、双向 streaming 四种模式。
• 内置 deadline、超时、元数据、状态码。

缺点：

• 二进制不便人工调试（需要工具）。
• 浏览器直接调用支持有限（gRPC-Web 需代理）。
• 学习成本、工具链比 REST 重。

四、关键维度对比

五、怎么选

• 对外 API / 浏览器 / 第三方集成 / 简单 CRUD → REST。通用性、可调试性、生态是刚需。
• 内部微服务间高频调用 / 低延迟 / 强契约 / 流式 → gRPC。性能与类型安全收益明显。
• 混合架构很常见：对外 REST（或 GraphQL），对内 gRPC，通过 API 网关把外部 REST 转成内部 gRPC。

六、工程实践要点

1. 契约先行：gRPC 用 .proto 做单一事实源；REST 用 OpenAPI 保证文档与实现一致。
2. 向后兼容：Protobuf 字段编号一旦发布不要复用/改类型，只能新增；删字段用 reserved。
3. 超时与重试：gRPC 用 deadline，REST 用客户端超时；重试要幂等且带退避。
4. 错误语义：gRPC 用状态码（如 INVALID_ARGUMENT、UNAVAILABLE）；REST 用 HTTP 状态码 + 业务错误体。
5. 可观测性：统一的 trace id 透传（gRPC metadata / HTTP header），链路追踪对两者都必需。
6. 网关转换：用 grpc-gateway 或 Envoy 把 REST↔gRPC 互转，兼顾外部易用与内部高效。

七、常见坑

1. 为了“先进”全量上 gRPC：结果浏览器端要额外代理、调试困难，得不偿失。
2. REST 不做契约/版本管理：接口随意改导致调用方连环崩，务必 OpenAPI + 版本策略。
3. 忽略 HTTP/2 依赖：gRPC 需要 HTTP/2，老旧代理/负载均衡可能不支持。
4. 流式滥用：双向流很强但状态管理复杂，非必要不引入。
5. payload 塞大对象：无论哪种协议，单条消息过大都会拖慢，注意分页/分块。

八、总结

REST 胜在通用与简单，gRPC 胜在性能与契约。 选型看边界：跨团队/对外开放用 REST，内部高频调用用 gRPC；大系统通常是“外 REST、内 gRPC、网关转换”的组合。真正的关键是契约管理、版本兼容与可观测性——协议只是手段，稳定的接口治理才是目标。