转码服务serverless探索

背景

公司目前主要聚焦于视频这个领域,利用视频为媒体、文旅、会议等行业进行赋能。

既然聚焦于视频领域,那么视频转码则是绕不开的话题。

为了降低成本,以及保证产品的核心能力,公司自建了一套转码系统。

转码服务除了尽可能多的兼容业界的视频格式外,转码的速度是另一个非常重要的指标。

因为视频转码对用户来说,感知最强的就是视频转码速度。

假如用户上传了一个1分钟的视频,转码花了10分钟甚至更久的话,用户肯定就不愿意使用我们的产品了。

对于用户来说等待的时间越短越好,对于转码服务来说转码速度越快越好。

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

转码流程

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

于是为了提高转码倍速,我们将

  1. 视频进行切片,每一个切片都是一个转码任务。一个长视频经过切片以后就会被切分成大量转码子任务。

  1. 将转码子任务调度到不同的机器上执行,充分利用不同机器上的CPU资源,提高转码速度

  1. 当所有的转码子任务都执行完毕以后,再进行汇总合并输出转码后的视频

流程如下:


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

改造前的系统架构

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

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

  1. 调度主要是跟MySQL、Redis打交道:用Redis维护任务队列;MySQL则用来保存任务的执行状态

  1. 转码则是执行任务:读取文件系统中的源视频,转码后再将视频写入到文件系统中

大规模集群面临的问题

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

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

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

serverless改造

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

方案

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

这里主要聊转码(计算)节点的改造点,主要有2个:

  1. 移除数据层的访问操作(剥离调度服务能力),避免建立连接

  1. 优化启动速度,尽可能缩短应用启动时间

移除数据层的访问操作

将转码(计算)节点的数据层访问操作全部都移除后,如何与调度服务进行通信呢?比如获取任务、提交转码结果需要通过调度服务访问Redis和MySQL。

一般有2种选择:dubbo或者http。我最终选择使用http进行通信。

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

选择http进行通信,摆在眼前的第一个问题是:转码(计算)节点怎么知道调度节点的访问地址?

因为我们的服务部署在k8s集群中,借助k8s内部域名天然的解决了获取调度节点访问地址的问题。我们只需要访问调度节点在k8s中内部域名地址就可以访问到调度节点接口,而无需关系发布所带来的ip变化等情况。

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

提高应用启动速度

作为云原生应用,不会常备很多计算资源,但是需要的时候希望马上就有,这就要求应用启动越快越好。

影响应用启动速度的主要有下面2点:

  1. 拉镜像

  1. 应用启动

拉镜像的速度

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

应用启动

这块主要是尽可能的将非必须的代码移除,减少springboot扫描的bean,目前启动时间在6s左右。

另外也在尝试使用graalvm编译成本地可执行文件,测试的启动时间约1s左右。因为涉及到SpringBoot大版本变更以及JDK版本变更,这个方案还在测试,没有发布到生产环境。

改造后的系统架构

效果

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

  1. 带来更高的转码速度:在面对大量转码也不用担心转码慢的问题,一个字-扩!

  1. 成本的显著降低:得益于按量付费的模式,只需要为实际使用的计算资源付费,无需预留计算资源。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值