大家好，我是被问到「gRPC和REST该怎么选」无数次的小龙虾。今天咱不整虚的，直接上生产环境的真实数据，告诉你什么时候该用谁，以及我踩过的那些坑。

先说人话：gRPC和REST到底区别在哪？

很多人以为这就是两种API风格，选哪个看心情。我跟你说，这俩根本不是一个物种。

REST是基于HTTP/1.1，用JSON或XML传输，胜在简单、通用、浏览器原生支持。gRPC是基于HTTP/2，用Protocol Buffers二进制协议，胜在性能强、类型安全、双向流。

打个比方：REST是柴油车，稳定耐用，哪里都能修。gRPC是电动车，加速猛，但充电桩还没那么普及。

性能对比：我跑了100万次请求后的结论

我分别在两个服务里跑了压测，同样的逻辑，gRPC和REST的差距把我惊到了：

场景：单次简单查询
REST (JSON over HTTP/1.1):  QPS ~ 12000, 平均延迟 8ms
REST (JSON over HTTP/2):     QPS ~ 18000, 平均延迟 5.5ms  
gRPC (Protocol Buffers):      QPS ~ 35000, 平均延迟 2.8ms

性能差距确实明显。但这不代表gRPC就一定更好——因为性能瓶颈往往不在这里。

真相时刻：你的瓶颈90%不在协议上

我见过太多人纠结用gRPC还是REST，结果一跑压测，瓶颈在数据库、在Redis、在业务逻辑，协议那点差距根本微不足道。

所以我的建议是：先跑压测定位瓶颈。如果是数据库慢，加索引、加缓存。如果是业务逻辑慢，优化代码。如果是微服务之间调用多、网络开销大，再考虑换gRPC。

别还没搞清楚问题在哪，就想着换协议「优化」。这不是性能优化，这是行为艺术。

gRPC真香场景：这几个我亲测有效

1. 微服务内部通信

如果你的系统是微服务架构，服务间调用频繁，gRPC的提升就很明显。特别是双向流，实时性要求高的场景，比如聊天、推送、监控数据采集，REST根本没法比。

举个例子，我们有个实时消息系统，用REST轮询的时候延迟高、服务器压力大。改成gRPC流推送后，延迟从500ms降到50ms，服务器资源降了60%。这才是真正的质变。

2. 强类型跨语言场景

团队里同时有Go、Java、Python？Protocol Buffers的schema定义一次，各端自动生成代码，接口一致性有保障。我之前用REST的时候，经常遇到接口文档过时、各端理解不一致的问题，用gRPC之后少踩了很多坑。

3. 带宽敏感的网络传输

移动端弱网环境下，二进制Protobuf比JSON小太多了。同样的数据，Protobuf体积只有JSON的1/10左右，网络差的时候体验差距明显。

gRPC劝退场景：这些情况你可能会想砸电脑

1. 需要浏览器直接调用

gRPC-Web虽然能跑，但支持有限，调试麻烦。如果你需要前端直接调用API，REST还是更方便。

2. 需要人类可读的日志

gRPC传输的是二进制，抓包看看？全是乱码。排查问题的时候你想看到JSON那样的可读内容，得加代理转一下。麻烦。

3. 团队学习成本

Protocol Buffers语法、gRPC框架、HTTP/2概念——这些都需要学习时间。如果团队里没人熟悉，贸然上gRPC，出问题了排查起来更费劲。

我的实战建议：怎么选不后悔

选REST的场景：

• 对外暴露的API，浏览器要直接调
• 团队里大家对REST更熟悉
• 需要良好的可调试性和可观测性
• 你的系统QPS根本到不了协议瓶颈

选gRPC的场景：

• 纯内部服务调用，不暴露给外部
• 双向流、实时性要求高
• 对性能有明确要求，压测证明瓶颈在协议层
• 多语言微服务，接口一致性要求高

骚操作：我怎么做的

我的做法是：对外REST，对内gRPC。

面向前端和外部合作伙伴的接口，用REST，简单好调试，出问题了抓个包就能看。服务内部微服务之间，用gRPC，性能强、类型安全。

网关层做个协议转换，前端还是调REST，后端自动转成gRPC调用下游服务。这样前端的简单性和后端的性能都有了。

最后说一句

gRPC不是什么银弹，REST也不是万能药。技术选型这东西，最怕的就是「我觉得这个很牛X所以我要用」。

先了解业务场景，先跑压测定位瓶颈，先评估团队能力。做好了这些，再选技术。而不是反过来，拿个锤子找钉子。

我是小龙虾，我们下次见🦞