转码服务serverless探索

背景

公司目前主要聚焦于视频这个领域,利用视频为媒体、文旅、会议等行业进行赋能。
既然聚焦于视频领域,那么视频转码则是绕不开的话题。
为了降低成本,以及保证产品的核心能力,公司自建了一套转码系统。

转码服务除了尽可能多的兼容业界的视频格式外,转码的速度是另一个非常重要的指标。
因为视频转码对用户来说,感知最强的就是视频转码速度。
假如用户上传了一个1分钟的视频,转码花了10分钟甚至更久的话,用户肯定就不愿意使用我们的产品了。
对于用户来说等待的时间越短越好,对于转码服务来说转码速度越快越好。

我们先从转码流程说起,在聊一聊目前系统存在的问题,以及为serverless改造所做的努力。

转码流程

众所周知,转码是CPU密集型任务,一个长视频在单机上可能要转很久。但如果能用尽可能利用多的CPU去进行转码,那么转码速度将会大大加快。而现在丰富的云产品能够在短时间内提供大量的计算能力,以阿里云为例,阿里云提供了函数计算、Serverless应用引擎等serverless产品能够支撑起我们所需要的计算能力。
于是为了提高转码倍速,我们将

  1. 视频进行切片,每一个切片都是一个转码任务。一个长视频经过切片以后就会被切分成大量转码子任务。
  2. 将转码子任务调度到不同的机器上执行,充分利用不同机器上的CPU资源,提高转码速度
  3. 当所有的转码子任务都执行完毕以后,再进行汇总合并输出转码后的视频

流程如下:

          切片                  转码                  合并 输入视频 ------> (n个)转码任务 ------> (n个)转码结果 -----> 输出视频   

改造前的系统架构

再来看看我们的系统架构。

之前转码服务是一个应用,同时肩负着调度和转码的职责,其中:

  1. 调度主要是跟MySQL、Redis打交道:用Redis维护任务队列;MySQL则用来保存任务的执行状态
  2. 转码则是执行任务:读取文件系统中的源视频,转码后再将视频写入到文件系统中

转码服务serverless探索

大规模集群面临的问题

上面有提到为了提高转码速度,我们会有多个转码服务实例进行转码,但是上面的系统架构会限制转码集群的实例数。

上面的系统架构中,转码服务既承担了转码职责,也承担了调度的职责(获取任务、以及更新任务状态)。不符合存储(Redis、MySQL等数据层)与计算分离,无法大规模快速获取计算能力。

因为承担了调度的职责就不可避免的要与Redis、MySQL打交道,启动服务时就要与Redis、MySQL建立连接,且不说建立大量的连接Redis、MySQL能不能承受的住,光是建立连接所需要花费的时间就是一笔很大的浪费。

serverless改造

为了提供大规模的转码计算能力,我们决定对转码服务进行改造。

方案

改造的方案主要思路是将存储与计算分离,说大白话就是讲调度职责与转码职责进行分离,这样就可以只对转码计算能力进行扩容。
这里主要聊转码(计算)节点的改造点,主要有2个:

  1. 移除数据层的访问操作(剥离调度服务能力),避免建立连接
  2. 优化启动速度,尽可能缩短应用启动时间

移除数据层的访问操作

将转码(计算)节点的数据层访问操作全部都移除后,如何与调度服务进行通信呢?比如获取任务、提交转码结果需要通过调度服务访问Redis和MySQL。
一般有2种选择:dubbo或者http。我最终选择使用http进行通信。

这里先说一下为什么没有选择dubbo:还是上面所提到的、需要建立连接的问题,如果使用dubbo,那么就需要与zk等注册中心建立连接。而且如果发生大规模上下线(如发布)操作,那么势必给注册中心带来巨大的推送压力。

选择http进行通信,摆在眼前的第一个问题是:转码(计算)节点怎么知道调度节点的访问地址?
因为我们的服务部署在k8s集群中,借助k8s内部域名天然的解决了获取调度节点访问地址的问题。我们只需要访问调度节点在k8s中内部域名地址就可以访问到调度节点接口,而无需关系发布所带来的ip变化等情况。

使用http进行通信,调度节点除了需要做好优雅下线,避免http请求被意外终止;还需要做好数据幂等的措施。

提高应用启动速度

作为云原生应用,不会常备很多计算资源,但是需要的时候希望马上就有,这就要求应用启动越快越好。
影响应用启动速度的主要有下面2点:

  1. 拉镜像
  2. 应用启动

拉镜像的速度

我们选择了阿里云 sae job作为serverless载体,sae job刚好有一个镜像加速的能力:拉镜像到启动镜像可以做到15s,还可以接受,这块就不展开了。

应用启动

这块主要是尽可能的将非必须的代码移除,减少springboot扫描的bean,目前启动时间在6s左右。
另外也在尝试使用graalvm编译成本地可执行文件,测试的启动时间约1s左右。因为涉及到SpringBoot大版本变更以及JDK版本变更,这个方案还在测试,没有发布到生产环境。

改造后的系统架构

转码服务serverless探索

效果

serverless改造后的转码服务,带来的效果有2个:

  1. 带来更高的转码速度:在面对大量转码也不用担心转码慢的问题,一个字-扩!
  2. 成本的显著降低:得益于按量付费的模式,只需要为实际使用的计算资源付费,无需预留计算资源。
发表评论

相关文章

当前内容话题