译:从分布式微服务到单体

这篇具有很好参考价值的文章主要介绍了译:从分布式微服务到单体。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

原文: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能够监控客户观看的所有流,而不仅仅是观看人数最多的流。这种方法可以带来更高的质量和更好的客户体验。文章来源地址https://www.toymoban.com/news/detail-438917.html

到了这里,关于译:从分布式微服务到单体的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • sentinel介绍-分布式微服务流量控制

    https://sentinelguard.io/ 随着微服务的流行,服务和服务之间的稳定性变得越来越重要。Sentinel 是面向分布式、多语言异构化服务架构的流量治理组件,主要以流量为切入点,从流量路由、流量控制、流量整形、熔断降级、系统自适应过载保护、热点流量防护等多个维度来帮助开

    2024年02月16日
    浏览(31)
  • golang 分布式微服务DAO层构建

    构建云原生项目的dao层 配置读写分离的mysql集群 搭建一主二从的mysql集群、单机redis db.yml 其中viper init方法的逻辑如下: 例如现在要获取mysql “一主二从” 的主机dsn: 将一主二从都连接上 dbresolver 的作用是将数据库的读写操作分发到不同的数据库实例上。在配置中,Sources

    2024年02月12日
    浏览(31)
  • 推荐一个.Net分布式微服务开发框架

    在给大家介绍之前,我们一起来看看分布式架构的使用场景与好处。 针对一些互联网系统,大数据、高并发和快速响应,都是系统必须满足的 ,而单机系统的架构是无法满足这样的需求的,这时候我们就需要用到分布式的架构。 分布式架构具备以下的好处: 高性能 :把高

    2024年02月10日
    浏览(32)
  • Java分布式微服务4——异步服务通讯(RabbitMQ)中间件

    为什么需要异步调用? 故障隔离 :支付服务不负责调用其他三个服务,只负责通知Broker支付成功这个事件,然后就返回结果,后面的服务故障了和前面发布事件的服务无关,前面的服务发布完事件就结束了 吞吐量提升 :Broker将支付成功的事件广播给订阅了这个事件的那些服

    2024年02月13日
    浏览(34)
  • Java分布式微服务1——注册中心(Eureka/Nacos)

    远程调用 向其他服务器请求信息(远程调用) 先在application或者configuration中注册一个Bean方便之后使用(可忽略) 使用restTemplate方法发送请求 getForObject/postForObject/… 1、Eureka注册中心 上面的url是硬编码写死的,很不方便切换,所以使用Eurake注册中心来管理服务提供者的地址 E

    2024年02月14日
    浏览(29)
  • 整合spring cloud云服务架构 - 企业分布式微服务云架构构建

        1. 介绍 Commonservice-system是一个大型分布式、微服务、面向企业的JavaEE体系快速研发平台,基于模块化、服务化、原子化、热插拔的设计思想,使用成熟领先的无商业限制的主流开源技术构建。采用服务化的组件开发模式,可实现复杂的业务功能。提供驱动式开发模式,

    2024年02月16日
    浏览(29)
  • 分布式微服务技术栈-SpringCloud<Eureka,Ribbon,nacos>

    分布式架构的一种 把服务进行 拆分 springcloud 解决了 服务拆分过程中的 治理问题 与单体应用 进行区分 (单体架构 把业务所有功能集中开发,打成一个包部署) 每个模块独立开发和部署(服务集群) 服务之间互相调用 出现分布式技术 Webservice ESB Hession Dubbo 异步通信 消息队

    2024年02月07日
    浏览(38)
  • java 分布式微服务配置统一的日志输出包括logstash

    在springcloud分布式微服务中,每个微服务都要配置一个日志输出文件,当微服务多起来的时候,日志输出有变动就要一个一个微服务去修改,这样使工作量增加,变得很麻烦,还有可能出现错误。 对日志文件进行统一的配置处理是个不错的选择。 首先在微服务中有一个基础的

    2024年02月12日
    浏览(37)
  • Java单体到分布式进阶,分布式到高可用进阶,单体到微服务进

    鹅厂实习第十周 研二下了论文没有实习没有怎么办 数据分析求职Happy Ending 献上我的面经和回答思路 求求大家投下我们鹅厂吧 五年职场人,今做面试官,我来揭秘大学生校招内幕! 五年职场人,今做面试官,我来揭秘大学生校招内幕! 京东Java实习一面 机械转码前端上岸,

    2024年03月08日
    浏览(41)
  • 单体到分布式到微服务

    业务驱动着技术发展是亘古不变的道理。最开始的时候,业务量少、复杂度低,采取的技术也相对简单,能够基本满足用户对功能的需求。随着 IT 信息化的普及,更多交易被放到了网络上,增加的信息量和频繁的业务访问就变成了需要解决的问题。因此,逐渐产生了缓存、集

    2024年04月12日
    浏览(27)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包