原文链接：A Brief History of Scaling Netflix
Netflix 于 1997 年以邮件-based DVD 租赁业务起家。Marc Randolph 和 Reed Hastings 在加州办公室和家之间拼车时想到了 Netflix 的创意。Hastings 很欣赏亚马逊，想通过找到一大类可通过互联网销售的便携商品来效仿他们的成功。大约就在 DVDs 在美国推出的时候，他们测试了通过邮件销售或租赁 DVDs 的概念。
快进到 2024 年，Netflix 已发展成为拥有全球超过 2.6 亿用户的视频流媒体服务。它的影响力如此巨大，以至于”Netflix 宕机”经常被视为紧急情况。
为了支持这一惊人的增长故事，Netflix 必须在多个维度上扩展其架构。
在本文中，我们试图揭开一些他们所面临的最重大扩展挑战以及这些挑战是如何被克服的。
Netflix 架构的起源
像任何希望在竞争激烈的市场中快速推出的初创公司一样，Netflix 最初是一个单体应用程序。
应用程序由单个可部署单元组成，带有单体数据库（Oracle）。如你所见，数据库是一个可能的单点故障。
这种可能性在 2008 年 8 月变成了现实。
出现了一个严重的数据库损坏问题，导致 Netflix 无法向客户运送任何 DVD 长达 3 天。突然间，很明显他们必须摆脱易于出现单点故障的垂直扩展架构。
购买 vs 构建
当 Netflix 在 2007 年推出时，EC2 刚刚开始，他们当时无法利用它。因此，他们建立了两个彼此相邻的数据中心。
然而，建立数据中心是大量的工作。你必须订购设备，等待设备到达并安装。在你完成之前，你已经再次用完了容量，需要重新经历整个周期。
为了打破这个循环，Netflix 选择了垂直扩展策略，这导致他们早期的系统架构被建模为单体应用程序。
然而，我们之前谈到的中断给 Netflix 上了一堂关键课——建立数据中心不是他们的核心能力。
这是一个庞大的决定，Netflix 采用了一些基本原则来指导他们度过这一变革：
- 首先，尽可能使用或贡献开源技术。
- 除了持久化或缓存层外，服务应以无状态方式构建。
- 采用混沌测试来证明实例宕机不会影响更广泛的系统。
- 水平扩展为你提供更长久的可扩展性跑道。
- 选择水平扩展而不是垂直扩展。
- 为任何事物制作多个副本。例如，副本数据库和多个服务实例。
- 通过隔离工作负载来减少任何问题的爆炸半径。
- 破坏性测试应成为正在进行的活动。
- 采用 Chaos Monkey 等工具来大规模执行此类测试。
这些指导原则充当了 Netflix 为构建能够根据需求扩展的架构而采取的每个转型项目的北极星。
无状态服务
Netflix 的整体架构分为三个部分：
客户端：这是你移动设备上的 Netflix 应用程序、计算机上的网站，甚至是智能电视上的应用程序。它包括用户可以浏览和流媒体 Netflix 视频的任何设备。Netflix 控制每个设备的每个客户端。
后端：这是控制在用户点击播放之前发生的所有事情的应用程序部分。它由在 AWS 上运行的多个服务组成，负责各种功能，如用户注册、准备传入视频、计费等。后端暴露多个 API，客户端利用这些 API 提供无缝的用户体验。
内容分发网络 (CDN)：也称为 Open Connect。它在世界各地不同的位置存储 Netflix 视频。当用户播放视频时，它从 Open Connect 流式传输并显示在客户端上。
需要注意的是，Netflix 控制所有三个领域，从而实现对其技术栈的完全垂直集成。
水平扩展 vs 垂直扩展
Netflix 必须扩展的一些关键领域如下：
- 扩展 Netflix CDN
- 扩展 Netflix Edge
冗余和隔离
自动化破坏性测试
扩展 Netflix CDN
想象一下，你正在新加坡观看视频，而视频是从波特兰流式传输的。这是一个巨大的地理距离，分成许多网络跳。在这种设置中必然会有延迟问题，导致用户体验变差。
如果将视频内容移到离观看者更近的地方，观看体验会更好得多。
这是在 Netflix 使用 CDN 背后的基本思想。
通过在世界各地的位置存储副本来尽可能将视频靠近用户。当用户想观看视频时，从最近的节点流式传输。
存储视频内容的每个位置称为 PoP 或存在点。它是一个提供互联网访问的物理位置，由服务器、路由器和其他网络设备组成。
然而，Netflix 花了多次迭代才将 CDN 扩展到适当的水平。
迭代 1 - 小型 CDN
当时，它拥有来自 50 个国家的超过 3500 万成员，每月流媒体超过 10 亿小时的视频。
为了支持这种使用，Netflix 在美国境内的五个不同地点构建了自己的 CDN。每个位置都包含所有内容。
迭代 2 - 第三方 CDN
原因是第三方 CDN 成本在下降，Netflix 投入大量时间和精力构建自己的 CDN 是没有意义的。正如我们所看到的，他们在运营自己的数据中心方面遇到了很多困难。
转向第三方解决方案也让他们有时间处理其他更高优先级的项目。然而，Netflix 确实在开发更智能的客户端应用程序以适应不断变化的网络条件方面投入了大量时间和精力。
例如，他们开发了切换到不同 CDN 以获得更好结果的技术。这样的创新使他们能够为用户在面临错误和过载网络时提供最高质量的体验。
迭代 3 - Open Connect
大约在 2011 年，Netflix 意识到他们在运营一个需要专用 CDN 来最大化网络效率和观看体验的规模。
流媒体业务现在是收入的主要来源，视频分发是 Netflix 的核心能力。如果他们能够以极高质量做到这一点，它可以变成巨大的竞争优势。
因此，2012 年 Netflix 推出了自己的 CDN，称为 Open Connect。
为了获得最佳性能，他们开发了自己的视频存储计算机系统，称为 Open Connect 设备或 OCA。
OCA 安装是多个 OCA 服务器的集群。每个 OCA 都是快速服务器，高度优化用于传输大文件。它们装满了大量硬盘或闪存驱动器来存储视频。
Open Connect CDN 的推出为 Netflix 带来了很多优势：
- 在提供全球服务方面更具可扩展性。
- 质量更好，因为他们现在可以控制从转码、CDN 到设备上客户端的整个视频路径。
- 与第三方 CDN 相比也更便宜。
扩展 Netflix Edge
Netflix 扩展难题中的下一个关键部分是边缘。
边缘是系统中靠近客户端的部分。例如，在 DNS 和数据库之间，DNS 更靠近客户端，可以被认为是更边缘的。把它看作是一个程度而不是固定值。
边缘是来自各种请求的数据进入服务域的地方。由于这是请求量最高的地方，因此扩展边缘至关重要。
Netflix Edge 在扩展方面经历了多个阶段。
早期架构
如你所见，这是一个典型的三层架构。
有客户端、API 和 API 对话的数据库。API 应用程序名为 NCCP（Netflix Content Control Protocol），它是唯一暴露给客户端的应用程序。所有关注点都放入这个应用程序中。
负载均衡器终止 TLS 并将纯流量发送到应用程序。此外，DNS 配置相当简单。想法是客户端应该能够找到并到达 Netflix 服务器。
这样的设计是由当时的业务需求决定的。他们有钱但不多。不过度复杂化事情并优化上市时间很重要。
增长期
随着客户群的增长，添加了更多功能。随着更多功能，公司开始赚更多钱。
此时，保持工程速度对他们来说很重要。这意味着将单体应用程序拆分为微服务。功能从 NCCP 应用程序中取出，作为具有单独数据的单独应用程序开发。
然而，在服务之间编排的逻辑仍在 API 内。来自客户端的传入请求击中 API，API 按正确顺序调用底层微服务。
本文为学习目的的个人翻译，译文仅供参考。
原文链接：A Brief History of Scaling Netflix。
版权归原作者或原刊登方所有。本文为非官方译本；如有不妥，请联系删除。