挑战
固定的流媒体基础设施无法应对不断增长的监控平台的动态需求：
- 规模可变性 — 摄像头数量和观看者需求在一天中大幅波动（峰谷比为 10 倍）
- 过度预置成本 — 为峰值负载预置资源意味着在非高峰时段有超过 70% 的闲置资源
- 扩缩容期间的丢包 — 添加或移除流媒体服务器会导致流中断，使 AI 处理工作者丢帧
- URL 不稳定性 — 配置了特定服务器 IP 的摄像头和观看者在基础设施变更时需要重新配置
- 不同的扩缩容需求 — 摄像头摄取和观看者分发具有根本不同的负载模式，需要独立扩缩容
- AI 工作者中断 — AI 处理管道在其源流服务器缩容时崩溃
我们的解决方案
我们设计了一个双编排器自动扩缩容流媒体架构，具有独立的摄取和分发集群、一个 5 阶段的优雅停机以实现零丢包、稳定的基于 DNS 的 URL，以及自动化的 AI 工作者重连。
架构
- 流媒体服务器: MediaMTX，支持 RTSP/WebRTC/HLS 协议
- 摄取集群: 1-10 台接收摄像头 RTSP 流的服务器
- 分发集群: 2-20 台服务观看者 (WebRTC/HLS) 和 AI 工作者 (RTSP) 的服务器
- 双编排器: 用于摄取和分发的独立扩缩容控制器
- 负载均衡器: 每个集群独立的负载均衡器，采用适合协议的算法
- 服务注册中心: Redis，用于服务器状态、流映射和协调
- 健康监控: 具有自动化恢复功能的主动健康检查
- DNS 层: 指向负载均衡器的稳定域名 (URL 永不改变)
双编排器设计
为什么需要两个编排器
摄取和分发具有根本不同的扩缩容特性：
- 摄取随摄像头数量和入站带宽扩缩容（可预测，稳定增长）
- 分发随观看者数量和 AI 工作者需求扩缩容（突发性，不可预测）
独立的编排器允许每个独立扩缩容，采用专门的策略、指标和阈值 — 而一个集群的扩缩容决策不会影响另一个。
摄取编排器
- 主要指标: 每服务器摄像头连接数
- 次要指标: 入站带宽利用率
- 扩容: 当 CPU 超过阈值或每服务器摄像头数超过容量时
- 缩容: 当利用率降至阈值以下并持续一段时间的稳定期后
- 服务器范围: 1 到 10 台服务器
分发编排器
- 主要指标: 每服务器观看者 + AI 工作者连接数
- 次要指标: 出站带宽利用率
- 扩容: 当 CPU 超过阈值或每服务器连接数超过容量时
- 缩容: 当利用率降至阈值以下并持续一段时间后（比摄取更长的稳定期）
- 服务器范围: 2 到 20 台服务器（最少 2 台以实现高可用性）
零丢包：5 阶段优雅停机
当一个分发服务器被计划移除时，一个 5 阶段的过程确保不会丢失任何帧：
阶段 1: 预通知服务器在服务注册中心被标记为“DRAINING”（正在排空）。负载均衡器权重降低，新连接路由到其他地方。Redis pub/sub 通知和 webhooks 提醒 AI 工作者准备迁移。
阶段 2: 负载均衡器更新服务器从负载均衡器后端池中移除。没有新连接能到达正在排空的服务器。现有连接继续不中断。
阶段 3: AI 工作者迁移AI 工作者从正在排空的服务器断开连接，并重新连接到健康的分布服务器。基于检查点的状态保存确保处理从中断的精确帧处恢复。总中断时间：大约 3 秒，零丢帧。
阶段 4: 观看者排空剩余的观看者连接在可配置的时间窗口内自然排空。现代视频播放器会自动重新连接到相同的稳定 URL，该 URL 会路由到健康的服务器。大多数观看者不会经历中断。
阶段 5: 清理验证所有连接已关闭。将服务器从服务注册中心移除。销毁云实例。记录扩缩容指标。
稳定 URL
URL 架构确保摄像头和客户端永不需要重新配置：
- 摄像头发布目标: 一个稳定的摄取域名
- 观看者/AI 访问目标: 一个稳定的分发域名
- DNS 记录指向负载均衡器 IP（这些 IP 是永久性的）
- 负载均衡器透明地处理路由到后端服务器
- 后端服务器可以添加、移除或替换，而无需更改 URL
服务注册中心 (Redis)
一个中心化的 Redis 实例协调整个系统：
- 服务器状态跟踪（活跃、排空、离线）
- 流到服务器的映射（哪个摄像头在哪个摄取服务器上）
- AI 工作者状态和检查点数据
- 每服务器负载指标用于扩缩容决策
- Pub/sub 通道用于实时协调事件
AI 客户端重连
一个 AI 客户端库提供无缝重连：
- 通过 Redis pub/sub 监听服务器移除通知
- 定期自动帧检查点
- 在收到通知后重新连接到健康的分布服务器
- 从检查点恢复处理，间隔最小
- 重连事件的指标报告
健康监控
- 定期对每台服务器进行主动健康检查
- 服务器故障时自动更新负载均衡器
- 对无响应服务器的自动恢复触发器
- 运行时间跟踪和可用性报告
主要特点
- 双编排器 — 用于摄取和分发集群的独立扩缩容
- 零丢包 — 具有 AI 工作者迁移的 5 阶段优雅停机
- 稳定 URL — 基于 DNS 的路由确保 URL 在扩缩容期间永不改变
- AI 工作者重连 — 基于检查点的迁移，大约 3 秒的间隔，零丢帧
- 独立扩缩容 — 摄取和分发根据各自的指标进行扩缩容
- 服务注册中心 — 基于 Redis 的服务器状态和流映射协调
- 健康监控 — 具有自动恢复功能的主动检查
- 成本优化 — 低需求时段自动缩容
成果
技术栈
caseStudyDetail.more 案例研究
探索更多我们的技术实施案例
常见问题
MicrocosmWorks 实施了一个双活 (active-active) 双编排器设计，其中两个编排器都维护关于流分配和工作节点健康状况的同步状态，并具有自动故障转移功能，在其中一个发生故障时，几秒钟内将流管理转移到幸存的编排器。这消除了传统单编排器设计所固有的单点故障，确保在编排器维护或意外崩溃期间零丢包。
MicrocosmWorks 设计了一种优雅的下线机制，其中即将下线的旧工作节点会继续服务其分配的流，直到所有连接都通过 RTSP TEARDOWN 和 re-SETUP 序列干净地迁移到新工作节点。新工作节点在接收流分配之前会完成初始化并进行健康检查，并且此过渡采用重叠窗口的方式，新旧工作节点会短暂地同时服务相同的流，以防止任何中断。
MicrocosmWorks 在此项目中选择 MediaMTX 是因为它轻量、开源，并且专为 RTSP 重流（re-streaming）设计，与功能齐全的媒体服务器相比，每个流的资源开销极小。它支持通过 API 动态创建流，可以在容器中高效运行，以实现基于 Kubernetes 的自动扩缩容，并避免了像 Wowza 等商业替代方案按流计费的许可成本，这种成本在规模化时可能变得过高。
MicrocosmWorks 部署了一个全面的可观测性堆栈，用于跟踪每流指标，包括丢包率、抖动、重连次数和端到端延迟，并设有告警，在性能下降对最终用户可见之前触发。该监控系统还跟踪编排器决策指标，例如伸缩事件、流迁移持续时间以及工作节点利用率趋势，以实现主动的容量规划。
是的，MicrocosmWorks 设计了工作节点，以支持对实时观众的并发RTSP输出以及分段录制到对象存储，并为每种工作负载独立分配资源。录制使用独立的写入路径，在上传前本地缓冲分段，因此存储I/O峰值绝不会影响直播流的传输，并且自动伸缩器在做出伸缩决策时会考虑这两种工作负载的总资源需求。