Horizon: A Hyper-Edge Observability Engine for Live Streaming Networks

Experience Session 2: Content Delivery & Video Streaming

企业赛道, 反正笔者是从来不看. 用 AI 扫一遍吧...

(1) 论文研究背景与核心痛点

• 背景:

  • 大规模直播网络（LiveNets）是承载现代实时互动的核心基础设施，要求极低的延迟和极高的稳定性。

• 挑战:

  • 直播网络的故障往往发生在面向用户的最后一公里路径以及上层流媒体协议/应用逻辑中
  • 传统的服务端探测无法触及真实的用户端路径，而客户端 SDK 遥测又只能被动收集，无法用于前置的主动测试

• 破局思路:

  • 论文提出利用“超边缘（hyper-edge）”设备（如: 家用机顶盒、智能网关）作为监测点
  • 这些设备物理位置极度贴近用户，且具备一定的可编程与可管理能力

(2) Horizon 系统的两大核心功能

Horizon 采用了“控制器-代理（Controller-Agent）”架构，实现了两大核心引擎:

A. Runtime Monitoring Engine

该引擎致力于将不可靠的超边缘设备舰队转化为可靠的实时监控网络:

• 可靠性感知的代理选择:

  • 由于超边缘设备状态波动大，Horizon 持续计算每个代理的可靠性评分，过滤掉低可靠性的节点
  • 并通过多节点“多数投票”机制确保探测结果的准确性

• 基于拉取（Pull-based）的任务分配:

  • 放弃服务端主动推送，改为设备根据自身的可用性和资源预算主动向控制器拉取探测任务
  • 极大提升了系统对设备频繁掉线的鲁棒性

• 防冲突的任务调度:

  • 代理端在执行探测任务时，会基于“冲突矩阵”（如避免并发执行大带宽拉流任务和敏感的 ICMP 延迟测试）和资源上限（CPU/内存）进行调度，防止探针相互干扰

B. Preflight Testing Engine

该引擎用于在真实环境或重大更新上线前，进行主动的、高度可控的验证:

• 网络环境实例化:
  • 支持通过一种统一的领域特定语言（DSL）来定义网络拓扑结构（如跨区域节点）、流量压力规模、节点通信模型以及注入特定网络故障（如拥塞控制、转码错误等）
  • 
• 用户行为实例化:
  • 将用户行为建模为由 QoE 驱动的状态机
  • 系统通过轻量级的无参考 QoE 检查（如帧完整性、码率稳定性、音视频同步）来触发用户的条件动作（如降级分辨率、退出播放等），以此模拟真实用户的互动
  • 

(3) 部署规模与评估效果

• 部署规模:
  • Horizon 已在生产环境中部署了 3 年以上，管理着超过 10 万个超边缘代理，覆盖全球数百个边缘站点和数千万级别的实时并发
• 实战成效:
  • 在 2025 年，Horizon 成功识别了 2000 多起重大网络事件，覆盖了 98% 的确诊严重故障，准确率（Precision）超过 95%
• 响应速度:
  • 自动化监控的平均发现时间（MTTD）仅为 3.4 分钟