gRPC 跟其他通信方式到底有什么区别？
先说结论：gRPC 不是“纯传输协议”，它更像一套 RPC 框架/应用层协议：
- 底层：通常跑在 HTTP/2 上（传输层还是 TCP/TLS）
- 上层：用 .proto（IDL）定义接口 + 代码生成 + Protobuf（二进制）序列化 + 统一的调用语义
gRPC 的几个“关键特征”
✅ HTTP/2：一个连接多路复用并发请求、头部压缩、流控
✅ Protobuf（二进制）：体积更小、序列化更快、强类型
✅ IDL 驱动：先写 .proto 定义 service/method/message，再生成客户端/服务端代码
✅ 原生流式：Unary / Server Stream / Client Stream / 双向 Stream
✅ 调用治理更标准：deadline/timeout、metadata、统一 status code、拦截器（middleware）
跟 REST（HTTP/1.1 + JSON）比
REST：通用、好调试、对外开放生态强
gRPC：强类型、高性能、更适合微服务内部高频调用
- REST 通常 JSON 文本：易读，但更大更慢
- gRPC 通常 Protobuf：更省带宽更快
- REST 多为 HTTP/1.1：并发多时连接/队头阻塞更明显
- gRPC 基于 HTTP/2：天然适合高并发、长连接、流式
👉 建议：
对外开放 API：REST 更友好
内部服务调用：gRPC 更香（必要时加 gateway 转 HTTP）
跟 WebSocket 比
WebSocket：双向长连接“通道”，你得自己设计消息协议、鉴权、心跳、重连、错误语义
gRPC Streaming：双向流 + RPC 语义 + 标准化 status/deadline + Protobuf
👉 建议：
IM/实时推送：WebSocket 常用
服务间流式处理/边算边推：gRPC streaming 很顺
跟消息队列（Kafka/RabbitMQ）比
这俩不是同一赛道：
- gRPC：同步/近实时 请求-响应（也支持流）
- MQ：异步解耦、削峰填谷、可靠投递、最终一致
👉 最常见组合：
在线链路用 gRPC / HTTP，异步任务用 MQ
一句话总结
- REST：对外友好、通用、易调试
- gRPC：强类型 + 高性能 + HTTP/2 + 原生流式，微服务内部首选
- WebSocket：实时双向通道（但协议治理你自己来）
- MQ：异步解耦与可靠投递（不是同步 RPC）
