怎么做淘宝客手机网站,wordpress 单页模版,软文营销网,个人网站做seo简介#xff1a; 2021 年#xff0c;Netflix 会将大部分的工作负载从 Reloaded 转移到 Cosmos 平台。Cosmos 是一个计算平台#xff0c;它将微服务的最佳特性与异步工作流以及 Serverless 结合在一起。 作者 | Frank San Miguel 策划 | 田晓旭
2021 年#xff0c;Netflix …简介 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 服务并且预计还会增长更多。我们仍处于中期阶段但我们可以分享一些我们迄今为止所学到的重点知识
1. Netflix 的文化起到了关键的作用
众所周知Netflix 的工程文化依赖于个人判断而不是自上而下的控制。软件开发人员有承担风险和做出决策的自由和责任。我们中没有人有软件架构师的头衔我们所有人都在扮演着这个角色。在这种背景下Cosmos 从局部优化的不同尝试中脱颖而出。Optimus、Plato 和 Stratum 是独立构思的并最终整合成一个单一的平台愿景。团队中的应用程序开发人员让每个人都专注于用户友好的 API 和开发人员的生产力。基础设施和媒体算法开发人员之间建立了强有力的合作关系才将愿景变为现实。我们不可能在自上而下的工程环境中做到这一点。
2. 微服务 工作流 Serverless
我们发现“触发编排 Serverless 函数工作流的微服务”的编程模型是一个强大的范式。它适用于我们的大多数用例但有些应用程序非常简单以至于由此而增加复杂性是不值得的。
3. 平台心态
从大型分布式应用程序迁移到“平台 应用程序”是一个重大的范式转变。每个人都必须改变他们的心态。应用程序开发人员必须放弃一定的灵活性以换取一致性、可靠性等。平台开发人员必须培养更多的同理心并优先考虑客户服务、用户生产力和服务等级。有时候应用程序开发人员会感到平台团队没有适当地专注于他们的需求而有时候平台团队却因用户需求而感到负担过重。我们彼此坦诚相待度过了这些难关。例如在最近的一次回顾之后我们加强了横切系统质量的开发跟踪例如开发人员的经验、可靠性、可观察性和安全性。
4. 平台获胜
我们创建 Cosmos 的目的是让开发人员能够更好更快地工作将更多的时间花在解决业务问题上而减少处理基础设施的时间。有时目标似乎遥不可及但我们开始看到我们所希望的成果。在 Cosmos 中开发人员最喜欢的一些系统特性是托管交付、模块化、可观察性和开发人员支持。我们正在努力使这些品质变得更好同时也在致力于薄弱环节如本地开发、弹性和可测试性。
未来的规划
2021 年对 Cosmos 来说将是重要的一年因为我们会将大部分工作从 Reloaded 转移到 Cosmos 中这将带来更多的开发人员和更高的负载。我们计划改进编程模型以适应新的用例。我们的目标是使 Cosmos 更易于使用更具弹性更快更有效。请继续关注以了解更多有关 Cosmos 是如何工作以及我们是如何使用它的细节。
原文链接
本文为阿里云原创内容未经允许不得转载。
