gRPC vs REST 2026 对比：何时该用哪个？

一句话结论：内部服务通信用 gRPC，外部 API 用 REST。两者不是替代关系，而是互补关系。

背景

REST 一直是 API 主流，但 gRPC 在微服务时代崛起。2026 年的现实是：

• REST（特别是 RESTful JSON API）：80% 项目的选择
• gRPC：内部服务通信、性能敏感场景
• GraphQL：复杂前端 / 移动端
• WebSocket：实时通信

核心差异

维度	REST	gRPC
协议	HTTP/1.1 + JSON	HTTP/2 + Protobuf
性能	中	高（5-10x）
易用性	高	中
浏览器支持	原生	需 gRPC-Web
类型安全	弱	强（Protobuf 强类型）
流式通信	弱（SSE / WebSocket）	原生支持
工具生态	极丰富	较丰富

5 维度对比

1. 性能

测试场景：1000 次 UserService.GetUser 请求

REST (JSON over HTTP/1.1):
  - 平均延迟: 28ms
  - P99: 65ms
  - CPU 占用: 中
  - 数据传输: 8KB/请求

gRPC (Protobuf over HTTP/2):
  - 平均延迟: 4ms
  - P99: 12ms
  - CPU 占用: 低
  - 数据传输: 1.5KB/请求（Protobuf 二进制）

性能差距: ~7x

// Protobuf 定义（强类型）
syntax = "proto3";

service UserService {
  rpc GetUser(GetUserRequest) returns (User);
  rpc ListUsers(ListUsersRequest) returns (stream User);
  rpc CreateUser(CreateUserRequest) returns (User);
}

message User {
  int64 id = 1;
  string name = 2;
  string email = 3;
  repeated string roles = 4;
}

message GetUserRequest {
  int64 id = 1;
}

// 对应 TypeScript 类型（自动生成）
interface User {
  id: number;
  name: string;
  email: string;
  roles: string[];
}

2. 易用性

REST:
  ✅ 浏览器直接调用
  ✅ curl 测试方便
  ✅ Postman 调试方便
  ✅ 跨语言简单
  
gRPC:
  ❌ 浏览器需要 gRPC-Web
  ⚠️ 需要 .proto 文件
  ✅ 跨语言代码生成
  ✅ 类型安全

3. 流式通信

// gRPC 4 种通信模式
service ChatService {
  // 1. Unary（一元）
  rpc SendMessage(Message) returns (Ack);
  
  // 2. Server Streaming（服务端流）
  rpc Subscribe(Topic) returns (stream Message);
  
  // 3. Client Streaming（客户端流）
  rpc UploadFile(stream Chunk) returns (UploadStatus);
  
  // 4. Bidirectional Streaming（双向流）
  rpc Chat(stream Message) returns (stream Message);
}

REST 实现流式需要 SSE / WebSocket，gRPC 原生支持。

4. 类型安全

// REST: 容易出错
const response = await fetch('/api/users/123');
const user = await response.json();
// user.name? user.username? user.fullName?
// 没有类型保证

// gRPC: 强类型
const user = await client.getUser({ id: 123 });
// user.name ✅ 类型安全

5. 工具生态

REST:
  ✅ OpenAPI / Swagger（文档自动生成）
  ✅ Postman / Insomnia
  ✅ 任何 HTTP 工具
  ✅ 任何语言
  
gRPC:
  ✅ grpcurl（类似 curl）
  ✅ Evans（gRPC 客户端）
  ✅ BloomRPC（Postman 替代）
  ⚠️ 浏览器需要 gRPC-Web

实战对比

REST 服务（Node.js + Express）

// app.ts
import express from 'express';

const app = express();
app.use(express.json());

app.get('/api/users/:id', async (req, res) => {
  const user = await db.users.findUnique({ where: { id: req.params.id } });
  if (!user) return res.status(404).json({ error: 'Not found' });
  res.json(user);
});

app.post('/api/users', async (req, res) => {
  const user = await db.users.create({ data: req.body });
  res.status(201).json(user);
});

app.listen(3000);

gRPC 服务（Node.js）

// server.ts
import * as grpc from '@grpc/grpc-js';
import * as protoLoader from '@grpc/proto-loader';
import { UserService } from './proto/user_grpc';

const PROTO_PATH = './user.proto';
const packageDefinition = protoLoader.loadSync(PROTO_PATH);
const proto = grpc.loadPackageDefinition(packageDefinition) as any;

const server = new grpc.Server();

server.addService(proto.UserService.service, {
  async getUser(call, callback) {
    const user = await db.users.findUnique({ where: { id: call.request.id } });
    if (!user) return callback({ code: grpc.status.NOT_FOUND });
    callback(null, user);
  },
  
  async listUsers(call) {
    // 服务端流式
    const users = await db.users.findMany();
    for (const user of users) {
      call.write(user);
    }
    call.end();
  },
});

server.bindAsync('0.0.0.0:50051', grpc.ServerCredentials.createInsecure(), () => {
  server.start();
});

5 个真实场景选型

场景 1：对外公开 API

✅ 用 REST
- 浏览器直接调用
- 第三方接入门槛低
- OpenAPI 文档

场景 2：内部微服务通信

✅ 用 gRPC
- 性能要求高
- 强类型避免错误
- 服务间调用频繁

场景 3：实时通信

✅ 用 gRPC（流式）或 WebSocket
- gRPC：内部服务实时数据
- WebSocket：浏览器实时通信

场景 4：移动 App API

考虑：
- gRPC：性能好，节省流量（节省 50%+ 流量）
- REST：通用，调试方便
- GraphQL：复杂页面减少请求数

场景 5：IoT 设备

✅ 用 gRPC
- 性能 + 省流量
- 流式传感器数据
- 强类型避免协议错误

何时使用 gRPC-Web

浏览器直接调用 gRPC 需要 gRPC-Web：

// 浏览器端
import { GrpcWebClient } from 'grpc-web';

const client = new GrpcWebClient('https://api.example.com');
const response = await client.method('UserService/GetUser', { id: 123 });

但 gRPC-Web 有局限：

• 流式支持有限（仅 server streaming）
• 需要 Envoy 代理

替代方案：浏览器用 REST，内部 gRPC，对外通过 BFF（Backend for Frontend）。

5 个常见坑

坑 1：错误处理不一致

// REST: HTTP status code
res.status(404).json({ error: 'Not found' });

// gRPC: status code
callback({ code: grpc.status.NOT_FOUND, message: 'Not found' });

gRPC 的错误处理更规范，但需要学习 status code 体系。

坑 2：调试 gRPC 更难

REST: 浏览器 Network 面板直接看
gRPC: 需要 grpcurl 或 Evans

解决方案：

• 开发环境用 REST（便于调试）
• 生产环境用 gRPC（性能优先）

坑 3：版本兼容

// Protobuf 兼容规则：
// - 不能修改字段编号
// - 不能删除 required 字段
// - 可以加新字段

message User {
  int64 id = 1;
  string name = 2;
  string email = 3;  // 新增字段，向后兼容
}

坑 4：过度使用

// ❌ 反面：所有 API 都用 gRPC
// 即使是简单的 CRUD

// ✅ 正面：按需使用
// - 内部高频调用：gRPC
// - 简单 CRUD：REST
// - 公开 API：REST（必须）

坑 5：忽略生态兼容性

有些客户端库不支持 gRPC：
- 老版本浏览器
- 部分 IoT 设备
- 部分 SaaS 平台

→ 对外仍用 REST（兼容性优先）

我的看法

2026 年的 API 选型：

✅ 默认：REST（兼容性好）
✅ 内部微服务：gRPC
✅ 复杂前端：考虑 GraphQL
✅ 实时通信：gRPC Stream 或 WebSocket
✅ 移动 App：gRPC（性能）或 REST（兼容）

gRPC 不是 REST 的替代，而是特定场景的优化。

混合架构：

外部 API: REST（OpenAPI 文档）
   ↓
BFF（Backend for Frontend）
   ↓
内部服务: gRPC
   ↓
数据库

我的建议：

1. 新项目从 REST 开始：易上手、工具丰富
2. 遇到性能瓶颈再考虑 gRPC
3. 微服务内部统一用 gRPC
4. 公开 API 保持 REST

参考

• gRPC 官方文档
• Protocol Buffers 指南
• REST API 设计最佳实践
• gRPC-Web 文档

---

本文性能数据基于 2026 年 6 月实测，AWS c5.xlarge 实例 + 1KB payload。