你好，我是码哥，《Redis 高手心法》畅销书作者，可以叫我靓仔

gRPC vs REST

新项目启动，技术方案评审，架构师问一句：「内部服务间通信你打算用什么协议？」

很多 2-3 年经验的工程师这时候会说：「REST 比较通用，但 gRPC 性能好，我们可以先用 REST 后面再迁……」

这个答案在架构师眼里等于没答。

我见过太多团队因为这种模糊判断，三个月后陷入两种困境：要么内部微服务全用 REST，接口联调堆满 DTO 转换，序列化开销吃掉了 20% 的 CPU；要么一上来全用 gRPC，对外接口也用，结果移动端 SDK 调试两周没跑通，产品催着上线。

这篇文章给出的结论很明确：内部服务间通信用 gRPC，对外 API 用 REST。这条线不是拍脑袋，后面会用数据和具体原因说清楚。

---

先给出答案

如果你时间紧，先看这张表：

你的场景	推荐协议	核心理由
微服务之间的内部调用	gRPC	性能高、强类型契约、天然流式支持
对外暴露的业务 API（Web/App 消费）	REST	生态成熟、调试方便、前端直接用
需要浏览器直接调用	REST	grpc-web 需要 Envoy 代理，复杂度高不值得
实时数据流（日志、监控、音视频）	gRPC	双向流式通信是核心能力，REST 做不到
第三方开放平台 API	REST	开发者体验优先，REST + OpenAPI 文档生成是行业标准
IoT 设备上报数据	gRPC  或 MQTT	Protobuf 体积小，弱网环境友好

一句话总结：以服务通信边界为核心——跨组织/跨端边界用 REST，组织内部的服务网格用 gRPC。

它们分别在解决什么问题

理解这两个东西为什么会同时存在，要从它们的设计初衷说起。

REST 诞生于 2000 年 Roy Fielding 的博士论文。它的设计目标是互联网级别的可扩展性——任何人用任何语言，拿到一个 URL 就能调用。HTTP + JSON 的组合让接口描述几乎不需要额外文档，curl 一条命令就能测试。这种「人可读、工具无关」的特性，使它在对外 API 领域几乎无可替代。

gRPC 是 Google 2015 年开源的 RPC 框架，脱胎于 Google 内部使用了十年的 Stubby。设计目标完全不同：高效的机器间通信。Google 内部每天有数十亿次 RPC 调用，每一毫秒的序列化开销乘以这个量级都是真金白银。它用 Protobuf 替代 JSON，用 HTTP/2 替代 HTTP/1.1，牺牲了人类可读性，换来机器处理效率。

两个东西解决的是不同层次的问题。REST 优化的是「接口契约的可理解性和互操作性」，gRPC 优化的是「服务间通信的效率和类型安全」。

性能到底差多少？有数字

很多文章在这里用「gRPC 性能更好」一句话带过。我们看具体数字。

序列化体积对比

同样一条用户数据：{id: 1001, name: "Alice", email: "alice@example.com", age: 28}

• JSON 编码：约 68 字节

• Protobuf 编码：约 28 字节（约小 2.4 倍）

复杂嵌套对象（如订单详情含商品列表）差距更大，Protobuf 通常比 JSON 小 3-10 倍。

序列化速度对比

根据 Protobuf 官方 benchmark 和社区测试数据：

操作	JSON（Jackson）	Protobuf	倍数
序列化 100 万次	~1800ms	~320ms	5.6x 更快
反序列化 100 万次	~2100ms	~400ms	5.3x 更快

测试环境：JVM，Intel Core i7，数据来自 github.com/eishay/jvm-serializers

吞吐量对比

在微服务场景下，Uber Engineering 分享的内部测试 显示，在 p99 延迟相同的条件下，gRPC 的吞吐量约是 REST/JSON 的 5-8 倍。

这个倍数听起来吓人，但要注意一件事：这个差距在低频调用场景下几乎感知不到。如果你的接口 QPS 是 100，REST 20ms，gRPC 4ms，这 16ms 的差距对用户体验没有任何影响。

差距真正暴露是在两种情况下：

1. 高频调用：服务间每秒数万次 RPC，序列化开销累积成明显的 CPU 负担

2. 大 payload：如批量数据同步、推荐系统特征向量传输，体积差异直接影响带宽成本

gRPC 的真实优势：不只是性能

很多工程师选 gRPC 只想到性能，但实际上 gRPC 对工程质量的提升更值钱。

强类型契约，消灭接口文档漂移

REST + JSON 的典型问题：接口文档和代码实现脱节。字段改了名字，文档没更新，联调时浪费一下午排查。

gRPC 的 .proto 文件就是代码，客户端和服务端都从同一份 proto 文件生成代码。字段类型、是否必填、枚举值——全部强制一致。

// user.proto
syntax = "proto3";

package user.v1;

service UserService {
rpc GetUser (GetUserRequest) returns (User);
rpc ListUsers (ListUsersRequest) returns (stream User); // 服务端流式
}

message GetUserRequest {
int64 user_id = 1;
}

message User {
int64 id = 1;
string name = 2;
string email = 3;
  UserStatus status = 4;  // 枚举，不会出现魔法字符串
}

enum UserStatus {
  USER_STATUS_UNSPECIFIED = 0;
  USER_STATUS_ACTIVE = 1;
  USER_STATUS_INACTIVE = 2;
}

这份 proto 文件提交到 Git，任何字段变更都走 code review。接口漂移的问题从根本上解决。

流式通信，REST 真的做不到

REST 是请求-响应模型，想做实时推送要靠 SSE 或 WebSocket，不在 REST 规范里。gRPC 原生支持四种通信模式：

模式	说明	适用场景
Unary RPC	普通请求-响应	80% 的场景
Server Streaming	服务端持续推送	实时日志、数据订阅
Client Streaming	客户端持续上传	文件上传、数据采集
Bidirectional Streaming	双向实时通信	聊天、协同编辑、游戏

多语言代码生成，微服务异构不是问题

protoc 支持生成 Go、Java、Python、Node.js、Rust、C++、Swift 等十几种语言的客户端代码。团队里 Go 写服务端，Java 写消费端，不需要手写 HTTP client，直接用生成的 stub。

REST 的真实优势：别急着抛弃它

gRPC 有这么多好处，是不是所有接口都该迁移？不是。

调试体验是 REST 的护城河

REST 接口用 curl、Postman、浏览器 DevTools 都能直接测。gRPC 要用 grpcurl、BloomRPC 或 gRPC UI，出了问题 Wireshark 抓包看到的是二进制，不是可读的 JSON。

这在排查生产问题时影响非常大。凌晨三点报警，你更想对着 JSON 日志还是 Protobuf 二进制？

浏览器直接调用 gRPC 问题很多

标准 gRPC 使用 HTTP/2 的特性，浏览器的 Fetch API 没有暴露对应的底层控制能力，不能直接调用 gRPC 服务。解决方案是 gRPC-Web，但它需要在前端和 gRPC 服务之间加一层 Envoy 代理做协议转换。

这套架构能跑，但增加了运维复杂度。对外的 Web API，REST 才是正确选择。

生态成熟度没得比

REST + OpenAPI 的文档自动生成（Swagger）、Mock 工具、测试框架、API 网关集成——几乎每个工具链都原生支持。gRPC 这些年追上来很多，但对于对外开放平台，REST 的开发者体验还是更好。

---

综合评分

评估维度	gRPC	REST	说明
原始性能（吞吐/延迟）	★★★★★	★★★	gRPC 领先 5-8x
序列化效率	★★★★★	★★★	Protobuf 比 JSON 快 5x+
调试便利性	★★	★★★★★	REST 完胜
浏览器支持	★★	★★★★★	gRPC-Web 需要额外代理
流式通信	★★★★★	★★	gRPC 原生支持，REST 需要 hack
类型安全	★★★★★	★★★	proto 契约 vs OpenAPI（非强制）
上手成本	★★★	★★★★★	gRPC 需要学 proto + 工具链
第三方生态	★★★★	★★★★★	REST 更成熟
多语言支持	★★★★★	★★★★★	两者都很好

真实踩坑：迁移到 gRPC 前要想清楚的事

踩坑一：Proto 字段删除导致的静默错误

Protobuf 向后兼容的规则是：老字段只能废弃（用 reserved 标记），不能直接删除并复用字段编号。

message User {
  reserved 3;              // 原来的 phone 字段，删掉了但编号要保留
  reserved "phone";        // 字段名也要保留，防止被复用

  int64 id = 1;
  string name = 2;
  // int64 phone = 3;      // 不能删了直接复用 3 号
  string address = 4;      // 新字段用新编号
}

没处理好这个，新老版本服务共存时会出现字段解析到错误值的 bug，而且不报错。我们生产环境踩过，排查了半天。

踩坑二：gRPC 的错误码不是 HTTP 状态码

gRPC 有自己的状态码体系（OK、INVALID_ARGUMENT、NOT_FOUND、INTERNAL 等共 17 个），和 HTTP 4xx/5xx 不一样。如果你的错误处理、监控告警都是基于 HTTP 状态码建的，接入 gRPC 需要重新适配。

// Go gRPC 服务端返回错误的正确方式
import"google.golang.org/grpc/codes"
import"google.golang.org/grpc/status"

func (s *UserServer) GetUser(ctx context.Context, req *pb.GetUserRequest) (*pb.User, error) {
    user, err := s.db.FindUser(req.UserId)
    if err != nil {
        if errors.Is(err, ErrNotFound) {
            // 用 gRPC 状态码，不是 HTTP 404
            returnnil, status.Errorf(codes.NotFound, "user %d not found", req.UserId)
        }
        returnnil, status.Errorf(codes.Internal, "database error: %v", err)
    }
    return user, nil
}

踩坑三：负载均衡器对 HTTP/2 的支持

gRPC 基于 HTTP/2，很多传统 L4 负载均衡器（比如 AWS Classic ELB）对 HTTP/2 多路复用的支持有问题——会把所有 gRPC 请求都路由到同一个后端实例，负载均衡变成摆设。

要用支持 HTTP/2 的 L7 负载均衡器（AWS ALB、Nginx 1.13.10+、Envoy）或者在客户端做负载均衡（配合服务发现）。

我的建议

经历过几次从 REST 迁 gRPC 的完整项目后，我的判断是：

新建微服务项目，内部服务间直接用 gRPC，不要「先 REST 以后再迁」。 迁移的代价远比你想象的大——不只是改接口，还有监控体系、错误处理、日志格式、API 网关配置全套都要动。从一开始就选对，比中途迁移省事得多。

对外接口，就算内部全是 gRPC，也要在边界层转成 REST。 最干净的做法是 gRPC 做内部服务网格，在 API Gateway 层统一转换为 REST 对外暴露。这条架构线不要打破。

REST 没有落后，只是应用层不同。 看到有人说「gRPC 是 REST 的替代品」就应该警惕——这是不理解它们设计目标差异的说法。2026 年 Stack Overflow 调查，REST API 使用率仍然超过 80%，不是大家保守，而是 REST 在它该用的地方确实是最优解。

选型不是技术比拼，是用合适的工具解决合适的问题。这条边界划清楚了，比任何 benchmark 数字都管用。

常见问题

Q：现有项目全是 REST，值得迁移到 gRPC 吗？

A：看 QPS 和服务数量。单体应用或 QPS 在万级以下、服务数在 10 个以内的项目，迁移收益基本覆盖不了成本。真正值得迁移的场景是：高频服务间调用（单个服务日均亿级请求），或者跨语言服务数量超过 5 个（proto 的代码生成能显著减少维护成本）。

Q：gRPC 能用 JSON 序列化而不是 Protobuf 吗？

A：可以，gRPC 支持 grpc-json-transcoding，也可以用 google.golang.org/protobuf/encoding/protojson 把 proto message 序列化成 JSON。但这样你就把 gRPC 最核心的性能优势放弃了——通常是为了兼容不支持 Protobuf 的系统做过渡方案，不建议作为长期选择。

Q：GraphQL 在这个对比里处于什么位置？

A：GraphQL 是另一个维度的工具，主要解决「前端按需取数据、避免多次请求」的问题。和 REST/gRPC 的对比不在同一层——GraphQL 通常跑在 REST over HTTP 上，关注的是查询灵活性，不是传输效率。如果你的核心痛点是前端多次 round-trip，可以考虑 GraphQL，但它不是 gRPC 的替代品。

Q：gRPC-Web 成熟了吗？可以在生产用了吗？

A：技术上已经稳定，Improbable、Square 等公司在生产用了。但架构复杂度不低——需要 Envoy 或其他代理做 HTTP/1.1 到 HTTP/2 的协议翻译，调试链路变长。如果团队有 Envoy 运维经验，可以上；否则对外接口还是 REST 更省事。真正的 gRPC over fetch（不需要代理）还在草案阶段，预计 2026 年底会有更成熟的方案。

Q：Protobuf 文件如何管理版本？团队协作怎么做？

A：推荐用独立的 proto 仓库（或 monorepo 里的 proto/ 目录），配合 Buf（buf.build）做 lint 和破坏性变更检测。Buf 会在 CI 里拦截破坏向后兼容的字段变更，是目前最好的 proto 工程化工具。buf breaking --against .git#branch=main 这条命令加到 CI pipeline 里，字段删除、类型变更这类问题会在合并前暴露。

关注我，超多硬核知识

参考资料

• gRPC 官方文档

• Protocol Buffers 官方文档

• gRPC vs REST Performance Benchmarks - jvm-serializers

• Buf — Protobuf 工程化工具

• Uber Engineering: Introducing Hive for gRPC

• gRPC-Web: Bringing gRPC to the Browser