gRPC从0到1系列【18】

双向流RPC

6.3 应用场景

6.3.1 实时聊天系统(Chat/IM)

📌 需求

• 用户 A 和 B 实时互发消息
• 消息需即时送达，支持文本、表情、文件等
• 支持在线状态、已读回执

🧩 优点

• 客户端持续发送新消息（上行流）
• 服务器持续推送他人消息（下行流）
• 无需轮询，消息到达即推

✅ 优势：比 WebSocket 更结构化，天然支持多语言、强类型、自动序列化

6.3.2 协同编辑（Collaborative Editing）

📌 需求

• 多人同时编辑同一文档（如 Google Docs）
• 实时同步光标位置、文本变更、格式调整
• 需要操作转换（OT）或 CRDT 算法保证一致性

🧩 为什么用双向流？

• 每个用户将本地操作（如“在位置5插入‘Hello’”）发送给服务器（上行）
• 服务器广播操作给其他协作者（下行）
• 低延迟同步是关键

✅ 优势：gRPC 的流控机制可防止突发操作导致网络拥塞

6.3.3 实时游戏（多人在线游戏）

📌 需求

• 玩家移动、攻击、交互等操作实时同步
• 服务器广播游戏状态（位置、血量、事件）
• 要求 <100ms 延迟

🧩 为什么用双向流？

• 客户端持续上报玩家输入（上行流）
• 服务器持续下发世界状态（下行流）
• 全双工通信避免“请求-响应”延迟

✅ 优势：Protobuf 二进制格式比 JSON 更小，节省带宽；HTTP/2 多路复用减少连接开销

6.3.4 物联网（IoT）设备控制与监控

📌 需求

• 设备上报传感器数据（温度、湿度、电量）
• 服务器下发控制指令（开关、参数调整）
• 支持设备在线/离线状态管理

🧩 为什么用双向流？

• 设备 → 服务器：持续上报遥测数据（上行）
• 服务器 → 设备：远程配置、固件升级指令（下行）
• 一条连接搞定双向通信

✅ 优势：相比 MQTT，gRPC 提供更强的类型安全和错误处理；相比 REST，避免频繁建连

6.3.5 语音/视频通话信令（Signaling）

📌 需求

• 建立 P2P 连接前交换 SDP、ICE 候选地址
• 通话中传递控制指令（静音、挂断、切换摄像头）
• 需要可靠、有序的消息传递

🧩 为什么用双向流？

• 双方交替发送信令消息（无固定发起方）

• 消息需按序到达（HTTP/2 保证）

• 长连接避免信令丢失

⚠️ 注意：媒体流（音视频）仍走 WebRTC，gRPC 仅用于信令

6.3.6 实时数据处理管道（Streaming ETL）

📌 需求

• 客户端持续发送原始数据（日志、交易记录）
• 服务器实时处理并返回结果（清洗、聚合、告警）
• 支持背压（Backpressure）防止过载

🧩 为什么用双向流？

• 上行：原始数据流
• 下行：处理结果流（成功/失败/指标）
• 流式处理避免批处理延迟

✅ 优势：gRPC 的流控（flow control）天然支持背压，防止消费者被压垮

6.3.7 远程过程调用代理（gRPC Gateway / Proxy）

📌 需求

• 客户端通过代理调用后端服务
• 代理需透传双向流（如 WebRTC 信令代理）
• 支持中间件（认证、日志、限流）

🧩 为什么用双向流？

• 代理作为“中间人”，需同时处理上下游流
• 零拷贝转发降低延迟

✅ 优势：gRPC 的拦截器（Interceptor）可轻松注入中间件逻辑

6.3.8 与其他技术的对比

场景	gRPC 双向流	WebSocket	MQTT	REST Long Polling
实时聊天	✅ 强类型、多语言	✅ Web 原生支持	✅ 轻量	❌ 高延迟
协同编辑	✅ 低延迟、流控	⚠️ 需自定义协议	⚠️ 无序风险	❌ 不适用
IoT 控制	✅ 安全、高效	⚠️ 资源消耗大	✅ 专为 IoT 设计	❌ 不适用
游戏同步	✅ 二进制高效	✅ 常用	❌ 不适合	❌ 不适用
Web 前端支持	❌ 需 gRPC-Web	✅ 原生	⚠️ 需库	✅ 支持

📌 选择建议：

• 内部服务/移动端 → 优先 gRPC 双向流
• Web 前端 → WebSocket 或 gRPC-Web（需代理）
• 资源受限 IoT → MQTT + gRPC 混合架构