如何构建一套高性能、高可用性、低成本的视频处理系统?

本文涉及的产品
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
简介: 基于函数计算和 Serverless 工作流的弹性高可用视频处理架构,充分体现了云原生时代 Serverless 化思想,以事件驱动的形式触发函数执行,真实计算资源真正意义上的按需使用。对于使用而言,这套方案在保证业务灵活度的同时,可以显著降低维护成本与资源成本,并大幅度的缩短项目交付时间。

前言

近些年,在线教育行业飞速发展,为整个社会的知识传播提供了前所未有的便利性。通过多种形式的在线教育平台,学员与教师即使相隔万里也可以开展教学活动。借助丰富的网络课件,学员还可以随时随地的进行学习,真正打破了时间和空间的限制。在各种形式的网络课件中,视频课件自然是最直观表现力最丰富的形式,因此视频课件的市场占有率也在逐年提升。

视频处理需求分析

对于在线教育领域的视频课件出品方而言,每天都要对大量视频内容进行处理,下图展示了一个比较典型的场景:

image.png
1、用户上传一个视频到平台后,会先在对象存储中对视频源文件进行暂存。
2、平台对视频进行预处理,并打上水印。
3、平台将视频文件转换为其他格式,并对分辨率进行调整,以适配各种不同的终端设备的要求。
4、将处理好的视频文件保存回对象存储,并同步到 CDN 进行加速。

虽然从流程上来讲,这个场景比较简单,但在技术上的挑战其实是非常大的。视频课件的原作者来自于在线教育平台的广大用户,可能是平台负责内容输出的内部用户,也有可能是签约的教师,或者是平台认证过的分享型用户。用户上传视频的操作并没有固定的频率,往往集中在几个时间段,存在明显的波峰波谷。在业务高峰期,视频处理的需求量非常大,有的在线教育企业每天要完成数万个视频的转码工作。对于负责建设视频处理系统的技术团队而言,这样的业务场景就留给了他们一系列的挑战:

1、如何确保这套系统在业务高峰期的高可用性?
2、如何让每一个上传的视频尽可能快的处理完?
3、如何尽可能的降低资源成本?
4、如何高效率的应对需求的频繁变更?

基于这几个诉求,我们结合云计算的特点,来分析一下可行的解决方案。

使用 SaaS 化的云服务完成视频处理

随着各大云计算厂商产品线的不断丰富,我们可以很轻松的寻找到开箱即用的方案来解决这类典型的视频处理需求。以阿里云为例,视频点播类产品提供了视频采集、编辑、上传、媒体资源管理、转码处理、视频审核分析、分发加速于一体的一站式解决方案。

image.png
对于技术团队而言,采用这样的方案不用预先准备任何计算资源,甚至不用编写任何代码,就能够从无到有拥有一整套视频处理系统,完全不用考虑资源规划的问题。这样的方案非常适合在业务发展初级需要让系统快速上线的场景。

但随着业务的不断发展,开箱即用的 SaaS 化方案还是存在不少的局限性,基于如下的原因,大多数的技术团队还是会选择自己建设视频处理系统:

1、对于之前已经通过 FFmpeg 技术实现的视频处理服务,因为涉及到复杂的业务逻辑,很难直接迁移到 SaaS 化方案上来。

2、高阶的视频处理需求必须使用代码来实现:比如音频降噪、插入动态 Gif 水印、按固定频率截帧等等。

3、使用高分辨率的大视频是行业趋势,对于超大视频的处理,比如 10G 以上的 1080P 视频,往往需要通过自定义的手段进行计算优化,才能保证处理的及时性。

4、在很多种场景下,自建视频处理系统都会带来明显的成本优势。

5、频繁的业务需求变更需要对整套系统进行更精细粒度的迭代管理,比如采用金丝雀策略降低新版本发布所带来的风险。

那么如何建设一套同时具备高性能、高可用性、高灵活性、低成本特点的视频处理系统呢?

基于分布式集群

最典型的方案是申请一组云虚拟机,在每台虚拟机上部署视频处理应用,组建成一个可以水平伸缩的服务集服。当有新的上频上传的时候,可以触发一个处理任务,并通过负载均衡或消息队列对任务进行分发,接到任务的应用节点负责完成对应的任务。

image.png
通过这个架构,在业务高峰期,用户上传视频行为比较密集,可以增加服务集群的实例数量,来提升处理能力。在业务低峰期,可以减少服务集群的实例数量,来减少资源成本。

此方案可以通过定制化的代码逻辑实现各种高阶的视频处理需求,灵活度非常高,配合可以水平伸缩的计算集群以及负载均衡机制,能同时满足性能和成本方面的需求,是一套被广泛采纳的方案。但在生产环境大规模运行的情况下,这套方案还是会暴露出很多问题:

维护工作量大。整套系统的维护工作量涵盖了虚拟机、网络、负载均衡组件、操作系统、应用等多个层面,需要投入大量的时间和精力来保障系统的高可用性与稳定性。举一个最简单的例子,当某个应用实例出现故障的时候,如何第一时间定位故障并尽可能迅速的将其从计算集群中摘除,摘除之后又如何保证之前没有完成的任务能够重新得到处理呢?这些都需要再配合完整的监控机制、故障隔离恢复机制来实现,甚至涉及到代码层的业务逻辑优化。

弹性伸缩能力滞后。有两种方式实现计算集群的弹性伸缩:通过定时任务触发,或者通过指标阈值(CPU利用率,内存使用率等)触发。不管采用哪种方式,都没有办法基于用户行为精细化管理,在遇到任务密度大幅度起伏的时候,会面临弹性伸缩能力滞后的问题。当来自用户的视频上传请求突增的时候,新增一个应用实例需要经过申请云资源>初始化>部署应用镜像>应用启动>加入负载均衡列表等多个阶段,即便通过 Kubernetes + 预留资源池等技术优化,也往往需要 10 分钟以上。

资源利用率低。滞后的弹性伸缩能力会导致伸缩策略制定的相对保守,造成计算资源的大量浪费,增加了使用成本,如下图所示:
image.png
有没有一种方案能能帮助技术团队专注于业务逻辑的实现,并可以根据用户的实际上传请求进行精细化的资源分配,实现资源利用最大化呢?随着云计算的飞速发展,各大云厂商都在积极探索新的方案,用更加“云原生”的方式来解决成本和效率的问题,阿里云提供的函数计算 + Serverless 工作流就是这个领域非常具有代表性的方案。

函数计算

阿里云函数计算是事件驱动的全托管计算服务。通过函数计算,开发者无需管理服务器等基础设施,只需编写代码并上传。函数计算会为自动准备好计算资源,以弹性、可靠的方式运行代码,并提供日志查询、性能监控、报警等功能,确保系统的稳定运行。

相比传统的应用服务器保持运行状态并对外提供服务的方式,函数计算最大的区别是按需拉起计算资源对任务进行处理,在任务完成以后自动的回收计算资源,这是一种真正符合 Serverless 理念的方案,能最大化的提升资源利用率,减少系统系统维护工作量和使用成本。因为不需要预先申请计算资源,使用者完全不需要考虑容量评估和弹性伸缩的问题,只需要根据资源的实际使用量来进行付费。

下图展示了函数计算的工作方式:
image.png
对于使用者而言,把实现关键业务逻辑的代码上传到函数计算平台,就能以事件驱动的方式触发函数执行。函数计算已经支持各种主流的编程语言,对于即有的代码,可以通过几个非常简单的步骤部署到函数计算。函数支持的所有开发语言请参考开发语言列表:

https://help.aliyun.com/document_detail/74712.html

每一次计算资源的分配,都基于事件的触发,一个事件往往对应着业务上的一个任务。函数计算支持多种多样的触发器,比如HTTP触发器的事件源就是 HTTP 请求,函数计算接收到一次 HTTP 请求后,会按照预设的规格,分配相应的计算资源来处理这个 HTTP 请求,请求处理完成之后,函数计算会根据用户的设置决定是否立即回收这一次拉起的计算资源。而 OSS 触发器,能够监控发生在对象存储 OSS 上的各种事件,当有用户上传新文件或者对文件进行修改的时候,自动触发函数执行,这种方式就刚好适合视频处理的业务场景。更多支持的函数触发器请参考触发器列表:

https://help.aliyun.com/document_detail/74707.html

在计算资源的调度上,函数计算进行了大量优化,面对用户请求的突增,可以在毫秒级拉起大量的计算资源来并行工作,确保用户体验。

通过函数计算进行视频处理

基于函数计算的特性,搭建一套视频处理系统就非常简单,只需要配置一个 OSS 触发器,并将视频处理的核心代码上传到函数计算,就大功告成:
image.png
通过这套方案,使用者不再需要考虑资源管理、负载均衡、系统高可用、弹性伸缩、系统监控等一系列复杂的问题,函数计算平台会按最优的方式根据用户的上传行为调度计算资源,低成本高效率的完成视频处理任务。具体的操作步骤和代码实现可以参考视频处理 Python 实现 Demo :

https://github.com/awesome-fc/simple-video-processing

在这个 Demo 中,演示了如何基于函数计算将用户上传的视频统一转为 640 * 480 分辨率的 mp4 格式视频。

代码开发

每一个创建好的函数都会对应一个指定的入口,函数计算会从这个函数入口开始执行,类似于本地开发中的 Main() 函数。以 Python 语言为列,一个简单的入口函数如下:

def handler(event, context):
return 'hello world'

当有事件触发的时候,就会从入口函数开始执行,其中 event 参数携带了事件源相关的信息,比如在视频处理场景中,event 参数携带了上传到 OSS 的 Bucket 以及文件名等信息。而 context 参数携带了函数的运行信息,包括函数名、超时时间、访问凭证等。通过这些信息,就能让执行代码完成预定义的各种操作。

函数计算支持各种主流的编程语言,在这个编程语言当中, Node.js 和 Python 等脚本型语言含了丰富的类库,开发效率很高,而且运算实例启动的速度很快,能够支持对延迟特别敏感的任务,是函数计算最匹配的语言。Java 和 Go 等语言不能像脚本型语言一样直接上传代码就能创建一个函数,需要预先进行编译,使用起来会稍微复杂一些,但配合函数计算提供的 Funcraft 等工具,也可以大幅度提升开发和部署的效率。不管使用哪种开发语言,都建议使用者下载官方提供的 Funcraft 工具,更轻松进行开发、构建、部署操作,请参考 Funcraft :

https://help.aliyun.com/document_detail/140283.html

像 Java 这样的语言,在虚拟机启动的时候需要加载比较多的类库,不能够像实现运算实例毫秒级启动并进入执行状态,不能直接使用在一些对于延迟特别敏感的业务场景。但配合函数计算提供的预留实例以及单实例多并发新功能,能够消除冷启动对业务的影响,并降低等待下游服务响应的影响,让函数计算上运行的 Java 语言也能实现 API 网关等对延时要求特别高业务场景。请参考预留实例:

https://help.aliyun.com/document_detail/138103.html

和单实例多并发:

https://help.aliyun.com/document_detail/144586.html

Serverless 工作流

通过前面介绍的方案,可以轻松完成对短视频的各种定制化处理。但每一个函数计算实例,在资源规格上和总运行时长都不是无限的,目前函数计算实例可以拥有 3G 的内存资源和 10 分钟的执行时间,这也就说明,当一个视频处理任务需要占用 3G 以上的系统内存,或者总执行时长超过 10 分钟的情况下,处理任务是会失败的。

在 5G 时代,超大视频课件是非常普遍的需求,如何通过函数计算处理这样的大视频呢?这个时候就要出动另一个武器--- Serverless 工作流,来配合函数计算一起完成这个任务。

Serverless 工作流是一个用来协调多个分布式任务执行的全托管云服务。您可以用顺序、选择、并行等方式来编排分布式任务,Serverless 工作流会按照设定好的步骤可靠地协调任务执行,跟踪每个步骤的状态转换,并在必要时执行用户定义的重试逻辑,以确保工作流顺利完成。Serverless 工作流通过提供日志记录和审计来监视工作流的执行,方便您轻松地诊断和调试应用。

image.png
image.png

您可以使用 Serverless 工作流编排一系列的函数资源,同时定义流程中每一步的输入和输出,使用内置控制步骤编排复杂逻辑、发起并行执行、管理超时或终止流程。另外通过控制台能够使用图形界面显示出执行任务状态和执行顺序,同时控制台会显示每个步骤的实时状态,并提供每次执行的详细历史记录。通过 Serverless 工作流 + 函数计算的组合,我们可以突破时间和空间的限制,对任意大小的视频文件进行复杂的处理。

大视频处理

简单来讲,处理一个大视频的基本思路是:

1、将视频先进行切片处理,把每一个分片的大小控制在合理的大小,以便单个函数计算实例可以对其进行快速处理。

2、拉起多个函数计算实例对每一个分片进行并行处理。

3、对处理结果进行合并。

通过 Serverless 工作流 + 函数计算进行视频处理的流程如下:

image.png
通过 Serverless 工作流提供的可视界面,我们能在工作流执行的过程当中,方便的查看到每一个步骤运行的信息,并配合自定义的 Dashboard 实现对整套视频处理系统的全面监控:

image.png

方案对比

image.png

总结

基于函数计算和 Serverless 工作流的弹性高可用视频处理架构,充分体现了云原生时代 Serverless 化思想,以事件驱动的形式触发函数执行,真实计算资源真正意义上的按需使用。对于使用而言,这套方案在保证业务灵活度的同时,可以显著降低维护成本与资源成本,并大幅度的缩短项目交付时间。

在线教育领域对于视频处理的需求量非常大,而且对于处理速度、并发吞吐量、资源利用率等方面都有极高的要求,函数计算 + Serverless 工作流方案组合帮助用户轻松建设弹性高可用的视频处理架构,是实现这些复杂需求的最优解。随着云原生的不断发展, Serverless 相关技术还将深入更多的业务场景,有未来有无限可能!

【更多精彩】

1.中间件爆款一折起,还有阿里巴巴十年最佳实践深度解密,点击马上了解https://www.aliyun.com/activity/daily/commercial?spm=5176.20960838.0.0.6a54305etoEn4D

2.【填问卷领淘公仔】点击马上填写问卷:
https://survey.aliyun.com/apps/zhiliao/YmW95Gk8bU

【加入行业实战交流钉钉群】

阿里云专门成立了“互联网架构升级实战课”钉钉群,每周邀请一位阿里云专家在群内进行行业最佳实践直播,每天分享行业前沿干货,钉钉扫码马上加入。
image.png

相关文章
|
11月前
|
存储 监控 安全
使用阿里云构建弹性可扩展的服务器less架构
在现代的软件开发中,构建弹性可扩展的架构是至关重要的。而阿里云提供了一种强大的方式来实现这一目标,那就是服务器less架构。服务器less架构使开发人员能够专注于编写代码,而不必关注底层的服务器管理和扩展性。在本文中,我们将探讨如何使用阿里云构建弹性可扩展的服务器less架构。
256 0
|
12月前
|
存储 缓存 NoSQL
【可扩展性】谷歌可扩展和弹性应用的模式(下)
【可扩展性】谷歌可扩展和弹性应用的模式
|
12月前
|
存储 监控 负载均衡
【可扩展性】谷歌可扩展和弹性应用的模式(上)
【可扩展性】谷歌可扩展和弹性应用的模式
|
存储 运维 监控
性能透明提升 50%!SMC + ERDMA 云上超大规模高性能网络协议栈
新的协议栈是不是重新发明轮子?一个协议栈能否解决所有问题?适配所有场景?
性能透明提升 50%!SMC + ERDMA 云上超大规模高性能网络协议栈
|
存储 容灾 安全
如何利用工具低成本构建阿里云灾备方案?
如何利用工具低成本构建阿里云灾备方案?
如何利用工具低成本构建阿里云灾备方案?
|
算法 NoSQL 数据库
如何设计一款“高可用高性能”的发号器?
在分布式场景中,很多地方需要生成全局唯一的id,如数据库分库分表后需要用唯一id代替单机版本的自增id。发号器的基本要求是 全局唯一,无论如何都不能重复 某些场景下还要求单调递增,如排序需求等。
344 0
如何设计一款“高可用高性能”的发号器?
|
JavaScript Cloud Native Java
x86架构应用如何向Arm架构低成本迁移
曾几何时,无论是在服务器还是个人电脑,CPU芯片领域一直是 Intel 独占鳌头,旗下的 X86_64 架构被广泛采用。然而王权没有永恒,近年来 Arm64 架构异军突起,服务器端有华为鲲鹏920高性能芯片做代表,个人电脑端则以苹果M1芯片惊艳世人。Arm64 架构芯片用低功耗和高性能炫耀着其市场价值,国产化替代的洪流也在不断将 Arm64 推向军队、政府、国企的供应商们。抓住先机,迅速拥抱与适配国产化芯片,是这个时代软件交付的新话题。
x86架构应用如何向Arm架构低成本迁移
|
弹性计算 编解码 负载均衡
构建在线教育弹性高可用视频处理架构实战
对于负责建设视频处理系统的技术团队而言,这样的业务场景就留给了他们一系列的挑战。
1738 0
构建在线教育弹性高可用视频处理架构实战
|
机器学习/深度学习 存储 安全
【盘点篇】从安全、稳定、高可用、高性能、智能等维度看阿里云存储 2018
2008年,为了探索阿里巴巴集团大规模存储解决之道,阿里云存储自研飞天大规模的分布式存储引擎(盘古 1.0 ),从写下第一行代码开始,阿里云存储的进化之路正式开启。
8771 0