嘿老张，昨儿咱俩聊天你提到那个"gRPC 比 REST 快 10 倍"的说法，我想了挺多，今天就跟你好好唠唠这个事儿。

先说个大实话

你知道我是那种喜欢刨根问底的人。第一次听到"gRPC 比 REST 快 10 倍"这个说法的时候，我也愣了一下。各种技术会议、架构讨论、性能 benchmark 里都能看到这个数字。有时候还配着漂亮的图表，有时候就是大家口口相传。

但这里头有个问题——这个说法把太多细节都给藏起来了。

就像你买车的时候销售跟你说"这车最高时速 300 公里"，听着挺厉害对吧？但你日常在城里开车，哪个路段能让你跑到 300？这不是销售骗你，是他只告诉你了一半真相。

“10 倍快"到底在说啥

咱得先搞清楚，人家说"快 10 倍"的时候，到底在测量啥。一般就这三样：

  • 吞吐量：一秒钟能处理多少请求
  • 延迟：单个请求要等多久
  • payload 敏感度：数据量变大了性能会怎么掉

大多数流传很广的 benchmark 都是盯着吞吐量看的——小请求、重复发、连接都预热好了。在这种特定的环境下，gRPC 确实能快得惊人。

但现实系统哪有这么干净的？真正干活的时候，你得关心 p95、p99 的尾部延迟，得处理各种不同的客户端行为，得做认证、重试、监控……这些东西一加进来，那个漂亮的数字很快就缩水了。

就像那个说"我跑步平均配速 4 分钟"的家伙，他没告诉你那是他在跑道上跑出来的，你让他早晚高峰在地铁里跑个 4 分钟试试？

benchmark 没说谎，但它说得不完整。

第一个根本差异：HTTP/2 vs HTTP/1.1

大多数 REST API 还在跑 HTTP/1.1。这玩意儿简单、到处都有、大家都懂——但在高并发的时候会露馅。

在 HTTP/1.1 下面，一个连接上的请求基本上是串行的。就算用了 keep-alive，还是会有 head-of-line blocking 的问题。什么意思呢？就像你在餐厅点餐，前面那个人点了个要等 10 分钟的菜，后面所有人只能等着，就算你只想买杯饮料也不行。

想要并行？多开几个连接呗。但多了就意味着更多的 TCP 握手、更多的 TLS 协商、更多的内核状态、更多的上下文切换……就像开了更多的收银台，每个台子都要配人、都要维护。

gRPC 默认就跑在 HTTP/2 上，这个完全不一样。HTTP/2 支持多路复用——一个 TCP 连接上能跑好多独立的流。这就像餐厅改革了，不再是一个收银台排队，而是每个人扫码点餐，后厨同时处理，谁先好谁先出。

HTTP/1.1 vs HTTP/2 多路复用对比 图：HTTP/1.1 串行阻塞 vs HTTP/2 多路复用

这个就消除了应用层的 head-of-line blocking。结果不只是吞吐量高了，更重要的是负载下延迟更可预测，尤其是尾部延迟。

这个可预测性，才是"gRPC 更快"这个说法的真正来源。

第二个根本差异：Protocol Buffers vs JSON

第二个性能差异来自序列化。

REST API 几乎都用 JSON。JSON 好读、灵活、容易 debug。你打开浏览器就能看，用 curl 调一下就知道返回了啥。但解析起来挺费劲。每个请求都要解析字符串、查 key、动态类型判断、分配内存……

就像你每次寄快递都要手写地址、填单子、称重、算运费，麻烦但大家都看得懂。

gRPC 用 Protocol Buffers，二进制的、schema 驱动的。字段用数字编码、布局提前就知道、解析过程避开了 JSON 的大部分开销。就像快递公司内部用的是条码扫描，啪一下就识别了，不用人工看地址。

概念上差异是这样的：

JSON 路径：解析文本 → 分配字符串 → 解码数字 → key 映射到字段 → 验证结构

Protobuf 路径：读字节 → 映射数字标签 → 赋值字段 → 完事

JSON vs Protobuf 序列化流程对比 图：JSON 解析的 5 步 vs Protobuf 的 3 步

但具体收益多少，得看你传输的数据有多大。小数据（几百字节）的时候，Protobuf 能快 3-5 倍，毕竟解析开销占比大。中等数据（几十 KB）差不多 2-3 倍，还是有差距但没那么夸张了。等到了大数据（1MB 以上），可能就 1.2-1.5 倍——这时候网络传输才是大头，序列化快不快已经不是主要矛盾了。所以 Protobuf 最大的收益其实是省 CPU 和少折腾内存，不是省网络带宽。

gRPC 的性能优势在哪儿最明显

在特定类型的系统里，gRPC 的优势才看得出来。高 QPS 的内部服务网格、低延迟的金融或交易系统、实时多人游戏或流媒体控制面，还有那些对 p99 或 p99.9 延迟有严格要求的系统。这些环境里，平均延迟反而不是最重要的，尾部延迟才是关键。p99 多几毫秒，可能导致重试、队列堆积、SLA 没达标。HTTP/2 多路复用和 Protobuf 的效率能把这些尾部平滑掉。

就像你平时开车平均时速 40 公里就够了，但如果你跑出租车，乘客在意的是最堵的时候能不能准时到达。那个尾部延迟的几公里，才是你的生死线。

尾部延迟分布曲线对比 图：平均延迟差不多，但尾部延迟（p99）差异巨大

如果你的系统不关心尾部延迟，gRPC 的大部分优势你就享受不到了。

为什么大多数团队还没换（而且是对的）

虽然性能有优势，但 REST 还是主流——不是因为大家不懂行。

gRPC 有实实在在的成本：Protobuf 生成和版本管理的工具摩擦，ad-hoc 调试更困难（不能简单 curl 一下），浏览器原生支持有限，新工程师上手更复杂。REST 最大的优势不是速度——是组织层面的简单。它和网关、日志、监控、文档、第三方客户端集成都很干净。对很多团队来说，这个简单性比内部调用快几毫秒重要多了。

就像你买车，百公里加速 3 秒是很爽，但你日常要的是好停车、维修便宜、配件好找。那些性能数据看着刺激，但你的真实需求可能是另一回事。

工程是优化整个系统，不是只优化热路径。

过度工程的陷阱

我见过太多这样的失败模式：团队看到一个 benchmark，为了性能上了 gRPC，从来没定义过真正的延迟预算，结果就是复杂度上升、on-call 调试更难、迭代变慢、用户感知不到任何改进。

没有明确约束的性能工程，就是有叙事的复杂度。

gRPC 很强大——但不需要的强大往往会反噬。就像你买了个专业咖啡机，结果每天喝速溶的，那台机器最后就变成占地方的贵重摆设。

一个不会骗你的决策框架

gRPC vs REST 决策框架 图：三个关键问题帮你做正确选择

别问"gRPC 更快吗？"，问这个：

你有严格的 p99 延迟预算（<20ms）吗？→ 是

大多数客户端是内部的、可控的？→ 是

请求是小的、频繁的、延迟敏感的？→ 是

→ gRPC 可能值得

如果你在这个流程的前面就答"no”，REST 可能是更好的选择。

性能决策应该跟着约束走，不是跟着 benchmark 走。

成功迁移的团队是怎么干的

成功采用 gRPC 的团队，一般都是渐进式的：只从内部服务开始，对外客户端还是用 REST，迁移前后都测量 p95 和 p99，只有当收益清晰且持续时才扩展。这避免了意识形态，让数据来证明复杂度的合理性。

速度是约束，不是美德

gRPC 真的可以比 REST 快 7-10 倍——在合适的条件下、对合适的 workload、用合适的纪律。

但速度本身不是美德。它是对约束的响应。

大多数团队还没换，是因为 REST 已经够快、更简单、更符合他们真正的瓶颈。这不是懒惰——这是工程判断。

Benchmark 不交付产品。trade-off 才是。

觉得这篇文章有用吗？

如果这篇文章帮你理清了 gRPC 和 REST 的选择思路，点个赞让更多人看到。转发给正在纠结这个问题的朋友或同事，关注梦兽编程不错过更多实用技术文章。有什么问题或想法？欢迎在评论区交流。

你的支持是我持续创作的最大动力！