如何构建一套高性能、高可用性、低成本的视频处理系统？
朱小厮的博客
Posted on
点击上方“朱小厮的博客”，选择“设为星标”
当当满200减40优惠码「J2KNAE」
来源：阿里巴巴中间件
前言
近些年，在线教育行业飞速发展，为整个社会的知识传播提供了前所未有的便利性。通过多种形式的在线教育平台，学员与教师即使相隔万里也可以开展教学活动。借助丰富的网络课件，学员还可以随时随地的进行学习，真正打破了时间和空间的限制。在各种形式的网络课件中，视频课件自然是最直观表现力最丰富的形式，因此视频课件的市场占有率也在逐年提升。
视频处理需求分析
对于在线教育领域的视频课件出品方而言，每天都要对大量视频内容进行处理，下图展示了一个比较典型的场景：
对于技术团队而言，采用这样的方案不用预先准备任何计算资源，甚至不用编写任何代码，就能够从无到有拥有一整套视频处理系统，完全不用考虑资源规划的问题。这样的方案非常适合在业务发展初级需要让系统快速上线的场景。
但随着业务的不断发展，开箱即用的 SaaS 化方案还是存在不少的局限性，基于如下的原因，大多数的技术团队还是会选择自己建设视频处理系统：
1、对于之前已经通过 FFmpeg 技术实现的视频处理服务，因为涉及到复杂的业务逻辑，很难直接迁移到 SaaS 化方案上来。
2、高阶的视频处理需求必须使用代码来实现：比如音频降噪、插入动态 Gif 水印、按固定频率截帧等等。
3、使用高分辨率的大视频是行业趋势，对于超大视频的处理，比如 10G 以上的 1080P 视频，往往需要通过自定义的手段进行计算优化，才能保证处理的及时性。
4、在很多种场景下，自建视频处理系统都会带来明显的成本优势。
5、频繁的业务需求变更需要对整套系统进行更精细粒度的迭代管理，比如采用金丝雀策略降低新版本发布所带来的风险。
那么如何建设一套同时具备高性能、高可用性、高灵活性、低成本特点的视频处理系统呢？
基于分布式集群
最典型的方案是申请一组云虚拟机，在每台虚拟机上部署视频处理应用，组建成一个可以水平伸缩的服务集服。当有新的上频上传的时候，可以触发一个处理任务，并通过负载均衡或消息队列对任务进行分发，接到任务的应用节点负责完成对应的任务。
通过这个架构，在业务高峰期，用户上传视频行为比较密集，可以增加服务集群的实例数量，来提升处理能力。在业务低峰期，可以减少服务集群的实例数量，来减少资源成本。
此方案可以通过定制化的代码逻辑实现各种高阶的视频处理需求，灵活度非常高，配合可以水平伸缩的计算集群以及负载均衡机制，能同时满足性能和成本方面的需求，是一套被广泛采纳的方案。但在生产环境大规模运行的情况下，这套方案还是会暴露出很多问题：
维护工作量大。整套系统的维护工作量涵盖了虚拟机、网络、负载均衡组件、操作系统、应用等多个层面，需要投入大量的时间和精力来保障系统的高可用性与稳定性。举一个最简单的例子，当某个应用实例出现故障的时候，如何第一时间定位故障并尽可能迅速的将其从计算集群中摘除，摘除之后又如何保证之前没有完成的任务能够重新得到处理呢？这些都需要再配合完整的监控机制、故障隔离恢复机制来实现，甚至涉及到代码层的业务逻辑优化。
弹性伸缩能力滞后。有两种方式实现计算集群的弹性伸缩：通过定时任务触发，或者通过指标阈值（CPU利用率，内存使用率等）触发。不管采用哪种方式，都没有办法基于用户行为精细化管理，在遇到任务密度大幅度起伏的时候，会面临弹性伸缩能力滞后的问题。当来自用户的视频上传请求突增的时候，新增一个应用实例需要经过申请云资源>初始化>部署应用镜像>应用启动>加入负载均衡列表等多个阶段，即便通过 Kubernetes + 预留资源池等技术优化，也往往需要 10 分钟以上。
资源利用率低。滞后的弹性伸缩能力会导致伸缩策略制定的相对保守，造成计算资源的大量浪费，增加了使用成本，如下图所示：
有没有一种方案能能帮助技术团队专注于业务逻辑的实现，并可以根据用户的实际上传请求进行精细化的资源分配，实现资源利用最大化呢？随着云计算的飞速发展，各大云厂商都在积极探索新的方案，用更加“云原生”的方式来解决成本和效率的问题，阿里云提供的函数计算 + Serverless 工作流就是这个领域非常具有代表性的方案。
函数计算
阿里云函数计算是事件驱动的全托管计算服务。通过函数计算，开发者无需管理服务器等基础设施，只需编写代码并上传。函数计算会为自动准备好计算资源，以弹性、可靠的方式运行代码，并提供日志查询、性能监控、报警等功能，确保系统的稳定运行。
相比传统的应用服务器保持运行状态并对外提供服务的方式，函数计算最大的区别是按需拉起计算资源对任务进行处理，在任务完成以后自动的回收计算资源，这是一种真正符合 Serverless 理念的方案，能最大化的提升资源利用率，减少系统系统维护工作量和使用成本。因为不需要预先申请计算资源，使用者完全不需要考虑容量评估和弹性伸缩的问题，只需要根据资源的实际使用量来进行付费。
下图展示了函数计算的工作方式：
对于使用者而言，把实现关键业务逻辑的代码上传到函数计算平台，就能以事件驱动的方式触发函数执行。函数计算已经支持各种主流的编程语言，对于即有的代码，可以通过几个非常简单的步骤部署到函数计算。
每一次计算资源的分配，都基于事件的触发，一个事件往往对应着业务上的一个任务。函数计算支持多种多样的触发器，比如HTTP触发器的事件源就是 HTTP 请求，函数计算接收到一次 HTTP 请求后，会按照预设的规格，分配相应的计算资源来处理这个 HTTP 请求，请求处理完成之后，函数计算会根据用户的设置决定是否立即回收这一次拉起的计算资源。而 OSS 触发器，能够监控发生在对象存储 OSS 上的各种事件，当有用户上传新文件或者对文件进行修改的时候，自动触发函数执行，这种方式就刚好适合视频处理的业务场景。
在计算资源的调度上，函数计算进行了大量优化，面对用户请求的突增，可以在毫秒级拉起大量的计算资源来并行工作，确保用户体验。
通过函数计算进行视频处理
基于函数计算的特性，搭建一套视频处理系统就非常简单，只需要配置一个 OSS 触发器，并将视频处理的核心代码上传到函数计算，就大功告成：
通过这套方案，使用者不再需要考虑资源管理、负载均衡、系统高可用、弹性伸缩、系统监控等一系列复杂的问题，函数计算平台会按最优的方式根据用户的上传行为调度计算资源，低成本高效率的完成视频处理任务。
在这个 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 工具，更轻松进行开发、构建、部署操作.
像 Java 这样的语言，在虚拟机启动的时候需要加载比较多的类库，不能够像实现运算实例毫秒级启动并进入执行状态，不能直接使用在一些对于延迟特别敏感的业务场景。但配合函数计算提供的预留实例以及单实例多并发新功能，能够消除冷启动对业务的影响，并降低等待下游服务响应的影响，让函数计算上运行的 Java 语言也能实现 API 网关等对延时要求特别高业务场景。
Serverless 工作流
通过前面介绍的方案，可以轻松完成对短视频的各种定制化处理。但每一个函数计算实例，在资源规格上和总运行时长都不是无限的，目前函数计算实例可以拥有 3G 的内存资源和 10 分钟的执行时间，这也就说明，当一个视频处理任务需要占用 3G 以上的系统内存，或者总执行时长超过 10 分钟的情况下，处理任务是会失败的。
在 5G 时代，超大视频课件是非常普遍的需求，如何通过函数计算处理这样的大视频呢？这个时候就要出动另一个武器--- Serverless 工作流，来配合函数计算一起完成这个任务。
Serverless 工作流是一个用来协调多个分布式任务执行的全托管云服务。您可以用顺序、选择、并行等方式来编排分布式任务，Serverless 工作流会按照设定好的步骤可靠地协调任务执行，跟踪每个步骤的状态转换，并在必要时执行用户定义的重试逻辑，以确保工作流顺利完成。Serverless 工作流通过提供日志记录和审计来监视工作流的执行，方便您轻松地诊断和调试应用。
您可以使用 Serverless 工作流编排一系列的函数资源，同时定义流程中每一步的输入和输出，使用内置控制步骤编排复杂逻辑、发起并行执行、管理超时或终止流程。另外通过控制台能够使用图形界面显示出执行任务状态和执行顺序，同时控制台会显示每个步骤的实时状态，并提供每次执行的详细历史记录。通过 Serverless 工作流 + 函数计算的组合，我们可以突破时间和空间的限制，对任意大小的视频文件进行复杂的处理。
大视频处理
简单来讲，处理一个大视频的基本思路是：
1、将视频先进行切片处理，把每一个分片的大小控制在合理的大小，以便单个函数计算实例可以对其进行快速处理。
2、拉起多个函数计算实例对每一个分片进行并行处理。
3、对处理结果进行合并。
通过 Serverless 工作流 + 函数计算进行视频处理的流程如下：
通过 Serverless 工作流提供的可视界面，我们能在工作流执行的过程当中，方便的查看到每一个步骤运行的信息，并配合自定义的 Dashboard 实现对整套视频处理系统的全面监控：
方案对比
自建分布式集群 | 直播使用SaaS化云服务 | 函数计算+Serverless工作流 | |
基础设施 | 使用者自行管理 | 无 | 无 |
开发效率 | 低：除了实现业务逻辑之外，还需要投入精力解决系统安装、配置管理、安全更新、异常重试等方面的问题 | 高：开箱即用 | 高：专注业务逻辑实现, 配合Funcraft工具实现 一键资源编排和部署 |
运维成本 | 极高：需要搭建多套环境，并自行解决负载均衡、系统高可用、弹性伸缩等方面的问题。 | 低 | 低 |
灵活度 | 高 | 低：无法实现高阶自定义处理逻辑 | 高 |
弹性伸缩 | 滞后：基于定时计算和指标阈值的弹性机制。 | 不用考虑 | 迅速：按需调试计算实例，毫秒级启动。 |
学习成本 | 高：除了要了解FFmpeg之外 ，还必须对Kubernetes等容器编排技术有深入了解。 | 低：仅需了解对应的API | 低：仅需了解一种编程语言以及FFmpeg |
新项目上线周期 | 30天以上：容量评估、资源采购、环境搭建、开发、测试、监控体系集成、报警体系集成、配置管理、灰度体系集成。 | 1周以内 | 1周以内：仅需开发核心逻辑的代码，并完成测试与部署。 |
使用成本 | 高：资源利用率比较低，CPU利用率很难超过20%。 | 高：云视频处理费用在大规模使用的场景下偏高。 | 低：资源利用率高，CPU利用率可大于80%。 |
与云产品集成能力 | 较低：需要研究各项产品的API，自行集成。 | 低：集成困难。 | 高：非常方便的与NAS、服务消息、日志服务、CDN等云服务集成，实现更丰富的业务场景。 |
总结
基于函数计算和 Serverless 工作流的弹性高可用视频处理架构，充分体现了云原生时代 Serverless 化思想，以事件驱动的形式触发函数执行，真实计算资源真正意义上的按需使用。对于使用而言，这套方案在保证业务灵活度的同时，可以显著降低维护成本与资源成本，并大幅度的缩短项目交付时间。
在线教育领域对于视频处理的需求量非常大，而且对于处理速度、并发吞吐量、资源利用率等方面都有极高的要求，函数计算 + Serverless 工作流方案组合帮助用户轻松建设弹性高可用的视频处理架构，是实现这些复杂需求的最优解。随着云原生的不断发展， Serverless 相关技术还将深入更多的业务场景，有未来有无限可能！
当当1024图书优惠活动，“实付满200再减40”的优惠码「J2KNAE」，囤书薅羊毛再走一波~~（使用时间：10月20日~11月3日，使用渠道：当当小程序或当当APP）
原创|OpenAPI标准规范
如此简单| ES最全详细使用教程
ClickHouse到底是什么？为什么如此牛逼！
原来ElasticSearch还可以这么理解
面试官：InnoDB中一棵B+树可以存放多少行数据？