原文：https://www.primevideotech.com/video-streaming/scaling-up-the-prime-video-audio-video-monitoring-service-and-reducing-costs-by-90

从分布式微服务架构迁移到整体式应用程序有助于实现更高的规模、弹性并降低成本。

在Prime Video，我们为客户提供数千个直播流。为了确保客户无缝接收内容，Prime Video设置了一个工具来监控客户观看的每个流。该工具使我们能够自动识别感知质量问题（例如，块损坏或音频/视频同步问题）并触发修复过程。
我们在Prime Video的视频质量分析（VQA）团队已经拥有了一个用于音频/视频质量检查的工具，但我们从未打算也没有设计过它大规模运行（我们的目标是监控数千个并发流并随着时间的推移而增加这个数字）。在将更多流载入服务时，我们注意到大规模运行基础结构非常昂贵。我们还注意到扩展瓶颈，使我们无法监控数千个流。因此，我们退后一步，重新审视了现有服务的体系结构，重点关注成本和扩展瓶颈。
我们服务的初始版本由由 AWS Step Functions 编排的分布式组件组成。就成本而言，两个最昂贵的操作是业务流程工作流和数据在分布式组件之间传递的时间。为了解决这个问题，我们将所有组件移动到单个进程中，以将数据传输保留在进程内存中，这也简化了编排逻辑。由于我们将所有操作编译到单个进程中，因此我们可以依靠可扩展的 Amazon Elastic Compute Cloud （Amazon EC2） 和 Amazon Elastic Container Service （Amazon ECS） 实例进行部署。

分布式系统开销

我们的服务由三个主要部分组成。

  • 媒体转换器将输入音频/视频流转换为发送到检测器的帧或解密的音频缓冲区。
  • 缺陷检测器执行实时分析帧和音频缓冲区的算法，以查找缺陷（例如视频冻结、块损坏或音频/视频同步问题），并在发现缺陷时发送实时通知。有关此主题的更多信息，请参阅我们的 Prime Video 如何使用机器学习来确保视频质量一文。
  • 第三个组件提供控制服务中流的业务流程。

我们将最初的解决方案设计为使用无服务器组件（例如 AWS Step Functions 或 AWS Lambda）的分布式系统，这是快速构建服务的不错选择。从理论上讲，这将允许我们独立扩展每个服务组件。但是，我们使用某些组件的方式导致我们在预期负载的 5% 左右达到了硬扩展限制。此外，所有构建块的总体成本都太高，无法大规模接受解决方案。
下图显示了我们服务的无服务器体系结构。

架构中的主要扩展瓶颈是使用 AWS Step Functions 实施的编排管理。我们的服务对流的每一秒执行了多次状态转换，因此我们很快就达到了帐户限制。除此之外，AWS Step Functions 还按状态转换向用户收费。
我们发现的第二个成本问题是关于我们在不同组件之间传递视频帧（图像）的方式。为了减少计算成本高昂的视频转换作业，我们构建了一个微服务，将视频拆分为帧，并将图像临时上传到 Amazon Simple Storage Service （Amazon S3） 存储桶。然后，缺陷检测器（其中每个缺陷检测器也作为单独的微服务运行）下载图像并使用 AWS Lambda 同时处理它。但是，对 S3 存储桶的大量 Tier-1 调用成本很高。

从分布式微服务到单体应用程序

为了解决瓶颈问题，我们最初考虑单独修复问题，以降低成本并提高扩展能力。我们进行了试验并做出了一个大胆的决定：我们决定重新构建我们的基础设施。
我们意识到分布式方法在我们的特定用例中并没有带来很多好处，因此我们将所有组件打包到一个流程中。这消除了对 S3 存储桶作为视频帧中间存储的需求，因为我们的数据传输现在发生在内存中。我们还实现了控制单个实例中的组件的编排。
下图显示了迁移到整体架构后的系统体系结构。

从概念上讲，高级体系结构保持不变。我们仍然拥有与初始设计（媒体转换、检测器或编排）完全相同的组件。这使我们能够重用大量代码并快速迁移到新架构。
在初始设计中，我们可以水平扩展多个检测器，因为它们中的每一个都作为单独的微服务运行（因此添加新检测器需要创建一个新的微服务并将其插入业务流程）。然而，在我们的新方法中，探测器的数量只能垂直缩放，因为它们都在同一实例中运行。我们的团队会定期向服务中添加更多检测器，我们已经超出了单个实例的容量。为了克服这个问题，我们多次克隆服务，用不同的检测器子集对每个副本进行参数化。我们还实现了一个轻量级编排层来分发客户请求。
下图显示了我们在超出单个实例容量时部署检测器的解决方案。

结果和要点

微服务和无服务器组件是可以大规模工作的工具，但是否在整体式架构上使用它们必须根据具体情况进行。
将我们的服务迁移到整体式架构可将我们的基础架构成本降低 90% 以上。它还提高了我们的扩展能力。今天，我们能够处理数千个流，我们仍然有能力进一步扩展服务。将解决方案迁移到 Amazon EC2 和 Amazon ECS 还使我们能够使用 Amazon EC2 计算节省计划，这将有助于进一步降低成本。
我们做出的一些决定并不明显，但它们带来了重大改进。例如，我们复制了一个计算成本高昂的媒体转换过程，并将其放置在更靠近检测器的位置。虽然运行一次媒体转换并缓存其结果可能被认为是更便宜的选择，但我们发现这不是一种经济高效的方法。
我们所做的更改使Prime Video能够监控客户观看的所有流，而不仅仅是观看人数最多的流。这种方法可以带来更高的质量和更好的客户体验。

本文来自博客园，作者：IAyue，转载请注明原文链接：https://www.cnblogs.com/zmj-pr/p/17391507.html