我来跟大家分享一下我学到的……

Netflix 是视频流媒体行业的巨头。凭借其创意和屡获殊荣的内容库，它在全球积累了大量的订阅用户。截至2024年第一季度，Netflix 的全球订阅用户数量达到了2.7亿。

每天有数百万的用户观看 Netflix，期望流畅且精彩的观看体验。在幕后，许多系统协同工作来确保这一切顺利进行。这些后台系统不断优化，以满足并超越大家的期望。

我在探索Netflix技术博客过程中收集了许多有用的信息。下面分享几个例子，展示Netflix面对的工程挑战，以及他们为了更好地服务会员而遵循创新优先的原则。

Netflix 收到他们电影和电视节目的高质量、原始且高质量的视频源，这些视频源通常由 Netflix 的内部制作团队和其他内容合作伙伴提供。然后对这些视频源进行编码处理，以便根据用户的设备和带宽情况提供最适合的视频体验。

视频编码使用了AWS EC2实例。云的弹性让它们能够根据负载无缝地扩展或缩减。长时间的任务被分割成较小的部分，以便可以并行处理，从而克服计算资源和本地存储的限制。

早期版本的视频编码管道采用集中式线性编码，支持标准分辨率的SDR。然而，随着4K和HDR内容的广泛接受和普及，Netflix转向了基于微服务架构的分布式块编码，充分利用了其所有功能。

Netflix 还在其导入和编码流程中实施了自动质量检测，以检测早期出现的编码问题，如画面受损、插入黑场、帧率调整、隔行扫描痕迹、画面冻结等。

在2022年，Netflix对其iOS和Android应用进行了重大改动。Netflix将移动应用程序的后端迁移到了GraphQL，并实现了零停机时间，这涉及从客户端到API层的全面重构。

在这次转变之前，移动应用是由基于内部开发的Falcor框架支持的单体式API。整个单体服务器及其API层均由同一个团队负责维护。

我们创建了一个位于现有单体应用Falcor API之上的GraphQL中间层服务，并通过对比错误率、延迟和页面渲染时间等指标来执行A/B测试，以评估其对客户的影響。

AB实验结果表明，GraphQL的正确性不如旧系统。接下来的几个月里，团队深入研究了关键指标并解决了这些问题。通过持续改进，Netflix在6个月内成功地将移动端首页的流量100%迁移到了GraphQL。

在第二阶段，为了验证新GraphQL API的功能正确性，对指向Falcor API的GraphQL shim进行了重放测试，并与基于GraphQL的视频API服务进行对比。这涉及到将相同的请求发送到两个端点，并对比响应之间的任何差异。回放测试工具会比较结果并输出响应负载中的任何差异。

回放测试验证了新GraphQL API的功能正确性。但是为了全面检查用户交互的健康状况，执行了粘滞金丝雀测试。

在 Sticky Canary 中，框架创建了一组独特的一组客户设备，然后在实验期间，框架会持续地将该池的流量路由到金丝雀和基准集群。除了测量服务级指标外，金丝雀框架还能够跟踪整个金丝雀池的指标，从而在整个请求生命周期中检测可能的退化。

就这样，Netflix 安全迁移到了 GraphQL，并且在规定时间内顺利完成，实现了无缝迁移。

带有基本广告的计划于11月3日（11月3rd）在全球范围内由奈飞公司推出。它带来了重要的技术挑战，即扩展了现有基础设施，以在播放路径中增加对广告合作伙伴的新远程调用。

Netflix 设计了一种新颖的方案，在正式发布前几周内模拟预期的流量，以测试新功能并增强团队对整体实现的信心。模拟真实世界的流量和会员观看行为非常重要，这一点至关重要。回放真实流量并使其表现为“带有广告的基本版”流量是一种更好的解决方案，比起人工模拟 Netflix 流量的方案更为理想。

Netflix的数据科学团队提供了“带广告的基本”套餐订阅者数量在推出一个月后的预测。Netflix利用这些信息通过其AB测试平台来模拟订阅者群体的行为。当符合AB测试条件的流量到达播放服务时，这些请求的副本会被存储起来。

Netflix 然后处理了请求流的复制请求，并在为重播流量准备的生产环境中重放了这些请求。环境服务被设置为将请求视为采用广告计划，从而激活了广告系统的相关部分。

回放流量环境产生了类似成员会收到的回应。Kafka消费者模拟一个设备正在播放内容并触发印象跟踪事件。分析了结果并进行了逐步改进。回放流量也逐步增加到100%，实现了24/7的全天候运行。

混沌工程是由奈飞公司创造的一个术语。混沌工程是一种测试分布式系统的方法，通过故意引入故障和异常情况来验证其在随机中断面前的稳定性。

这一切开始于Chaos Monkey的开发和使用。它会随机砍掉生产环境实例，以确保工程师们编写的服务能够应对实例故障。

接下来的一个创新是FIT（故障注入技术）。FIT用于直接向微服务中注入故障。它允许Netflix定义应用程序的故障注入点，比如REST、gRPC、GraphQL、数据库或缓存。它还允许Netflix定义微服务中处理的类型，比如故障、延迟或两者兼有。还可以设定范围，包括实例或集群。FIT比Chaos Monkey更为精准。

Netflix 后来开始使用请求上下文。自定义头部被添加到请求中以模拟 FIT 类型的失败。相较于 FIT，这种方式更好，因为它提供了更多的测试灵活性，可以在更细粒度的层面进行测试，通过测试请求和集群故障的场景来实现，而不是仅仅局限于集群故障的场景。

Canary策略被用来测试FIT，简称FIT。在Canary策略中，一小部分流量被导向Canary集群。随后，其行为与基线集群的行为进行对比，以检查是否有任何异常。虽然此策略非常有用，但仍无法完全传达成员的体验。

CRR（自定义资源路由机制）被实现为在请求中添加更多的头部信息，以确保被识别为金丝雀实验成员的始终被路由到金丝雀集群。这为请求增加了粘滞性。

监控是奈飞混沌工程中的一个重要环节。奈飞从会员设备和一级系统（一级服务）中收集事件数据（如流启动、流启动错误）和日志。然后将这些数据转化为计数器。之后，将金丝雀集群和基线集群的数据进行比较，以评估其抗故障能力。

Netflix OCP 是一个遍布全球的 CDN，旨在减少对 Netflix 服务器的流量。Netflix Open Connect 每天交付我们全部的视频流量，目前每天的观看时长超过 1.25 亿小时。

Open Connect 是一组专为特定用途设计的服务器设备，称为 Open Connect Appliances (OCAs)。这些设备存储编码的视频和图像文件，并通过 HTTP/HTTPS 向客户端设备提供这些文件。这些 OCAs 安装在互联网交换点 (IXP) 里，这些交换点直接与互联网服务提供商 (ISP) 对接，并直接安装在 ISP 的网络中。

Netflix 的几乎所有内容都是从这些 OCAs 提供，而不是直接从互联网获取。这些 OCAs 分布在超过 1000 个地点。从大城市到偏远角落，这些 OCAs 无处不在，从 ISP 直接将 Netflix 的数据流式传输给用户。

好了，这就是我发现的一些关键点，希望你们喜欢。在我阅读Netflix的各种技术博客时，发现了一些关键的学习点。如果你想了解更多，可以访问Netflix技术博客。这确实是一个极佳的学习体验。如果你喜欢这篇文章，请不要忘了点个赞、转发并留下你的评论。非常感谢你的支持！