在系统设计中，“通信方式选型”是一个架构级问题。
选对了，系统稳定、可扩展；
选错了，耦合严重、后期必返工。

---

一、系统中常见的通信方式有哪些？

从实际工程角度看，主流通信方式可以归纳为 5 种：

1. HTTP / HTTPS
2. RPC
3. 消息队列（MQ）
4. WebSocket
5. 推送（Push）

下面逐一说明它们的定位和适用场景。

---

二、HTTP / HTTPS（请求-响应型通信）

1️⃣ 通信模型

• 请求 → 响应
• 由客户端主动发起
• 同步返回结果

2️⃣ 适用场景

• 登录
• 下单
• 提交表单
• 提交证件资料
• 修改业务数据

3️⃣ 不适合场景

• 实时通知
• 状态频繁变更推送

📌 总结一句话

HTTP 适合“用户主动发起、需要明确处理结果”的业务操作

---

三、RPC（内部系统高性能通信）

1️⃣ 通信模型

• 接口强约束
• 看起来像本地方法调用
• 实际是网络通信

2️⃣ 适用场景

• 微服务内部调用
• 内网系统之间通信
• 对性能要求高的服务

3️⃣ 不适合场景

• 对外开放接口
• 跨公司、跨组织系统

📌 总结一句话

RPC 适合“内部服务之间的高性能调用”

---

四、消息队列 MQ（异步解耦通信）

1️⃣ 通信模型

• 异步
• 生产者 / 消费者解耦
• 事件驱动

2️⃣ 适用场景

• 交易完成事件
• 状态变更通知
• 异步处理
• 削峰填谷

3️⃣ 典型错误用法

• 业务完成后同步调用多个系统
• 系统之间强依赖下游响应

📌 总结一句话

系统之间的“反应型动作”，必须使用 MQ 解耦

---

五、WebSocket（实时双向通信 / 信令）

1️⃣ 通信模型

• 基于 TCP 的长连接
• 双向通信
• 服务端可主动推送消息

2️⃣ 适用场景

• 即时消息
• 实时状态通知
• 审核结果推送
• 音视频信令

3️⃣ 不适合场景

• 下单
• 提交表单
• 修改核心业务数据

📌 总结一句话

WebSocket 用来“推送结果”，不用于“发起业务请求”

---

六、推送（Push，离线通知兜底）

1️⃣ 通信模型

• 不依赖客户端在线
• 由系统或厂商通道投递

2️⃣ 适用场景

• 用户离线提醒
• 弱实时通知
• WebSocket 的兜底方案

3️⃣ 正确定位

• 不能替代 WebSocket
• 不保证强实时

📌 总结一句话

推送负责“一定能看到”，不负责“立刻看到”

---

七、通信方式快速对照表

通信方式	是否实时	是否长连接	典型场景
HTTP	否	否	登录 / 提交
RPC	否	否	内部服务调用
MQ	否	否	系统解耦
WebSocket	是	是	实时通知
推送	否	否	离线提醒

---

八、补充说明：SDK 在通信体系中的正确位置

1️⃣ SDK 是什么？

SDK 不是通信方式，而是对通信方式的封装。

它把底层的 HTTP / RPC / WebSocket
封装成“方法调用”的形式，方便业务方使用。

2️⃣ 常见 SDK 的真实底层

SDK 类型	实际使用的通信方式
短信 / OCR / 活体 SDK	HTTP
云服务 SDK	HTTP / RPC
IM / RTC SDK	WebSocket

3️⃣ 为什么 SDK 要单独说明？

• 它不参与通信选型
• 它不决定系统架构
• 它只决定 “调起来舒不舒服”

📌 总结一句话

通信方式决定系统形态，SDK 只影响开发体验

---

九、全文一句话总结

HTTP 负责发起
RPC 负责内部
MQ 负责解耦
WebSocket 负责实时
推送负责兜底
SDK 只是封装手段