Netflix Cosmos平台。 协调功能– Netflix TechBlog

Cosmos是一个计算平台，将微服务的最佳方面与异步工作流和无服务器功能结合在一起。它的优点是应用程序涉及资源密集型算法，这些算法通过复杂的层次化工作流进行协调，持续时间长达数分钟到数年。它既支持一次消耗数十万个CPU的高吞吐量服务，又支持对延迟敏感的工作负载，在这些负载下，人们正在等待计算结果。

本文将说明我们构建Cosmos的原因，其工作方式并分享我们在此过程中学到的一些知识。

Netflix的媒体云工程和编码技术团队共同运营一个系统，用于处理来自我们的合作伙伴和工作室的传入媒体文件，以使其在所有设备上均可播放。该系统的第一代于2007年以流媒体发布的形式投入使用。第二代增加了规模，但极难操作。第三代被称为Reloaded，已经上线大约七年了，并且已经证明是稳定且可大规模扩展的。

在设计Reloaded时，我们是一小组开发人员，他们在一个受限的计算集群中运行，并专注于一个用例：视频/音频处理管道。随着时间的流逝，开发人员的数量增加了两倍多，用例的广度和深度不断扩展，我们的规模增加了十倍以上，单片式架构显着降低了新功能的交付速度。我们再也不能期望每个人都拥有构建和部署新功能所必需的专业知识。由于基础架构代码与应用程序代码混合在一起，因此处理生产问题成为一项繁重的琐事，使所有开发人员都需缴纳税收。当我们还是一个小团队时，对我们有用的集中式数据模型就成了一种责任。

我们的回应是创建Cosmos，这是一个以工作流程为驱动，以媒体为中心的微服务的平台。首要目标是在提供以下功能的同时保留我们当前的功能：

模块化—一种自以为是的框架，用于构建服务并启用编译时和运行时模块化。

生产力-本地开发工具，包括专门的测试运行器，代码生成器和命令行界面。

交付—全面管理的连续交付系统，包括管道，连续集成作业以及端到端测试。当您合并拉取请求时，它无需人工干预即可投入生产。

在此期间，我们还对可伸缩性，可靠性，安全性和其他系统质量进行了改进。

Cosmos服务不是微服务，但是有很多相似之处。典型的微服务是具有无状态业务逻辑的API，该API可根据请求负载自动缩放。该API与对等方提供了强有力的合同，同时将应用程序数据和二进制依赖项与其他系统隔离开来。

Cosmos服务保留了微服务的强大合同和隔离的数据/依赖关系，但添加了多步工作流和计算密集型异步无服务器功能。在典型Cosmos服务的下图中，客户端将请求发送到视频编码器服务API层。一组规则协调工作流步骤，以及一组无服务器功能为特定于域的算法提供支持。函数打包为Docker映像，并带来它们自己的特定于媒体的二进制依赖项（例如debian软件包）。它们根据队列大小进行缩放，并且可以在成千上万个不同的容器上运行。请求可能需要几个小时或几天才能完成。

宇宙有两个分离轴。一方面，逻辑在API，工作流和无服务器功能之间划分。另一方面，逻辑在应用程序和平台之间是分开的。平台API为应用程序开发人员提供了特定于媒体的抽象，同时隐藏了分布式计算的详细信息。例如，视频编码服务由与规模无关的组件构成：API，工作流和功能。他们对他们的经营规模没有特别的了解。这些特定于域的，与规模无关的组件是建立在三个可感知规模的Cosmos子系统之上的，这些子系统处理分配工作的细节：

子系统都通过Timestone（一种大规模，低延迟优先级排队系统）彼此异步通信。每个子系统都解决了服务的不同问题，并且可以通过专门构建的托管连续交付流程来独立部署。关注点的分离使编写，测试和操作Cosmos服务变得更加容易。

上图是可观察性门户网站Nirvana的屏幕截图。它显示了Cosmos中的典型服务请求（在这种情况下为视频编码器服务）：

有一个用于编码的API调用，其中包括视频源和配方

视频被分成31个块，并且31个编码功能并行运行

Cosmos支持服务的分解和分层。最终的模块化体系结构使团队可以专注于其专业领域，并控制其API和发布周期。

例如，上面提到的视频服务只是用于创建可在设备上播放的流的众多视频服务之一。这些服务（包括检查，音频，文本和包装）是使用更高级别的服务精心编排的。其中最大，最复杂的是Tapas，它负责从制片厂获取资源并使其可在Netflix服务上播放。另一个高级服务是Sagan，它用于摄影棚的业务，如市场营销剪辑或日常制作编辑代理。

当生产工作室收到新标题时，它将触发Tapas工作流，该工作流程会协调执行检查的请求，对视频进行编码（多种分辨率，质量和视频编解码器），对音频进行编码（多种质量和编解码器），生成字幕（许多语言） ，然后打包结果输出（多种播放器格式）。因此，对Tapas的单个请求可能导致对其他Cosmos服务的数百个请求以及成千上万的Stratum函数调用。

下面的跟踪显示了一个示例，该示例说明了顶级服务上的请求如何向下传播到较低级别的服务，从而导致许多不同的操作。在这种情况下，请求需要24分钟才能完成，涉及数百种不同的动作，涉及8种不同的Cosmos服务和9种不同的Stratum功能。

还是我们应该说工作流程规则？柏拉图是通过为服务开发人员提供一个定义域逻辑和协调无状态功能/服务的框架，将Cosmos中的所有内容联系在一起的粘合剂。 Optimus API层具有内置的功能，可以调用工作流程并检查其状态。无层服务器层生成强类型的RPC客户端，以使调用无服务器功能变得简单而直观。

柏拉图是一个前向链接规则引擎，可使其适用于我们算法的异步和计算密集型性质。与Netflix的Conductor这样的程序性工作流引擎不同，Plato使创建“始终在线”的工作流变得容易。例如，随着我们开发更好的编码算法，基于规则的工作流程将自动管理更新现有视频，而无需触发和管理新的工作流程。此外，任何工作流程都可以调用另一个工作流程，从而实现了上述服务的分层。

Plato是一个多租户系统（使用Apache Karaf实现），可以大大减少工作流程的操作负担。用户在自己的源代码存储库中编写和测试他们的规则，然后通过将编译后的代码上传到Plato服务器来部署工作流。

开发人员通过以Emirax（一种基于Groovy构建的领域特定语言）编写的规则来指定其工作流程。每个规则有4个部分：

动作：指定触发该规则时要执行的代码；在这里，您可以调用Stratum函数来处理请求。

在这些部分的每一个中，您通常通常首先记录工作流程的状态变化，然后执行将工作流程向前移动的步骤，例如执行Stratum函数或返回执行结果（有关更多详细信息，请参见此演示文稿）。

像Sagan这样的Cosmos服务对时延敏感，因为它们是面向用户的。例如，正在剪辑社交媒体帖子的艺术家在剪辑《 Money Heist》最新一季的视频时，不想等待很长时间。对于Stratum，延迟是执行工作的时间加上获取计算资源的时间的函数。当工作非常繁忙时（通常是这种情况），“获取资源的时间”部分成为重要因素。举例来说，假设您购物时通常会购买的东西之一是厕纸。通常，将其放入购物车并通过结帐行没有问题，整个过程需要30分钟。

然后有一天，一件坏病毒事件发生了，每个人都决定他们同时需要更多的卫生纸。由于整体需求超出了可用容量，您的厕纸等待时间现在从30分钟缩短到两周。面对突发性和不可预测的需求，Cosmos应用程序（尤其是Stratum功能）也存在相同的问题。 Stratum通过以下几种方式管理功能执行延迟：

资源池。最终用户可以为自己的业务用例保留Stratum计算资源，并且资源池是分层的，以允许用户组共享资源。

保暖能力。最终用户可以在需求之前请求计算资源（例如容器），以减少Stratum中的启动延迟。

微批次。 Stratum还使用微批处理，这是在Apache Spark等平台中发现的一种技巧，可以减少启动延迟。这个想法是将启动成本分散到许多函数调用中。如果您调用函数10,000次，则该函数可以在10,000个容器上运行一次，也可以在1000个容器中运行10次。

优先。当在成本与低延迟需求之间取得平衡时，Cosmos服务通常位于中间位置：足够的资源来处理典型的突发事件，但不足以处理具有最低延迟的最大突发事件。通过对工作进行优先级排序，即使在资源短缺的情况下，应用程序仍可以确保以低延迟处理最重要的工作。 Cosmos服务所有者可以允许最终用户设置优先级，或者在API层或工作流程中自行设置优先级。

Tapas之类的服务对吞吐量很敏感，因为它们消耗大量的计算资源（例如每天数百万个CPU小时），并且更关注在几个小时或几天内完成任务，而不是关注完成单个任务的时间。换句话说，服务水平目标（SLO）以每天的任务和每个任务的成本而不是每秒的任务来度量。

对于吞吐量敏感的工作负载，最重要的SLO是Stratumless无服务器层提供的SLO。构建在Titus容器平台之上的Stratum允许吞吐量敏感的工作负载通过灵活的资源调度使用“机会”计算资源。例如，如果愿意等待一个小时来执行，则无服务器功能调用的成本可能会更低。

我们知道，移动一个像Reloaded一样大而复杂的旧系统将是一个巨大的跨越，这是一个充满失败的重新设计项目碎片的危险鸿沟，但是毫无疑问，我们必须跳过。为了降低风险，我们采用了扼杀者无花果模式，该模式可使新系统在旧系统周围扩展，并最终完全替换它。

我们于2018年开始构建Cosmos，并自2019年初开始投入生产。今天，大约有40种cosmos服务，并且我们预计会有更多的增长。我们仍处于旅途中，但我们可以分享一些到目前为止所学知识的亮点：

Netflix的工程文化著名地是依靠个人判断而不是自上而下的控制。软件开发人员既有自由也有承担风险和做出决策的责任。我们都没有软件设计师的头衔。我们所有人都扮演着这个角色。在这种情况下，Cosmos脱颖而出，并从局部优化的不同尝试开始。 Optimus，Plato和Stratum是独立构思的，最终融合为一个平台的愿景。团队中的应用程序开发人员使每个人都专注于用户友好的API和开发人员的生产力。基础架构和媒体算法开发人员之间建立了牢固的伙伴关系，以将愿景变为现实。我们不可能在自上而下的工程环境中做到这一点。

我们发现，“触发微服务编排无服务器功能的工作流的微服务”的编程模型是一个强大的范例。它对我们的大多数用例都适用，但是某些应用程序非常简单，以至于增加的复杂性是不值得的。

从大型分布式应用程序迁移到“平台加应用程序”是一个重大的范式转变。每个人都必须改变观念。应用程序开发人员必须放弃一定程度的灵活性，以换取一致性，可靠性等。平台开发人员必须开发更多的同理心，并优先考虑客户服务，用户生产力和服务水平。有时候，应用程序开发人员会感到平台团队没有适当地专注于他们的需求，而有时候，平台团队却因用户需求而感到负担过重。我们彼此坦诚相待，度过了这些难关。例如，在最近的回顾之后，我们加强了横切系统质量的开发轨道，例如开发人员的经验，可靠性，可观察性和安全性。

我们启动Cosmos的目标是使开发人员能够更好，更快地工作，将更多时间花在解决业务问题上，而减少处理基础结构的时间。有时目标似乎难以实现，但我们开始看到我们所希望获得的收获。开发人员在Cosmos中最喜欢的一些系统质量是托管交付，模块化和可观察性以及开发人员支持。我们正在努力提高这些品质，同时还在较弱的领域（如本地发展，弹性和可测试性）上开展工作。

对于2021年来说，对于Cosmos来说将是重要的一年，因为我们会将大部分工作从Reloaded转移到Cosmos中，这将带来更多的开发人员和更高的负载。我们计划发展编程模型以适应新的用例。我们的目标是使Cosmos更易于使用，更具弹性，更快，更高效。请继续关注以了解有关Cosmos如何工作以及我们如何使用它的更多详细信息。