原文：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% 左右达到了硬扩展限制。此外，所有构建块的总体成本都太高，无法大规模接受解决方案。
下图显示了我们服务的无服务器体系结构。

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

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

结果和要点

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

热门相关：最强狂兵   横行霸道   最强装逼打脸系统   学霸女神超给力   惊世毒妃：轻狂大小姐