挑战
固定的流媒体基础设施无法应对不断增长的监控平台的动态需求：
- 伸缩可变性 — 摄像机数量和观看者需求全天剧烈波动（峰谷比达10倍）
- 过度配置成本 — 为峰值负载进行配置意味着在非高峰时段有70%以上的资源闲置
- 伸缩期间的丢包 — 添加或移除流媒体服务器会导致流中断，使 AI 处理工作者丢失帧
- URL 不稳定性 — 配置了特定服务器 IP 的摄像机和观看者在基础设施变更时需要重新配置
- 不同的伸缩需求 — 摄像机摄取和观看者分发具有根本不同的负载模式，需要独立伸缩
- AI 工作者中断 — 当其源流服务器缩减时，AI 处理管道会崩溃
我们的解决方案
我们设计了一种双编排器自动伸缩流媒体架构，其包含独立的摄取和分发集群、五阶段的优雅关机以实现零丢包、基于 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台以实现高可用性）
零丢包：五阶段优雅关机
当一个分发服务器被计划移除时，一个五阶段流程确保不会丢失任何帧：
阶段 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 工作者迁移的五阶段优雅关机
- 稳定 URL — 基于 DNS 的路由确保在伸缩期间 URL 永不改变
- AI 工作者重连 — 基于检查点的迁移，约3秒中断，零帧丢失
- 独立伸缩 — 摄取和分发根据各自的指标伸缩
- 服务注册中心 — 基于 Redis 的服务器状态和流映射协调
- 健康监控 — 带有自动恢复功能的主动检查
- 成本优化 — 低需求时段的自动缩容
成果
技术栈
caseStudyDetail.more 案例研究
探索更多我们的技术实施案例
常见问题
MicrocosmWorks 实施了一种主-主双编排器设计，其中两个编排器都维护关于流分配和工作节点健康状况的同步状态，并具有自动故障转移功能，如果其中一个发生故障，流管理会在几秒钟内转移到幸存的编排器。这消除了传统单编排器设计存在的单点故障，确保在编排器维护或意外崩溃期间实现零丢包。
MicrocosmWorks 设计了一种优雅下线机制，下线中的工作节点会继续服务其分配的流，直到所有连接通过 RTSP TEARDOWN 和重新 SETUP 序列平滑迁移到新的工作节点。新的工作节点在接收流分配之前会进行完整的初始化和健康检查，并且在过渡期间使用重叠窗口，新旧工作节点会短暂地同时服务相同的流，以防止任何中断。
MicrocosmWorks 为该项目选择了 MediaMTX，因为它轻量级、开源，并且专为 RTSP 重流式传输而设计，与全功能媒体服务器相比，每个流的资源开销极小。它支持通过 API 动态创建流，在容器中高效运行以实现基于 Kubernetes 的自动扩缩容，并避免了 Wowza 等商业替代方案在按流计费的许可成本，这些成本在大规模部署时会变得过高。
MicrocosmWorks 部署了一个全面的可观测性堆栈，用于跟踪按流指标，包括丢包率、抖动、重连次数和端到端延迟，并在服务质量下降对最终用户可见之前触发警报。监控系统还跟踪编排器决策指标，如扩缩容事件、流迁移持续时间和工作节点利用率趋势，以实现前瞻性容量规划。
是的，MicrocosmWorks 设计的工作节点支持为实时观看者提供并发 RTSP 输出，并支持将分段录制到对象存储，每个工作负载都有独立的资源分配。录制使用一个独立的写入路径，在上传前在本地缓冲分段，因此存储 I/O 峰值绝不会影响直播流传输，并且自动扩缩容器在做出扩缩容决策时会考虑这两种工作负载的组合资源需求。