你好我是码哥《Redis 高手心法》畅销书作者可以叫我靓仔gRPC vs REST新项目启动技术方案评审架构师问一句「内部服务间通信你打算用什么协议」很多 2-3 年经验的工程师这时候会说「REST 比较通用但 gRPC 性能好我们可以先用 REST 后面再迁……」这个答案在架构师眼里等于没答。我见过太多团队因为这种模糊判断三个月后陷入两种困境要么内部微服务全用 REST接口联调堆满 DTO 转换序列化开销吃掉了 20% 的 CPU要么一上来全用 gRPC对外接口也用结果移动端 SDK 调试两周没跑通产品催着上线。这篇文章给出的结论很明确内部服务间通信用 gRPC对外 API 用 REST。这条线不是拍脑袋后面会用数据和具体原因说清楚。先给出答案image-20260322211840586如果你时间紧先看这张表你的场景推荐协议核心理由微服务之间的内部调用gRPC性能高、强类型契约、天然流式支持对外暴露的业务 APIWeb/App 消费REST生态成熟、调试方便、前端直接用需要浏览器直接调用RESTgrpc-web 需要 Envoy 代理复杂度高不值得实时数据流日志、监控、音视频gRPC双向流式通信是核心能力REST 做不到第三方开放平台 APIREST开发者体验优先REST OpenAPI 文档生成是行业标准IoT 设备上报数据gRPC或MQTTProtobuf 体积小弱网环境友好一句话总结以服务通信边界为核心——跨组织/跨端边界用 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 性能更好」一句话带过。我们看具体数字。image-20260322212132168序列化体积对比同样一条用户数据{id: 1001, name: Alice, email: aliceexample.com, age: 28}JSON 编码约68 字节Protobuf 编码约28 字节约小2.4 倍复杂嵌套对象如订单详情含商品列表差距更大Protobuf 通常比 JSON小 3-10 倍。序列化速度对比根据 Protobuf 官方 benchmark 和社区测试数据操作JSONJacksonProtobuf倍数序列化 100 万次~1800ms~320ms5.6x 更快反序列化 100 万次~2100ms~400ms5.3x 更快测试环境JVMIntel Core i7数据来自 github.com/eishay/jvm-serializers吞吐量对比在微服务场景下Uber Engineering 分享的内部测试 显示在 p99 延迟相同的条件下gRPC 的吞吐量约是 REST/JSON 的5-8 倍。这个倍数听起来吓人但要注意一件事这个差距在低频调用场景下几乎感知不到。如果你的接口 QPS 是 100REST 20msgRPC 4ms这 16ms 的差距对用户体验没有任何影响。差距真正暴露是在两种情况下高频调用服务间每秒数万次 RPC序列化开销累积成明显的 CPU 负担大 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 APIREST 才是正确选择。生态成熟度没得比REST OpenAPI 的文档自动生成Swagger、Mock 工具、测试框架、API 网关集成——几乎每个工具链都原生支持。gRPC 这些年追上来很多但对于对外开放平台REST 的开发者体验还是更好。综合评分评估维度gRPCREST说明原始性能吞吐/延迟★★★★★★★★gRPC 领先 5-8x序列化效率★★★★★★★★Protobuf 比 JSON 快 5x调试便利性★★★★★★★REST 完胜浏览器支持★★★★★★★gRPC-Web 需要额外代理流式通信★★★★★★★gRPC 原生支持REST 需要 hack类型安全★★★★★★★★proto 契约 vs OpenAPI非强制上手成本★★★★★★★★gRPC 需要学 proto 工具链第三方生态★★★★★★★★★REST 更成熟多语言支持★★★★★★★★★★两者都很好真实踩坑迁移到 gRPC 前要想清楚的事image-20260322212252556踩坑一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 服务端返回错误的正确方式 importgoogle.golang.org/grpc/codes importgoogle.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 的代码生成能显著减少维护成本。QgRPC 能用 JSON 序列化而不是 Protobuf 吗A可以gRPC 支持grpc-json-transcoding也可以用google.golang.org/protobuf/encoding/protojson把 proto message 序列化成 JSON。但这样你就把 gRPC 最核心的性能优势放弃了——通常是为了兼容不支持 Protobuf 的系统做过渡方案不建议作为长期选择。QGraphQL 在这个对比里处于什么位置AGraphQL 是另一个维度的工具主要解决「前端按需取数据、避免多次请求」的问题。和 REST/gRPC 的对比不在同一层——GraphQL 通常跑在 REST over HTTP 上关注的是查询灵活性不是传输效率。如果你的核心痛点是前端多次 round-trip可以考虑 GraphQL但它不是 gRPC 的替代品。QgRPC-Web 成熟了吗可以在生产用了吗A技术上已经稳定Improbable、Square 等公司在生产用了。但架构复杂度不低——需要 Envoy 或其他代理做 HTTP/1.1 到 HTTP/2 的协议翻译调试链路变长。如果团队有 Envoy 运维经验可以上否则对外接口还是 REST 更省事。真正的 gRPC over fetch不需要代理还在草案阶段预计 2026 年底会有更成熟的方案。QProtobuf 文件如何管理版本团队协作怎么做A推荐用独立的 proto 仓库或 monorepo 里的proto/目录配合 Bufbuf.build做 lint 和破坏性变更检测。Buf 会在 CI 里拦截破坏向后兼容的字段变更是目前最好的 proto 工程化工具。buf breaking --against .git#branchmain这条命令加到 CI pipeline 里字段删除、类型变更这类问题会在合并前暴露。关注我超多硬核知识参考资料gRPC 官方文档Protocol Buffers 官方文档gRPC vs REST Performance Benchmarks - jvm-serializersBuf — Protobuf 工程化工具Uber Engineering: Introducing Hive for gRPCgRPC-Web: Bringing gRPC to the Browser