转码服务serverless探索

背景

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

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

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

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

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

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

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

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

转码流程

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

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

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

流程如下：

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

改造前的系统架构

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

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

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

大规模集群面临的问题

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

上面的系统架构中，转码服务既承担了转码职责，也承担了调度的职责（获取任务、以及更新任务状态）。不符合存储（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改造后的转码服务，带来的效果有2个：

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