共计 5709 个字符，预计需要花费 15 分钟才能阅读完成。
简介：2021 年，Netflix 会将大部分的工作负载从 Reloaded 转移到 Cosmos 平台。Cosmos 是一个计算平台，它将微服务的最佳个性与异步工作流以及 Serverless 联合在一起。
作者 | Frank San Miguel
策动 | 田晓旭
2021 年，Netflix 会将大部分的工作负载从 Reloaded 转移到 Cosmos 平台。Cosmos 是一个计算平台，它将微服务的最佳个性与异步工作流以及 Serverless 联合在一起。
介绍
Cosmos 是一个计算平台，它将微服务的最佳个性与异步工作流以及 Serverless（无服务器）联合在一起。它的最佳利用是用于波及到资源密集型算法的应用程序中，这些算法通过简单的层次化工作流进行协调，能够继续几分钟到几年。它既反对一次耗费数十万个 CPU 的高吞吐量服务，也反对须要期待计算结果对提早敏感的工作负载。
（一个 Cosmos 服务）
本文将会解释咱们建造 Cosmos 的起因以及它的工作原理，同时也会分享一些咱们在此过程中学到的常识。
背景
Netflix 的媒体云工程和编码技术团队独特经营一个零碎，解决来自咱们的合作伙伴以及工作室的输出媒体文件，使它们能够在所有设施上播放。该零碎的第一代于 2007 年推出了流媒体技术。第二代减少了扩缩容，但操作极为艰难。第三代被称为 Reloaded，也曾经上线 7 年了，并且已被证实是稳固的且可进行大规模扩缩容的。
在设计 Reloaded 时，咱们是一个由开发人员组成的小团队，操作一个受限的计算集群，并专一于惟一的用例：视频 / 音频解决管道。随着工夫的推移，开发人员的数量减少了三倍多，咱们的用例广度和深度也都扩充了，咱们的规模增长了十多倍。单体架构大大降低了新个性的交付速度。咱们不能再冀望每个人都领有构建和部署新个性所必须的专业知识了。因为基础设施代码和利用程序代码都混在了一起，导致解决生产问题成为一项沉重的琐事，这给所有开发人员都带来了累赘。当咱们还是一个小团队的时候，集中式数据模型能很好地服务于咱们，但当初它成了咱们的累赘。
咱们的响应是创立 Cosmos，这是一个由工作流驱动、以媒体为核心的微服务平台。咱们的首要指标是在保留咱们以后能力的同时提供以下性能：
可察看性——通过内置的日志、跟踪、监控、报警以及谬误分类来实现。
模块化——用于结构服务并反对编译时和运行时模块化的一个“自以为是”的框架。
生产力——本地开发工具，包含专门的测试运行程序、代码生成器和命令行界面。
交付——一个被全面治理的管道、继续集成作业和端到端测试的继续交付零碎。当你合并 pull 申请时，它能够在没有人干涉的状况下将其投入到生产环境中。
在此期间，咱们还对可伸缩性、可靠性、安全性和其余零碎品质进行了改良。
概述
Cosmos 服务不是微服务，然而它们有很多相似之处。典型的微服务是一个具备无状态业务逻辑的 API，它能够依据申请负载主动扩缩容。该 API 提供了与对等方之间的强契约，同时将利用数据和二进制依赖关系与其余零碎隔离开来。
（一个典型的微服务）
Cosmos 服务保留了微服务的强契约和相隔离的数据 / 依赖关系，但增加了多步工作流和计算密集型异步 Serverless 函数。下图展现了一个典型的 Cosmos 服务，在该服务中，客户端将申请发送到视频编码器服务的 API 层。一组规定编排工作流步骤，一组 Serverless 函数执行特定畛域的算法。函数被打包为 Docker 镜像，并带有它们本人特定于媒体的二进制依赖项（例如 debian 包）。它们依据队列的大小进行扩缩容，能够在成千上万的不同容器上运行。申请可能须要数小时或数天能力实现。
（一个典型的 Cosmos 服务）
关注点拆散
Cosmos 有两条拆散轴。一方面，逻辑被划分为 API、工作流和 Serverless 函数。另一方面，逻辑在应用程序和平台之间也是拆散的。平台 API 为应用程序开发人员提供了特定于媒体的形象，同时暗藏了分布式计算的细节。例如，视频编码服务是由与扩缩容无关的组件构建的：API、工作流和函数。他们对本人的扩缩容没有特地的理解。这些特定于畛域的、扩缩容不可知的组件构建在三个 扩缩容可感知的 Cosmos 子系统上，这些子系统负责解决散发工作的细节：
Optimus，一个将内部申请映射到外部业务模型的 API 层。
Plato，一个用于业务规定建模的工作流层。
Stratum，一个 Serverless 层，用于运行无状态以及计算密集型函数。
所有这些子系统都通过 Timestone（一种大规模、低提早的优先级队列零碎）进行异步通信。每个子系统解决服务的不同关注点，并且能够通过专门构建的托管继续交付流程独立部署。这种关注点的拆散使得编写、测试和操作 Cosmos 服务更加容易。
（平台与应用程序拆散）
Cosmos 服务申请
（Cosmos 服务申请的跟踪图）
上图是咱们的察看门户网站 Nirvana 的截图。它展现了 Cosmos 中的一个典型服务申请（在本例中是一个视频编码器服务）：
有一个用于编码的 API 调用，其中包含视频源和“配方”。
视频被分成 31 个块，并且有 31 个编码函数并行运行。
组装函数只被调用一次。
索引函数只被调用一次。
8 分钟后工作流实现。
服务分层
Cosmos 反对服务的合成和分层。由此产生的模块化架构容许团队专一于他们本人的业余畛域，并管制本人的 API 和公布周期。
例如，下面提到的视频服务只是泛滥用于创立可在设施上播放的流的服务之一。这些服务还包含查看、音频、文本和包装，它们是用更高级别的服务精心编排的。其中最大、最简单的是 Tapas，它负责从工作室获取资源，并使这些资源能够在 Netflix 服务上播放。另一个高级服务是 Sagan，它用于工作室的操作，如营销剪辑或日常制作编辑代理等。
（Cosmos 服务分层）
当制作工作室有新作品时，它会触发一个 Tapas 工作流，该工作流会编排执行查看的申请、编码视频（多种分辨率、品质、视频编解码器）、编码音频（多种品质、编解码器）、生成字幕（多种语言）并打包后果输入（多个播放器格局）。因而，对 Tapas 的单个申请可能导致对其余 Cosmos 服务的数百个申请以及数千个 Stratum 函数调用。
上面的跟踪示例展现了一个顶级服务中的申请是如何向上流到较低级别的服务中，从而导致许多不同操作的。在这种状况下，申请须要 24 分钟能力实现，数百个不同的口头波及 8 个不同的 Cosmos 服务和 9 个不同的 Stratum 函数。
（通过多个层的服务申请跟踪图）
工作流规定
或者咱们应该说是一些工作流规定？Plato 是一种粘合剂，它通过为服务开发人员提供一个定义畛域逻辑和编排无状态函数 / 服务的框架来将 Cosmos 中的所有内容分割在一起。Optimus API 层具备内置的工具，能够调用工作流并查看它们的状态。Stratum 的 Serverless 层生成强类型的 RPC 客户端，使调用 Serverless 函数变得简略且直观。
Plato 是一个前向链接规定引擎，它有助于咱们算法的异步性和计算密集性。与 Netflix 的 Conductor 这样的程序化工作流引擎不同，Plato 使创立“始终在线”（“always on”）的工作流变得更容易。例如，当咱们开发出更好的编码算法时，咱们基于规定的工作流会主动治理更新现有的视频，而无需触发和治理新的工作流。此外，任何工作流都能够调用另一个工作流，从而实现上述服务的分层。
Plato 是一个多租户零碎（应用 Apache Karaf 实现），能够极大地缩小操作工作流的操作累赘。用户在本人的源代码库中编写和测试他们的规定，而后通过将编译后的代码上传到 Plato 服务端来部署工作流。
开发人员通过用 Emirax（一种基于 Groovy 构建的特定畛域语言）编写的一组规定来指定他们的工作流，每条规定有 4 个局部：
匹配（match）：指定要触发此规定必须满足的条件。
动作（action）：指定触发该规定时要执行的代码；在这里，你能够调用 Stratum 函数来解决申请。
响应（reaction）：指定当动作代码胜利实现时要执行的代码。
谬误（error）：指定遇到谬误时要执行的代码。
在这些局部中，你通常首先要记录工作流状态的变动，而后执行使工作流向前推移的步骤，例如，执行 Stratum 函数或返回执行后果。
提早敏感型应用程序
像 Sagan 这样的 Cosmos 服务对提早敏感，因为它们是面向用户的。例如，一位正在制作社交媒体帖子的艺术家，在剪辑最新一季的《纸钞屋》（Money Heist）的视频时不想等太久。对于 Stratum，提早是执行工作的工夫加上获取计算资源的工夫的函数。当工作十分忙碌时（通常是这样），“获取资源的工夫”就成为了重要因素。举个例子，假如你购物时通常会买卫生纸。失常状况下，把它放进购物车，通过收银台是没有问题的，整个过程须要你破费 30 分钟。
（资源稀缺）
而后有一天，一种蹩脚的病毒暴发了，并且每个人都决定要买更多的卫生纸。因为总需求超过了可用容量，你卫生纸的延迟时间当初从 30 分钟减少到了两周。Cosmos 应用程序（尤其是 Stratum 函数）在面对突发和不可预测的需要时也有同样的问题。Stratum 通过以下几种形式来治理函数的执行提早：
资源池（Resource pools）。最终用户能够为本人的业务用例保留 Stratum 计算资源，并且资源池是分层的，容许用户组共享资源。
容量预热（Warm capacity）。最终用户能够提前申请计算资源（例如容器），以缩小 Stratum 中的启动提早。
微批次（Micro-batches）。Stratum 还应用微批次解决，这是在 Apache Spark 等平台上学到的一种缩小启动提早的技巧。其思维是将启动老本摊派到许多函数调用中。如果你调用函数 10000 次，那么该函数可能在 10000 个容器上运行一次，也可能在 1000 个容器上运行 10 次。
优先级（Priority）。当须要在老本和低提早的需要之间进行均衡时，Cosmos 服务通常会落在两头的某个地位：有足够的资源来解决典型的突发事件，但没有足够的资源来解决提早最低的最大突发事件。通过对工作进行优先级排序，即便在资源短缺的状况下，应用程序仍能够确保以较低的提早解决最重要的工作。Cosmos 服务所有者能够容许最终用户设置优先级，或者在 API 层或工作流中本人设置优先级。
吞吐量敏感型应用程序
像 Tapas 这样的服务对吞吐量十分敏感，因为它们会耗费大量的计算资源（例如每天数百万个 CPU 小时），并且更关怀一段时间内（数小时或数天内）实现的工作，而不是实现单个工作的工夫。换句话说，服务等级指标（SLO）是以每天的工作和每项工作的老本来掂量的，而不是以每秒的工作来掂量的。
对于吞吐量敏感的工作负载，最重要的 SLO 是由 Stratum 的 Serverles 层提供的。构建在 Titus 容器平台之上的 Stratum 容许吞吐量敏感的工作负载通过灵便的资源调度应用“机会主义”计算资源。例如，如果一个 Serverles 函数调用违心期待一个小时再执行，那么它的老本可能会更低。
Strangler Fig
咱们晓得，挪动一个像 Reloaded 这样宏大而简单的遗留零碎将是一个逾越危险鸿沟的大跃进，这个鸿沟里到处都是失败的从新设计后的我的项目碎片，但毫无疑问，咱们必须跳下去。为了升高危险，咱们采纳了 Strangler Fig（绞杀榕）模式，让新零碎围绕旧零碎扩大，并最终齐全取代旧零碎。
依然在学习
咱们于 2018 年开始建造 Cosmos，并从 2019 年初开始投入生产。明天，咱们大概有 40 个 Cosmos 服务，并且预计还会增长更多。咱们仍处于中期阶段，但咱们能够分享一些咱们迄今为止所学到的重点常识：
- Netflix 的文化起到了要害的作用
家喻户晓，Netflix 的工程文化依赖于集体判断，而不是自上而下的管制。软件开发人员有承担风险和做出决策的自在和责任。咱们中没有人有软件架构师的头衔；咱们所有人都在扮演着这个角色。在这种背景下，Cosmos 从局部优化的不同尝试中怀才不遇。Optimus、Plato 和 Stratum 是独立构思的，并最终整合成一个繁多的平台愿景。团队中的应用程序开发人员让每个人都专一于用户敌对的 API 和开发人员的生产力。基础设施和媒体算法开发人员之间建设了强有力的单干关系，才将愿景变为事实。咱们不可能在自上而下的工程环境中做到这一点。 - 微服务 + 工作流 + Serverless
咱们发现，“触发编排 Serverless 函数工作流的微服务”的编程模型是一个弱小的范式。它实用于咱们的大多数用例，但有些应用程序非常简单，以至于由此而减少复杂性是不值得的。 - 平台心态
从大型分布式应用程序迁徙到“平台 + 应用程序”是一个重大的范式转变。每个人都必须扭转他们的心态。应用程序开发人员必须放弃肯定的灵活性，以换取一致性、可靠性等。平台开发人员必须造就更多的同理心，并优先思考客户服务、用户生产力和服务等级。有时候，应用程序开发人员会感到平台团队没有适当地专一于他们的需要，而有时候，平台团队却因用户需要而感到负担过重。咱们彼此坦诚相待，度过了这些难关。例如，在最近的一次回顾之后，咱们增强了横切零碎品质的开发跟踪，例如开发人员的教训、可靠性、可察看性和安全性。 - 平台获胜
咱们创立 Cosmos 的目标是让开发人员可能更好更快地工作，将更多的工夫花在解决业务问题上，而缩小解决基础设施的工夫。有时指标仿佛遥不可及，但咱们开始看到咱们所心愿的成绩。在 Cosmos 中，开发人员最喜爱的一些零碎个性是托管交付、模块化、可察看性和开发人员反对。咱们正在致力使这些品质变得更好，同时也在致力于薄弱环节，如本地开发、弹性和可测试性。
将来的布局
2021 年对 Cosmos 来说将是重要的一年，因为咱们会将大部分工作从 Reloaded 转移到 Cosmos 中，这将带来更多的开发人员和更高的负载。咱们打算改良编程模型以适应新的用例。咱们的指标是使 Cosmos 更易于应用，更具弹性，更快，更无效。请持续关注，以理解更多无关 Cosmos 是如何工作以及咱们是如何应用它的细节。
原文链接
本文为阿里云原创内容，未经容许不得转载。
