Netflix 的系统如何支撑千万人同时观看直播?

前阵子 Alex Honnold 不带任何装备徒手爬上台北 101 大楼的最高点，在全球掀起一阵讨论。身为软件工程师，在看直播流手汗的同时，不免好奇「Netflix 的直播背后是如何撑起全球观众同时收看」这个问题。具体查了一下，Netflix 截至今最多人观看的直播节目，有超过六千五百万人同时收看，是个非常惊人的数字。

虽然我们自己没有开发过直播平台，不过 Netflix 的官方技术博客，有出过不少篇跟直播相关的技术文章。对此，希望通过这篇文章，展开讨论 Netflix 工程团队的分享，来一探相关的技术精华。

比起随选流媒体，直播有哪些技术挑战?

在读 Netflix 的直播相关技术文章前，我们有的第一个疑问是「Netflix 的随选流媒体 (on-demand streaming) 已经在高吞吐、低延迟，以及可靠都做很好，直播有哪些额外技术挑战是原本的技术无法解决的呢?」。换句话说，虽然直播同时有六千多万人观看，但在热门节目上线时 (例如当年的鱿鱼游戏风潮)，同时观看人数也不会少去哪，直播为什么在技术上更有挑战性?

直播比起随选流媒体，需要在极短的时间，完成从摄影机接收、编码和传输，即时处理要保持低延迟并不容易。在观看模式上，由于直播可能因为突发事件而涌入大量观众 (例如某个明星发了一个限动说自己在看，如果是直播，观众多半会想马上转来看，但如果是随选的流媒体，就比较不会有这种想马上跟看的急迫性)。

在播放缓冲上，随选的流媒体可以预先把所有内容都预加载；但是直播没有办法，所以缓冲的片段比较少。同时因为是即时的，观众对于错误容忍度比较低 (多数人比较不能接受直播被中断)，因此团队在维运上的压力比较大。

在了解这些区别后，接着让我们来看 Netflix 团队如何架构与应对这些挑战。

整体架构

首先，让我们看到 Netflix 直播的整体架构，我们大致可以把直播架构分成三个部分。

这三部分别为：

• 获取直播内容：直播的起点来自于摄影机与收音设备等捕捉到的内容。收到内容后会先进到运营中心做基本检测 (例如内容没问题、讯号品质没问题)。先前 Netflix 有说 Alex Honnold 的直播有 10 秒延迟，如果他不幸摔下会即时切断，切断会在这个步骤进行。
• 流媒体即时处理：直播内容通过检测后，会进行影片的转码，这样直播影片才能相容于不同使用者的装置；接着也会进行封装，让分发可以更紧密整合到播放系统中。
• 在全球分发直播内容：处理完后的直播内容会通过 CDN 从源站分发到全球各地的边缘服务器，让观众可以从最近的服务器取得内容，降低延迟。

如何确保可用?

对于直播服务来说，要面对的各种不同装置，例如电视 App、网页 App、手机的 App，不同装置支援的格式可能不同；同时也需要面对不同的网络传输速度，例如在开发中的国家，可能会遇到网速低与不稳定的状况。

要确保不论使用者用哪种装置、不论哪种网速与稳定度，都要能顺畅播放直播，就需要转码的过程。

具体来说，当收到最初的讯号源后，在转码的过程会转成多种不同影音格式、多种不同画质的比特率；这样即使在比较低阶的装置，或者比较慢的网速，也能够观看直播。假如没有做这个步骤，Netflix 在拍摄直播都是用最高规格的摄影机，拍出超高解析度的影片，可能在旧一点的装置播不了，网速慢一点可能也下载不动。

在上图的架构中，有一个关键是冗余 (redundancy)。Netflix 为了避免单点故障 (single points of failure)，建立了两条独立的直连网络来接收讯号，并且确保中间从转码到封装都独立进行。这样一来，即使其中一条有网络问题或设备故障，也能确保有另一层防护。

如何降低延迟?

当提到延迟，就不能不讨论传输协议。当谈到加快传输速度，多数人可能会想到在传输层使用 UDP 这个协议，而非使用 TCP。

UDP 比起 TCP 的一大特色，是如果传输过程中封包有丢失，UDP 不会管，就放其丢失，所以传输速度比 TCP 快。对比起来，TCP 的传输更可靠，但因为求可靠，封包丢失时会等待重传，自然会比较慢一点。

虽然重视低延迟，不过 Netflix 并没有使用 UDP，而是使用基于 TCP 的 HTTP。之所以会有这个技术选择，主要有几个原因，第一个是对于直播品质的考量，Netflix 希望做到高品质的直播稳定性，用 UDP 可能导致掉帧，这是从品质角度来看希望能避免的。除此之外，选择 HTTP 的好处在于，各类装置几乎都对 HTTP 支援，所以能在编码与分发上，都能够相容。

而从延迟的角度来看，Netflix 通过把文件切割成一小段一小段来传输的方式，有效降低延迟度。具体来说，Netflix 采用 2 秒片段时长的切割 (2-second segment duration)。当这么做，编码器 (encoder) 只要每生成一个 2 秒的片段，就可以传出去，让终端的播放器可以消费，不用等到整段片段都生成好后才能传输。

当然，这个选择也不是没有成本，因为从压缩的效率来看，片段越长的压缩效率越高，对服务器负担会比较小。不过在权衡之下，选择 2 秒片段时长的切割，能确保直播稳定不掉帧，同时让延迟度达到业界标准。

阅读更多

如果对 Netflix 团队如何让系统有效扩展、实务上如何做可靠性工程感兴趣，我们在 E+ 成长计画中的主题文都有谈到。

对更深入了解这个主题，以及其他前后端开发、软件工程、AI 工程主题感兴趣的读者，欢迎加入 E+ 成长计画一起成长 (链接)。