本篇文章为你整理了转码服务serverless探索（转码服务支持）的详细内容，包含有转码服务器的作用 转码服务支持 转码服务器要求配置 转码kux 转码服务serverless探索，希望能帮助你了解 转码服务serverless探索。

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

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

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

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

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

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

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

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

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

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

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

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

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

　　流程如下：

　　 切片 转码 合并

　　输入视频 ------ （n个）转码任务 ------ （n个）转码结果 ----- 输出视频

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

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

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

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

　　大规模集群面临的问题

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

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

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

　　serverless改造

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

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

　　这里主要聊转码（计算）节点的改造点，主要有2个：

　　移除数据层的访问操作（剥离调度服务能力），避免建立连接

　　优化启动速度，尽可能缩短应用启动时间

　　移除数据层的访问操作

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

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

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

　　选择http进行通信，摆在眼前的第一个问题是：转码（计算）节点怎么知道调度节点的访问地址？
 

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

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

　　提高应用启动速度

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

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

　　拉镜像的速度

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

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

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

　　改造后的系统架构

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

　　带来更高的转码速度：在面对大量转码也不用担心转码慢的问题，一个字-扩！

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

　　以上就是转码服务serverless探索（转码服务支持）的详细内容，想要了解更多 转码服务serverless探索的内容，请持续关注盛行IT软件开发工作室。

郑重声明：本文由网友发布，不代表盛行IT的观点，版权归原作者所有，仅为传播更多信息之目的，如有侵权请联系，我们将第一时间修改或删除，多谢。