在微服务或分布式系统中，HTTP（尤其是 RESTful API）已经非常够用，但很多团队/公司仍然选择引入 RPC（如 gRPC、Dubbo、Thrift 等），核心不是“HTTP 不行”，而是在特定场景下 RPC 能带来显著的性能、开发体验和可维护性提升。
简单一句话总结：
HTTP 像一辆通用家用轿车，够稳、够通用、到处都能开；RPC 像一辆为赛道优化的跑车，速度更快、操控更精准，但需要更专业的“赛道”（内部服务调用）。
下面从实际维度对比，为什么“HTTP 够了还要 RPC”。
HTTP vs RPC 核心对比（2025–2026 视角）
| 维度 | HTTP / REST (典型实现) | RPC (典型 gRPC / Dubbo) | 谁胜出？ & 为什么在微服务中 RPC 更受欢迎 |
|---|---|---|---|
| 性能（延迟 & 吞吐） | 中等（HTTP/1.1 头大、文本 JSON、连接复用弱） HTTP/2 改善但仍有限 | 极高（HTTP/2 + 多路复用 + 二进制 Protobuf/Thrift） 延迟可低 5–10x，吞吐高 2–5x | RPC 碾压（内部高频调用场景下差距明显） |
| 序列化效率 | JSON（文本、可读，但体积大、解析慢） | Protobuf / Thrift / Avro（二进制，体积小 3–10x，序列化快 5–20x） | RPC 完胜（带宽 & CPU 节省显著） |
| 传输协议 | HTTP/1.1 或 HTTP/2 | HTTP/2（gRPC）或自定义 TCP（如 Dubbo） | RPC 更充分压榨 HTTP/2 潜力 |
| 接口定义 & 代码生成 | OpenAPI/Swagger（手动维护，易出错） | .proto / IDL 文件 → 自动生成强类型客户端/服务端代码 | RPC 开发体验更好（类型安全、自动补全） |
| 错误处理 | HTTP 状态码 + 自定义 body | 标准化的 Status + 富错误信息（gRPC 有详细 code/message/details） | RPC 更精细、可扩展 |
| 流式支持 | HTTP/2 streaming 支持，但 REST 生态弱 | 原生支持双向/客户端/服务端流（gRPC streaming） | RPC 明显更好（实时数据、聊天、大文件） |
| 向后兼容 & 演进 | 字段新增/删除较友好（JSON 宽松） | Protobuf 支持向前/向后兼容（字段编号机制） | 两者相当，但 Protobuf 更严格 |
| 生态 & 调试 | 极其丰富（Postman、浏览器、curl、各种工具） | 专用工具（BloomRPC、gRPCurl），但不如 HTTP 通用 | HTTP 完胜（对外接口首选） |
| 适用场景 | 对外 API、浏览器调用、异构系统、简单查询 | 内部服务间高频调用、性能敏感、强类型需求 | — |
真实场景下“为什么要 RPC”的典型理由
- 性能瓶颈场景（最常见理由）
- 微服务内部调用链路长（10–20 次调用/请求）
- 每多 1ms 延迟 → 整体 RT 累加 10–20ms
- gRPC 在小包高频场景下可比 REST 快 5–50x（2025 年多个 benchmark 显示平均 5–10x）
- 强类型 & 开发效率
- 用 .proto 定义接口 → 全自动生成多语言客户端
- 编译期就能发现参数类型错、字段漏传
- REST + OpenAPI 虽然也能生成，但维护成本更高、类型安全弱
- 流式 & 双向通信
- 实时日志推送、AI 流式生成、视频/语音传输
- REST 实现 streaming 麻烦，gRPC 原生支持 server/client/bidi streaming
- 公司内部统一规范
- 大厂（如阿里、字节、腾讯）内部服务几乎全用 RPC（Dubbo / gRPC）
- 对外才暴露 REST/HTTP（网关层做转换）
- 资源成本敏感
- 节省带宽（Protobuf 体积小）
- 节省 CPU（序列化/反序列化更快）
- 云上省钱明显（流量费用、实例数）
什么时候 HTTP 就真的够了？
- 服务间调用频率低（日活 < 10w、QPS < 1k）
- 对外接口为主（浏览器、移动端、第三方对接）
- 团队小、异构语言多、优先调试便利性
- 追求极简（只用 Spring Boot + REST 就行）
2025–2026 年主流混合做法
- 对外：统一用 HTTP/REST（或 GraphQL） → 通过 Gateway（如 Spring Cloud Gateway / Kong / Nginx）
- 对内：高频/性能敏感路径用 RPC（gRPC / Dubbo）
- 网关转换：Gateway 层做 HTTP → gRPC 协议转换（很多公司这么干）
一句话结论：
HTTP 通用、易调试、生态好，适合对外和简单场景；RPC 性能更高、类型更安全、适合内部高频调用。
“够用”不等于“最优”，很多公司选择 RPC 就是为了在规模化后把“够用”升级到“极致高效”。
你们公司内部服务调用是用 HTTP 还是已经切 gRPC/Dubbo 了？性能有没有成为瓶颈？可以聊聊具体场景，我帮你分析值不值得引入 RPC。
