这是关于 Netflix 如何利用微服务重建其视频处理管道的系列博文的第一篇，以便我们能够保持快速的创新步伐，并不断改进会员流媒体和工作室运营系统。这篇介绍性博文重点概述了我们的历程。未来的博文将更深入地介绍每项服务，分享从这一过程中获得的见解和经验教训。
Netflix 视频处理管道于 2007 年随着流媒体服务的推出而投入使用。自那时起，视频管道经历了实质性的改进和广泛的扩展：
从标准定义的标准动态范围 (SDR) 开始，我们将编码管道扩展到 4K 和高动态范围 (HDR)，从而支持我们的高级产品。我们从集中式线性编码转向分布式基于块的编码。这种架构转变大大降低了处理延迟并提高了系统弹性。我们不再使用数量受限的专用实例，而是利用了 Netflix由于自动扩展微服务而产生的内部低谷，从而显著提高计算弹性和资源利用效率。我们推出了针对每个标题和每个镜头的优化等编码创新，这为 Netflix 会员提供了显著的体验质量 (QoE) 改进。通过与工作室内容系统集成，我们使管道能够利用来自创意方面的丰富元数据，并创造更具吸引力的会员体验，例如互动式讲故事。我们扩展了管道支持以满足我们的工作室/内容开发用例的需求，与传统的流媒体用例相比，这些用例具有不同的延迟和弹性要求。过去十五年的经验让我们更加坚信，高效、灵活的视频处理管道对于 Netflix 的持续成功至关重要，它使我们能够创新并支持我们的流媒体服务以及我们的工作室合作伙伴。为此，编码技术 (ET) 的视频和图像编码团队在过去几年中一直在我们的下一代基于微服务的计算平台Cosmos上重建视频处理管道。
从 Reloaded 到 Cosmos重装上阵从 2014 年开始，我们在第三代平台Reloaded上开发并运行视频处理管道。Reloaded 架构良好，具有良好的稳定性、可扩展性和合理的灵活性。它为我们团队开发的众多编码创新奠定了基础。
在设计 Reloaded 时，我们专注于一个用例：将从工作室收到的高质量媒体文件（也称为 mezzanines）转换为用于 Netflix 流媒体的压缩资产。Reloaded 是作为一个单一的整体系统创建的，来自 ET 各个媒体团队的开发人员和我们的平台合作伙伴团队内容基础设施和解决方案 (CIS)¹ 在同一代码库上工作，构建了一个处理所有媒体资产的单一系统。多年来，该系统不断扩展以支持各种新用例。这导致系统复杂性显著增加，Reloaded 的局限性开始显现：
功能耦合： Reloaded 由多个工作模块和一个编排模块组成。设置新的 Reloaded 模块并将其与编排模块集成需要付出大量努力，这导致在开发新功能时偏向于增强而不是创造。例如，在 Reloaded 中，视频质量计算是在视频编码器模块内实现的。在这种实现中，如果不重新编码，就很难重新计算视频质量。整体结构：由于 Reloaded 模块通常位于同一个存储库中，因此很容易忽略代码隔离规则，并且在本应是强边界的地方存在大量无意的代码重用。这种重用造成了紧密耦合并降低了开发速度。模块之间的紧密耦合进一步迫使我们将所有模块一起部署。发布周期长：联合部署意味着人们越来越担心意外生产中断，因为对于这种规模的部署来说，调试和回滚可能很困难。这推动了“发布列车”的方法。每两周，对所有模块进行一次“快照”，并将其提升为“候选版本”。然后，这个候选版本经过详尽的测试，试图覆盖尽可能大的表面积。这个测试阶段大约需要两周时间。因此，根据代码更改的合并时间，可能需要两到四周的时间才能投入生产。随着时间的推移和功能的增加，Reloaded 中新功能贡献率下降。由于需要大量工作来克服架构限制，一些有前途的想法被放弃。曾经为我们带来良好服务的平台现在成为了开发的拖累。
宇宙作为回应，CIS 和 ET 团队于 2018 年开始开发下一代平台 Cosmos。除了开发人员在 Reloaded 中已经享受到的可扩展性和稳定性之外，Cosmos 还旨在显著提高系统灵活性和功能开发速度。为了实现这一目标，Cosmos 被开发为工作流驱动、以媒体为中心的微服务的计算平台。
微服务架构提供了服务之间的强大解耦。每个微服务的工作流支持减轻了实现复杂媒体工作流逻辑的负担。最后，相关的抽象使媒体算法开发人员能够专注于视频和音频信号的操作，而不是基础设施问题。Cosmos 提供的全面优势列表可在链接的博客中找到。
在 Cosmos 中构建视频处理管道服务边界在微服务架构中，系统由许多细粒度的服务组成，每个服务专注于单一功能。因此，第一件事（也可以说是最重要的一件事）是确定边界并定义服务。
在我们的管道中，媒体资产从创建到采集再到交付，需要经过一系列处理步骤，例如分析和转换。我们分析了这些处理步骤，以确定“边界”，并将它们分组到不同的域中，这些域又成为我们设计的微服务的构建块。
举个例子，在Reloaded中，视频编码模块包含5个步骤：
1. 将输入视频分成小块
2. 独立编码每个块
3. 计算每个块的质量得分（VMAF ）
4. 将所有编码块组合成单个编码视频
5. 汇总所有块的质量得分
从系统角度来看，组装的编码视频是主要关注点，而内部分块和单独分块编码是为了满足某些延迟和弹性要求而存在的。此外，如上所述，与编码服务相比，视频质量计算提供了完全独立的功能。
因此，在 Cosmos 中，我们创建了两个独立的微服务：视频编码服务 (VES) 和视频质量服务 (VQS)，每个服务都具有明确、解耦的功能。作为实现细节，分块编码和组装被抽象到 VES 中。
视频服务上面概述的方法被应用于视频处理流程的其余部分，以识别功能并由此确定服务边界，从而创建以下视频服务²。
视频检测服务 (VIS)：此服务以夹层作为输入并执行各种检测。它从夹层的不同层中提取元数据以供下游服务使用。此外，如果发现无效或意外的元数据，检测服务会标记问题并向上游团队提供可操作的反馈。复杂性分析服务 (CAS)：最佳编码方案高度依赖于内容。此服务以夹层作为输入并进行分析以了解内容复杂性。它调用视频编码服务进行预编码，并调用视频质量服务进行质量评估。结果保存到数据库中，以便可以重复使用。阶梯生成服务 (LGS)：此服务为给定的编码系列 (H.264、AV1 等) 创建整个比特率阶梯。它从 CAS 获取复杂度数据并运行优化算法来创建编码方案。CAS 和 LGS 涵盖了我们之前在技术博客中介绍的许多创新（按标题、移动编码、按镜头、优化 4K 编码等）。通过将阶梯生成包装到单独的微服务 (LGS) 中，我们将阶梯优化算法与复杂度分析数据的创建和管理（驻留在 CAS 中）分离开来。我们希望这能为我们提供更大的实验自由和更快的创新速度。视频编码服务 (VES)：此服务采用中间层和编码配方来创建编码视频。配方包括所需的编码格式和输出属性，例如分辨率、比特率等。该服务还提供了允许根据用例微调延迟、吞吐量等的选项。视频验证服务 (VVS)：此服务接收编码视频和编码期望列表。这些期望包括编码配方中指定的属性以及编解码器规范中的一致性要求。VVS 分析编码视频并将结果与指示的期望进行比较。任何差异都会在响应中标记以提醒调用者。视频质量服务（VQS）：该服务以夹层和编码视频作为输入，并计算编码视频的质量分数（VMAF）。服务编排每个视频服务都提供专用功能，它们协同工作以生成所需的视频资产。目前，Netflix 视频管道的两个主要用例是为会员流媒体和工作室运营生成资产。对于每个用例，我们创建了一个专用的工作流程编排器，以便可以定制服务编排以最好地满足相应的业务需求。
对于流媒体用例，生成的视频将部署到我们的内容交付网络 (CDN) 供 Netflix 会员使用。这些视频可以轻松观看数百万次。流媒体工作流编排器利用几乎所有的视频服务来创建流媒体，以提供无可挑剔的会员体验。它利用 VIS 检测和拒绝不合格或低质量的中间件，调用 LGS 进行编码配方优化，使用 VES 对视频进行编码，并调用 VQS 进行质量测量，其中质量数据进一步输入到 Netflix 的数据管道以进行分析和监控。除了视频服务之外，流媒体工作流编排器还使用音频和定时文本服务来生成音频和文本资产，并使用打包服务来“容器化”资产以进行流媒体播放。
对于工作室用例，一些示例视频资产是营销剪辑和每日制作编辑代理。来自工作室方面的请求通常对延迟敏感。例如，制作团队中的某个人可能正在等待视频审核，以便他们可以决定第二天的拍摄计划。因此，Studio Workflow Orchestrator 优化了快速周转并专注于核心媒体处理服务。此时，Studio Workflow Orchestrator 调用 VIS 来提取所摄取资产的元数据，并使用预定义的配方调用 VES。与成员流媒体相比，工作室运营对视频处理有不同的独特要求。因此，Studio Workflow Orchestrator 是某些编码功能（如法医水印和时间码/文本刻录）的独家用户。
我们现在的情况几年来，我们一直在生产 Reloaded 的同时运行新的视频管道。在此期间，我们完成了从 Reloaded 迁移所有必要功能的工作，开始逐步逐个用例转移流量，并于 2023 年 9 月完成了切换。
虽然还处于早期阶段，但我们已经看到了新平台的优势，特别是功能交付的便利性。值得注意的是，Netflix 于 2022 年 11 月推出了广告支持计划。处理广告创意带来了一些新的挑战：广告的媒体格式与团队熟悉的电影和电视夹层完全不同，并且有一组与广告业务需求相关的新媒体处理要求。借助 Cosmos 的模块化和开发人员生产力优势，我们能够快速迭代管道以跟上不断变化的需求并支持成功的产品发布。
概括重建视频管道对团队来说是一项艰巨的任务。我们为所取得的成就感到自豪，也渴望与技术社区分享我们的历程。本博客主要提供概述：我们的管道和平台的简要历史、重建的必要性、这些新服务的外观以及它们如何用于 Netflix 业务。在下一篇博客中，我们将深入探讨视频编码服务 (VES) 的细节，逐步解释服务创建过程，并分享经验教训（我们有很多经验教训！）。我们还计划在未来的技术博客中介绍其他视频服务。关注Netflix 技术博客以了解最新动态。
致谢向 CIS 团队致以最诚挚的谢意，感谢他们在构建 Cosmos 平台过程中所做的出色工作，以及他们对服务开发人员反馈的积极接受。
我们要向我们的用户、流媒体编码管道团队和视频工程团队表示感谢。就像我们的反馈有助于完善平台一样，用户的反馈对于构建高质量的服务也起到了重要作用。
我们还要感谢 Christos Bampis 和 Zhi Li 对视频服务的重大贡献，以及我们两位前团队成员 Chao Chen 和 Megha Manohara 对该项目早期开发的贡献。
脚注前身为媒体云工程/MCE 团队。实际的视频服务数量远不止这里列出的数量。其中一些是 Netflix 独有的，因此本篇博文中省略了。作者:Liwei Guo, Anush Moorthy, Li-Heng Chen, Vinicius Carvalho, Aditya Mavlankar, Agata Opalach, Adithya Prakash, Kyle Swanson, Jessica Tweneboah, Subbu Venkatrav, Lishan Zhu
出处:https://netflixtechblog.com/rebuilding-netflix-video-processing-pipeline-with-microservices-4e5e6310e359
