Netflix Live架构学习笔记（一）

本篇文章是对Netflix TechBlog发布的Behind the Streams: Three Years Of Live at Netflix所做的学习总结。这是第一部分，主要是Netflix Live架构的一些基础内容，不会涉及具体的编码细节。

一、背景

从点播到直播，这是一个新的挑战。Netflix在点播视频领域已经积累了15年经验，有着极其成熟的技术栈和全球数亿用户。然而，切换到Live模式，Live引入了一些新的影响架构和技术选择的因素。

二、问题分析

传统点播系统架构无法承受Live流量洪峰，Netflix遇到的典型问题包括：

• ​​媒体处理方式​​：需近乎实时的系统进行媒体资产摄取、编码和分发。
• ​​资源扩展需求​​：需动态扩展云服务、优化负载均衡，避免请求“雪崩效应”。
• 用户观看时间特性​​：需在特定时间吸引观众，依赖精准事件通知和内容推广能力。
• 播放缓冲策略​​：播放器需保持极短分段缓冲以降低延迟。
• ​​运营维护挑战​​：直播中断影响重大（实时性+海量观众），需极短故障恢复时间。

三、Netfilx Live架构的核心策略

整个系统的目标是：

• 在尽可能多的设备上保持高质量播放并且不会中断。
• Netflix的直播带有娱乐属性，因此还需要将直播活动无缝融入用户体验，同时扩展到超过3亿的全球用户。

3.1 整体架构图

3.2 使用专用广播设施从制作端采集直播内容

直播事件可能发生在世界的任何角落，但并非所有地点都具备专业的直播设施或良好的网络连接。

• 分布式部署的广播运营中心： 为确保直播信号传输的安全性与可靠性，我们依托分布式、互联能力强的广播运营中心。这些中心配备了专门的信号采集与检测设备，支持字幕插入、图文包装以及广告管理。
• 系统设计中高度重视可复用性：通过流程标准化与自动化手段，实现了对直播事件的一致性、高可靠性和低成本的发起。最终将每场直播的定制化准备工作压缩至制作端与广播中心之间的传输部分，其余流程则实现了跨事件的通用复用。

3.3 基于云服务的冗余转码与打包处理流程

广播中心接收到的是完整制作后的节目信号，但该信号仍需进行编码与打包，以适配不同终端的在线流媒体播放。

• 基于云服务的转码打包架构：实现了弹性扩展、配置灵活、并便于与现有部署在云端的数字版权管理（DRM）、内容管理与内容分发服务集成。
• 转码方面：利用 AWS Elemental MediaConnect 与 MediaLive 将信号接入云端，并转码为多种码率与清晰度层级，以适应不同的观看环境。
• 打包方面：自研定制的打包器（Packager）和 Live Origin 服务。以更好地兼容内容分发与播放系统和保障直播分片的读写 SLA（服务等级协议）要求。

3.4 利用 Open Connect CDN 实现直播内容的大规模分发

要将制作完成的媒体内容传送到全球数亿设备，需要将直播源（Live Origin）部署于少数 AWS 站点，并通过高效路径分发至终端用户。

• 借助自建的内容分发网络（CDN）Open Connect 实现直播内容的可扩展分发能力（已部署至超过 6000 个接近用户的网络节点，并通过专用骨干网络与 AWS 站点互联)。
• 直播内容的服务器容量与点播内容共享：在提升资源利用率的同时，也通过缓存历史直播内容支持“回看”功能，提升用户体验。
  

3.5 优化直播播放的终端兼容性、扩展能力、画质与稳定性

• 基于 HTTPS 的直播流传输方式：虽然基于 UDP 的协议可提供如超低延迟等附加特性，但HTTPS 拥有广泛的终端支持能力，并与当前的编码与分发系统高度兼容。大多数用户无需更换终端设备即可观看直播。
• 编码方面：我们采用 AVC 与 HEVC 视频编码格式，提供从 SD 至 4K 多档位转码选项，统一采用 2 秒的分片时长，在压缩效率、服务器负载与延迟之间取得良好平衡。
• 播放开始时：终端播放器会接收一个播放清单（Playback Manifest），其中包含编码码率、推荐使用的 CDN 节点等信息（从云端而非 CDN 下发清单，以支持针对不同设备的个性化配置）。播放清单中包含的分片模板（Segment Template）用于将设备的本地时间映射为 CDN 上的具体分片 URL。相比传统的周期性清单轮询机制，分片模板大幅降低了网络依赖、CDN 负载以及对资源受限设备（如智能电视）的性能压力，从而提升了系统整体的可扩展性与稳定性。
• 播放过程中：播放器会动态监控网络表现，智能切换码率与 CDN 节点，以最大化播放质量并最小化卡顿重缓冲的发生。

3.6 在云端运行一系列发现与播放控制服务

至此，对整体系统的介绍已经涵盖了从录制设备到播放设备的流媒体路径。为了使直播流能工作起来，还需要协调这些系统组件，并确保观众可以找到并开始Live事件。

• 基于云的发现与播放控制服务：这些服务的作用是协调各个子系统的行为，并确保用户能够顺利发现并启动直播内容。涵盖播放配置、个性化推荐、数据采集等功能。由于用户通常会在直播开始前后集中访问，这些服务往往会在短时间内面临远高于平时的请求压力，基于云的部署方式可以提供弹性计算资源，能够根据流量动态扩容。
• 全球负载均衡：由于直播观看需求通常具有地域性，通过跨多个 AWS 区域部署服务，有效实现了全球负载均衡，提高了资源使用效率。

3.7 使用专门的工具和设施在云端监控实时指标

借助于我们对信号采集、编码处理、CDN 分发及终端播放器的全面掌控，已基本实现了对直播全链路的可观测性。

• 实时数据采集：在直播过程中实时采集系统与用户体验相关的数据指标，例如用户在哪些界面看到直播入口、观看质量是否达标等，从而在出现体验下降或系统性能问题时第一时间获知并响应。这套实时监控体系由 Netflix 自研工具（如 Atlas、Mantis 和 Lumen）与开源组件（如 Kafka 和 Druid）共同构建而成(系统最高每秒处理 3800 万条实时事件，并能在几秒钟内生成关键指标和运维洞察，支撑快速决策响应)。
• 设立监控设施：为了进一步提升运营效率，还设立了专用的“控制中心”监控设施，将关键指标实时聚合展示，供运维团队在直播期间集中监控与应对突发情况。

四、核心经验总结

以下是Netfilx Live开发团队做出的经验总结。

4.1 广泛的测试实践

在上线直播功能之前，我们主要依赖点播流量的可预测性，通过预发布 Canary 和 A/B 测试来验证部署。但直播流量并不总是可用，尤其难以复现大规模上线时的流量特征。因此 Netflix 投入了大量精力开发如下能力：

• 生成内部“测试流”，供工程师在开发流程中进行集成测试、回归测试和冒烟测试；

• 构建合成负载测试工具，以对云端和 CDN 系统进行压力测试。我们采用两种方法，最高可生成每秒 10 万次启动请求：

  • 捕获、修改并重放历史直播流量，模拟不同设备类型和访问模式；
  • 虚拟化 Netflix 终端设备，向 CDN 或云端接口生成测试流量，以覆盖最新变更带来的系统影响；

• 执行自动化故障注入，模拟编码流程中分片丢失或损坏、云区域不可用、网络中断或服务器超时等场景。

4.2 定期演练

发布前的测试尽管非常严密，但与真实生产环境相比仍存在差距，尤其是在规模化条件下。通过设立一个包含多样化直播内容的固定排期，有助于持续改进系统表现，同时平衡对用户的潜在影响。在实际运维中，会进行 A/B 测试、混沌工程测试、运维演练，并对运营团队进行相关训练，以应对即将上线的内容。

4.3 观众规模预测

• 预估资源：基于预测的方法提前为云服务和 CDN 分配资源，同时将预估结果提前共享给的 ISP 与云服务提供商，以便他们预留网络带宽与计算资源。
• 动态扩容：配置了云服务的动态扩容能力，涵盖注册、登录、内容发现和播放等环节，以应对实际观众人数超出预期的情况（在直播进行过程中，基于实时观众行为数据进行前瞻性预测，并据此提前采取措施，将潜在影响降至最小）。

4.4 平稳降级机制

针对实际中出现的观众人数超过预配置容量的情况，构建了一套“优雅降级”机制，以在有限资源下持续提供直播服务。核心就是逐步关闭某些非关键功能。

• 按服务等级优先级的负载削减策略：优先保障直播流量，而延迟或舍弃预加载等非关键操作。
• 降低个性化体验，禁用书签功能，或降低最高画质标准。

4.4 应对重试风暴

重试分为两种：

1. 系统内部的重试机制。
2. 用户手动发起的重试，用户因直播中断（即便只有 30 秒）而重新进入流的行为，可能使系统负载激增 10 倍。

当系统接近容量上限时，重点是避免问题扩散或因重试行为导致系统进一步过载。基于对各类设备在面临网络超时或分片缺失等异常时的重试行为的研究，实施了多项缓解策略。

• 服务器引导式的重试退避（Backoff）。
• 在 Cloud Edge Gateway 层优先级调度以吸收突发流量。
• 多个云服务区域之间动态平衡流量。

4.5 应急响应机制

在直播这一场景下，当出现故障时，几乎没有时间进行排查。

• 对于重大直播事件，设立线下的in-person launch room，聚集关键系统的工程负责人现场待命。
• 开发一套用于快速检测和响应的核心指标，并为常见的运维问题准备了详尽的运行手册（Runbook）。目标是在上线当天不再“现学现用”，而是通过事前的“Game Day”演练让团队对突发事件的响应形成肌肉记忆。这些运行手册不仅面向工程团队，还涵盖了向高层管理的升级流程，以及客户服务、制作、传播、公关等职能部门之间的协调机制。