后端接口除了 HTTP，还有什么？

一次讲清 RPC、Dubbo、gRPC、消息队列、GraphQL、WebSocket 的技术分享

在很多团队中，当我们讨论“接口”时，大家默认想到的几乎是 RESTful 的 HTTP + JSON。

但在真正的后端系统里，HTTP 其实只是众多接口方式中的其中一种。 高性能、低延迟、微服务内部调用、实时消息推送、数据流处理…… 这些需求往往需要完全不同的通信方式。

一个成熟的后端系统，接口绝不止 HTTP 一种选择。 不同方案，是为不同问题而生的。

本文就用一篇技术分享，系统梳理： 除了 HTTP，还有哪些常用接口？它们适合什么场景？与 HTTP 有什么本质差异？

📌 全文结构

1. 接口类型全景图
2. RPC（gRPC、Dubbo、Thrift）详解
3. 消息队列（Kafka、RabbitMQ…）详解
4. GraphQL 与 REST 的对比
5. WebSocket/MQTT 等实时接口
6. SOAP（企业级遗留）
7. 与 HTTP 的核心对比
8. 选型建议 + 场景示例
9. 技术栈参考
10. 总结

🧭 一张图看懂后端接口体系

每一种接口存在的意义都不同，因此 不存在万能接口，只有合适的场景。

1️⃣ RPC：真正的“函数级”远程调用

包括：gRPC、Dubbo、Thrift、Hessian 等

RPC 的思想很简单：

就像调用本地函数一样去调用远程服务。

它们通常具备：

• 二进制协议（更快更省带宽）
• 长连接、多路复用
• 强类型、依赖 IDL（接口定义文件）
• 自动生成客户端 SDK
• 常用于微服务内部通信

下面是主流 RPC 简析👇

✔ gRPC —— Google 出品，性能怪兽

协议：HTTP/2 格式：Protobuf（二进制）

特点：

• 高性能：延迟低，序列化快
• 天然支持流式（如双向流）
• 多语言支持极强
• 浏览器不直接支持，需要 gRPC-Web

适用场景： ⭐ 微服务内部调用 ⭐ 大流量场景（推荐页、Feed流） ⭐ 实时推送 ⭐ 移动端节省流量

✔ Dubbo —— 阿里系 Java 微服务标准

特点：

• Java 生态最强
• 内置服务治理（负载、路由、限流、熔断、注册中心）
• 支持多协议（Dubbo、gRPC、REST）

适合： ⭐ 大型 Java 后端，服务治理需求强的团队

✔ Thrift —— Facebook 开源

特点：

• 多语言支持好
• 高度可定制
• 协议可插拔（Binary、Compact、JSON）

适合： ⭐ 多语言团队 ⭐ 已有 Thrift 生态

2️⃣ 消息队列（MQ）：异步接口的王者

包括：Kafka、RabbitMQ、RocketMQ、Pulsar

“当你的系统需要解耦、削峰、异步处理时，MQ 是最合适的接口。”

特点：

• 通过 发布/订阅 或 队列 模式通信
• 不同步、不要求即时响应
• 支持事件广播、延时、重放、容错

适用场景： ⭐ 异步任务处理（发短信、批量计算） ⭐ 流数据管线（埋点、日志、监控） ⭐ 解耦业务系统（订单系统 -> 库存系统） ⭐ 高并发削峰

3️⃣ GraphQL：比 REST 更灵活的接口

GraphQL 的优势：

• 客户端决定要哪些字段
• 单个接口可聚合多个数据源
• 减少 over-fetching / under-fetching

缺点：

• 服务端实现比 REST 复杂
• 缓存和监控不如 REST 直接
• 查询过深容易带来性能风险

适用场景： ⭐ 前端页面复杂、字段要求灵活 ⭐ 移动端带宽敏感 ⭐ 需要聚合数据（如一个页面需多个后端接口）

4️⃣ WebSocket / MQTT：实时通信接口

WebSocket 特点：

• 长连接
• 双向通信
• 延迟低

应用： ⭐ 聊天室 ⭐ 在线游戏 ⭐ 实时行情 ⭐ 后台推送通知

MQTT 特点：

• 极轻量（专为 IoT 设备设计）
• 发布/订阅模型
• 带宽占用极低

应用： ⭐ 物联网设备 ⭐ 远程传感器 ⭐ 低带宽网络

5️⃣ SOAP：企业级的“古典接口”

特点：

• 基于 XML
• 配套大量 WS-* 协议（安全、事务）
• 金融、电信、政府系统仍在使用

如果没有遗留系统接入需求：不建议新项目使用。

6️⃣ 各类接口 vs HTTP 接口的核心对比

一句话总结：

外部用 HTTP，内部用 RPC，异步用 MQ，实时用 WebSocket。

7️⃣ 真实业务的选型示例

场景 1：电商系统拆分

• 下单服务 → 库存服务：RPC（实时响应）
• 下单结果 → 物流/营销：MQ（异步）
• Web 前端展示商品：REST
• 订单状态实时推送：WebSocket

场景 2：内容推荐系统

• 推荐服务内部：gRPC
• 埋点日志：Kafka
• 页面接口：REST / GraphQL

场景 3：IoT 平台

• 设备 → 云端：MQTT
• 后台管理系统：REST
• 大屏监控：WebSocket

8️⃣ 工程实践建议

• RPC/GraphQL 要做好 Schema/Proto 管理
• MQ 要确保至少一次 / 恰好一次投递
• WebSocket 要注意连接状态、心跳、扩容
• 所有接口都要接入链路追踪（OpenTelemetry）
• 选型先看团队能力，不盲目追热点

🎯 最后总结（收藏级）

接口不是越少越好，而是应该按职责组合使用。

• 对外 → HTTP/REST 是最通用的
• 内部短平快高性能 → gRPC / Dubbo
• 异步、解耦、高吞吐 → Kafka / MQ
• 实时通信 → WebSocket / MQTT
• 灵活查询 → GraphQL

一个优秀架构师的职责： 是为每条链路找到最合适的接口，而不是让所有接口一刀切。