3、整体架构设计：端到端架构图
好，咱们进入正题。这一章聊的是整体架构设计，说白了就是「视频从摄像头拍到手机屏幕，中间到底经历了什么」。我做了这么多年物联网项目，发现很多团队一上来就写代码，结果连数据流和信令流都没分清楚，最后调试时哭都来不及。
嗯，咱们先看一张整体架构图，把全局脉络理清楚。
3.1 端到端架构拆解
这张图我画了好几个版本才定下来。你仔细看，它其实分上下两层：上层是数据流，也就是视频画面本身；下层是信令流，负责控制、协商、状态同步。这两条线必须分开，否则后期维护就是噩梦。
咱们从左到右捋一遍：
- 摄像头端：采集视频，编码成 H.264 或 H.265，然后通过 RTMP 或 GB28181 推给流媒体服务器。我在项目中遇到过用老旧海康摄像头只支持 RTSP 的情况，还得加个转码网关，这个坑后面会细说。
- 流媒体服务器：核心枢纽。负责接收推流、转码（比如把 4K 降成 1080p）、切片（生成 HLS 的 .ts 文件），然后转发给 CDN。我个人习惯用 SRS 或 Nginx-RTMP，轻量且稳定。
- CDN：说白了就是「加速器」。把视频缓存到离用户最近的节点，避免全国用户都来挤你的源站。我见过一个客户没上 CDN，结果 1000 路并发直接把服务器打挂了……嗯，血的教训。
- 移动端：手机 App 或小程序，拉流解码播放。这里要处理弱网、首屏秒开、硬解兼容等问题。
核心原则：数据流走「推拉模式」，信令流走「请求响应模式」。两者物理上可以共用通道，但逻辑上必须解耦。
3.2 技术选型：WebRTC vs RTMP vs HLS
这是每次架构评审都会吵起来的话题。我直接说结论：没有银弹，只有场景。咱们用一张表对比清楚：
| 特性 | WebRTC | RTMP | HLS |
|---|---|---|---|
| 延迟 | < 500ms（实时） | 1-3s（低延迟） | 5-30s（高延迟） |
| 浏览器支持 | 原生支持（Chrome/Firefox） | 需 Flash 或插件 | 原生支持（H5 video） |
| 移动端支持 | iOS/Android SDK 支持 | 需第三方播放器 | 原生支持（iOS 尤佳） |
| 抗弱网能力 | 强（FEC + NACK） | 弱（TCP 重传） | 中（基于 HTTP） |
| 部署复杂度 | 高（需 STUN/TURN） | 低 | 低 |
| 适用场景 | 实时对讲、低延迟监控 | 直播推流、传统监控 | 大规模分发、点播回放 |
你想想看，如果做的是「幼儿园监控」，家长要看孩子实时活动，延迟超过 2 秒就会被投诉——那必须上 WebRTC。但如果做的是「安防录像回放」，用户点开看 10 分钟前的画面，HLS 完全够用，还省带宽。
我的建议：混合架构。实时预览用 WebRTC，回放用 HLS，推流用 RTMP。我在一个智慧工地项目里就是这么干的，效果很好。
3.3 数据流与信令流分离设计
这是很多新手容易忽略的点。我直接说为什么必须分离：
- 性能隔离：视频数据量大（一路 1080p 约 4-8 Mbps），信令数据量极小（几 KB）。混在一起，信令容易被视频流量冲垮。
- 安全控制：信令流承载鉴权、设备控制等敏感操作，需要加密和严格校验。数据流可以走 CDN 公开分发。
- 扩展性：信令服务器可以横向扩展，数据流可以走不同的 CDN 厂商，互不干扰。
具体怎么设计？我画个简单的信令交互流程：
// 信令交互示例（简化版）
移动端 --> 信令服务器: 请求观看摄像头A
信令服务器 --> 摄像头A: 开启推流
摄像头A --> 信令服务器: 推流地址 + token
信令服务器 --> 移动端: 播放地址 + token
移动端 --> CDN: 拉流播放（数据流）
你看，信令只负责「握手」和「控制」，真正的视频数据走 CDN。我曾经在一个项目中把信令和数据混在同一个 WebSocket 里，结果视频卡顿时信令也收不到，设备离线都检测不出来……后来花了三天重构，彻底分开才解决问题。
避坑指南：信令服务器不要用 Node.js 单线程处理大量视频流元数据。我曾经踩过这个坑，后来换成 Go 或 Java 的 Netty，性能提升 10 倍。
3.4 小结
这一章咱们把整体架构理清楚了。记住三个关键词：分层、选型、分离。数据流和信令流各走各的道，技术选型看场景不要跟风。下一章咱们会深入摄像头端的采集与编码，到时候再聊具体实现细节。
公众号:蓝海资料掘金营，微信deep3321