在LiveVideoStack线上交流分享中，新浪微博视频平台架构师曾诚分享了微博大规模视频处理如何应对多业务场景，大流量，高并发的挑战。包括利用工作流式计算引擎实现场景动态配置，以及采用流式上传协议SVE来解决大流量高并发的问题等内容。

文 / 曾诚

整理 / LiveVideoStack

直播回放:

https://www2.tutormeetplus.com/v2/render/playback?mode=playback&token=3ca02ec2b971400189f9176f239b5677

大家好，我叫曾诚，来自新浪微博视频平台。新浪微博作为大家熟知的社交媒体平台，每天有大量丰富的视频在此平台传播，用视频作为信息传播的载体已经成为主流。

微博每天新上传的视频量超过百万，播放次数也达到几十亿，面对这个量级，基本可以用大规模视频处理来形容了。大规模视频处理不同于传统意义上的大规模并发处理，因为视频上传完毕后，还需要复杂的转码，截图，审核，打水印，质量识别等等。那么本次分享主要是给大家介绍一下微博是如何进行大规模视频处理的。

1. 业务场景和挑战

1.1业务场景

首先我们来看一下微博的业务场景。

1) 从视频产品的角度来说：我们有微博视频，微博故事，酷燃视频，微博云剪，另外我们还有独立的app喵呜视频，波波视频等，基本涵盖了目前能用到视频的所有场景。

2) 从视频创作者角度来说：前面的产品矩阵能够让不同的创作者找到适合自己的平台。例如以UGC用户为主的微博故事，用户可以拍摄一些有趣的短视频，记录身边发生的事情，它的特点是竖版的短视频，对清晰度要求非常高，同时能够添加一些有趣的贴纸，支持在线编辑制作，拍摄完成后可以立刻发出来。微博视频和酷燃视频更多是针对PGC的一些尝试，能够管理自己的视频集，支持横竖版，对视频质量有更高的要求。另外还有一些针对OGC的媒体用户，他们需要快速发布视频到微博中， 对清晰度要求没有那么高。

3) 从业务流程的角度来说：视频处理的能力，包括视频上传，转码的策略，封面图是用户自定义还是截取，以及如何进行内容分辨，水印的位置大小，视频审核是先审后发，还是先发后审，不同产品的特点是不一样的。最后我们会收集用户的观看信息不断进行改善。

1.2挑战

针对微博视频丰富的业务场景和巨大的流量，对后端视频处理也提出了更高的要求

1） 业务场景的多样化：我们有超过了20个不同的业务方，包括前面提到的微博故事，酷燃视频，还有媒体直播视频等业务方，涵盖了短视频、长视频，不同的业务它们的处理流程也不一样，例如一些业务场景需要视频上传完成后立刻发布，一些需要进行广电审核才能发布，不同的业务方水印也不一样。针对这些业务场景我们急需要有能够动态配置，快速接入新的业务的能力。因此，我们设计实现了工作流式计算引擎Workflow ，以针对不同的业务场景实现动态配置。

2） 大流量高并发：微博MAU已经超过4.5亿，每天视频上传量也超过百万，同时微博作为媒体社交平台，第一属性还是媒体，很多用户对于视频的发布速度有非常高的要求，比如一些热点视频，早发出来5分钟可能在微博上的播放量会有数量级的差距，这种情况下，用户对视频的上传速度和发布速度有了更高的要求。另外，随着手机等各种拍摄设备的高清化，发布的视频文件也越来越大，在网络条件一定的条件下，视频上传发布的时间也越来越长。针对这种需求场景 ，我们设计实现了一整套的流式上传处理协议SVE，能够确保视频在上传的过程中，后端进行多分辨率输出的转码。

3） 扩展的高效性：由于上传的每个视频都需要有多个不同分辨率和协议的输出，每天需要处理的视频任务达到亿级，如何快速的进行任务调度，让所有的计算资源能够均衡的分配，同时在一些视频上传高峰时期，能够进行横向动态扩展，这些都是我们要考虑的问题。因此我们设计和实现了一整套流式资源调度系统来解决资源调度和扩展的问题。

2. 流式视频处理架构

面对我们遇到的挑战，前面已经提出了三种相对有针对性的解决方案，那么这些解决方案如何相互配合工作的呢？

客户端可以选择视频上传的协议，协议有两种，Binary和Sve，不同的协议， workflow处理起来会有一些差别，在最后通知Transcode。其实整个流程看起来并不复杂， 重点在于每一块内部的设计和灵活性。

客户端选择上传协议，可能要根据自己的实际情况来选择，每种协议有自己的优缺点。流式上传协议需要确保整个工作流的完整性，实时性，出现问题要能够及时发现和处理，并且要灵活可配置。流式资源调度系统更多的是去解决转码资源调度不均衡，SVE协议使用后，任务数成几何增长带来的调度问题，这三个部分其实是有相关性的。

2.1工作流式引擎设计思想

工作流式引擎设计思想的目标包括：1. 管理好任务依赖关系，能够灵活的为不同业务配置不同的模板。2. 可视化配置，能够随时查看工作流执行的进度情况。3. 任务类型尽可能丰富，每个任务的工作相对独立。4. 具有一定的容错性，并且能够进行错误处理。

根据以上内容可以将目标划分为四个部分：DAG的调度框架，Task任务划分，以及业务工作流（Biz Workflow），最后是对账系统(Check Bill)。

DAG调度框架

上图中是一个有向无环图，从任意顶点出发无法经过若干条边回到该点，学过数据结构应该都能够了解它的原理。我们依照有向无环图的原理设计了自己的DAG的调度框架。创建完DAG以后，调度会自动从入度为零的节点进行拓扑遍历，直到无后续节点存在。但是每个节点开始执行都是有条件的，在没有前置节点时，需要一些外部的调用或者事件来触发该节点，要是有前置节点，那么需要它前置节点都已经执行完毕，这时候该节点会自动执行，并且一直向后拓扑，直到碰到不符合执行条件的节点，然后继续等待触发。

DAG调度框架中每个Task节点有个非常重要的原则， 必须是单一可执行，它依赖于前后上下文的信息，但是不依赖于他们的资源，或者是内部的一些能力等等。

Biz Workflow

Biz  Workflow是我们业务处理的真实流程。这里列出了一些Task节点的能力，每个Task都有四种状态：未开始，正在进行中，执行成功，执行失败。四种状态可以相互转化，其中，未开始只有两种情况会变成正在执行中，第一，无前置节点，必须被事件触发，事件可以是接口调用，或者收到MCQ消息等。第二，有前置节点，但必须所有的前置节点都执行成功才会触发，这个是由DAG调度框架控制，每次改变Task节点状态时，调度框架都会遍历整个DAG，看是否有满足条件的节点需要执行。正在执行的节点最终也会变成执行成功或者执行失败，在整个过程中，如果有节点执行失败，整个Workflow最终不会执行完毕。

Check Bill System

前面的工作流中已经提到，如果有节点失败，整个工作流会执行失败，为了确保整个流程的正常运转，我们设计和实现了对账系统，它在整个工作流引擎中是非常重要的一部分。

对账系统包括5个模块：1.节点信息搜集，2.定时轮询检查，3.重新任务发起，4.探测预警，5.可视化。

1. 节点信息搜集：每个任务节点在改变状态的时候都会上报自己的信息，包括任务id，当前状态等。

2. 定时轮询检查：每隔一段时间都会检查任务的执行时间，如果该任务超过一定的时间阈值，则认为该任务失败。

3. 重新任务发起：根据前面的检查，发现任务失败，会检查失败的TASK节点，并重新发起任务，并标记重试次数。

4. 探测预警：一旦达到一定的重试次数，会向管理员发送预警，进入人工干预。

5. 可视化：很直观的发现任务失败的原因，并进行实时处理。

GOP

GOP是两个关键帧之间的片断，因为I是完整的画面，PB是预测帧。简单的说就是我们将视频进行切割，如果按GOP（两个I帧）去切的话，最终出来的视频是可以单独播放的。基于这个原理特性，我们设计实现了一套完整的流式上传协议SVE。

2.2 流式上传协议（SVE）

SVE（Streaming Video Engine）协议最核心的部分是视频的并行处理，也就是所谓的边传边转码。

图中展示了两种上传协议效率对比：第一种是普通的二进制分片上传，需要等待最后一片上传完毕才发起transcode，整个流程需要等待的时间包括视频上传时间和转码时间。第二种是边传边转码，每个上传的分片按照GOP进行切割，上传完成后可以进行单独转码，整个流程的时间为视频上传时间加上最后一个分片的转码时间。相比之下，如果切分文件大小一定的条件下，文件越大，SVE协议的效率越高，大文件的处理时间基本等于上传时间，效率提高非常明显。

按照上述的方式我们设计实现了整套的SVE（Streaming Video Engine）协议框架。

SVE（Streaming Video Engine）协议在实现上相比Binary上传协议要复杂多，同时需要客户端能够支持GOP切分，对转码的任务调度能力要求也非常高。

图中展示了两种不同视频上传协议的架构图：

Binary上传协议架构：按协议等比例切割文件，切割后的文件为二进制，不包含视频头，在上传完成后，通知Trans Center即可，Trans Center会启动一个Runner任务，该Runner先去Storage下载整个视频，然后进行转码，最后将转码完毕的视频上传到Storage中。

SVE上传协议框架：客户端需要按照GOP进行文件切割，服务端将每个分片存入Temp Storage，同时通知Trans Center启动一个Runner任务去处理该分片，处理的过程包括下载GOP分片，转码（多个分辨率），上传转码后的分片到Temp Storage，当所有的分片都上传完毕时，Trans Center启动一个Runner任务，将所有的转码后的视频分片下载下来，合成一个完整视频，上传到Storage。

使用SVE上传协议要解决两个问题：

第一：客户端必须能够支持这个协议，也就是能够按照GOP的方式对视频进行切割，通常手机客户端容易去实现，pc端实现起来比较复杂。

第二：转码的任务调度能力要求非常高，假设上传视频需要转出四个分辨率，按照SVE协议，假如一个视频被切割成100个片段，需要转码的视频任务就是400个，最后还需要将这些片段下载下来，合并成一个文件，如何快速的将任务分配到合适的转码机器也是一个挑战。

Transform for Parallel

在一些场景下，如果客户端不支持SVE（Streaming Video Engine）协议，同时上传的视频非常大，也能在服务端通过切割视频，进行并行转码，提高转码效率。

上图是服务端实现视频并行转码的流程图，在视频上传完毕后，通过GOP切分，将视频切割成音频和一批小视频，并且将这些小视频分发到不同的机器上，最后达到并行转码的效果。

虽然这种方式没有客户端实现SVE协议的效率高，但如果上传文件是非常大的视频，对于整体效率的提升还是非常明显。

SVE协议是将视频分解成一个个小视频进行并行转码，这也带来一个问题，转码任务数量成几何增长，对于转码任务如何调度，如何分配资源提出了更高的要求。下面我们介绍一下转码调度设计的两种方式：pull模式和push模式。

Pull模式转码调度：整个系统分为三个部分，任务队列（Task Queue），调度中心（Trans Center），任务处理机（Agent/Runner）。

任务队列（Task Queue）：任务队列是为了区分任务的优先级而设立的，不同的业务，不同的阶段，优先级都不一样，调度中心进行统一调度，特殊情况下也可以人为干预

调度中心（Trans Center）：消费任务队列，统一放在任务池中，记录每个任务执行的机器信息和结果信息，任务完成时通知业务方。

任务处理机（Agent/Runner）：处理机可以认为是一台单独的物理机器，上面会部署一个Agent服务，多个Runner服务。一个Runner服务就是一个转码任务，包括了原始视频下载，水印下载，转码，转码后视频上传，结果通知center等。Runner服务结束后会告知Agent服务，并结束掉自己的进程。通常会根据机器的配置Runner的最大个数，Agent服务是管理自己机器的Runner个数，一旦发现没有达到最大数量，就会去Trans Center拉取任务，获取到任务后，Trans Center会将任务和Agent机器ip绑定，等待任务结束的通知。

Pull模式的优点：实现起来简单，可以快速的把任务派发下去，能够快速的水平扩展，但需要注意center和底层资源的压力。

Pull模式的缺点：计算资源调度分布不均衡，每个任务需要的计算资源是不一样的，单纯用个数去控制容易造成大文件转码耗时较高。

2.3 Push模式的转码调度框架

Push模式转码调度包括三个部分：队列（三种队列），调度中心（Scheduler），执行器（Executor）。

队列（Queue）：我们设计实现了三种队列。Task Queue作为任务优先级队列，优先级越高，越能更早的被分配下去。Executor Queue 是机器空间度优先级队列，根据机器的配置设置slot，一个slot代表一个计算资源，slot越大，说明空闲度越高，优先级也就越高。Running Queue是执行中的队列，可以表示哪些任务正在执行中，一旦执行完毕，会从队列中移除，为了防止部分Executor出现宕机，后台会有定时任务轮训，发现超时的任务，会将任务重新放入Task Queue。

调度中心（Scheduler）：统一管理和调度资源，从Task Queue中拿到优先级最高的任务，从Executor Queue中拿到空间度最大的机器，将这个任务和机器绑定后放入Running Queue，并通知Executor开始执行，这样任务就下发下去了。

执行器（Executor）：每个执行器可以认为是一台物理机器，负责执行具体的转码任务，除了执行任务以外，每隔一段时间要向注册中心发送心跳，心跳的内容包括slot信息，机器的状态等，注册中心会根据机器的状态调整机器在Executor Queue中的优先级，如果一段时间注册中心没有收到心跳，会将机器移除。

Push模式的优点：能够实时监控整个集群的资源，并且将优先级最高的任务派发给最空闲的机器，让计算资源最大化

Push模式的缺点：实现起来比较复杂

2.4 上传分片优化

前面讲到的协议都涉及到分片上传，但更多的关注点在于上传后如何处理，如果提高效率，其实视频分片上传的速度和成功率对于整体的效率提升影响也是非常大的。

上图左边是在不同分片大小下，iphone，Android，pc三端的上传速度对比，可以发现，分片越大，上传速度越快。由于我们底层使用的是TCP协议，TCP协议需要经历三次握手建立连接，滑动窗口的慢启动的过程，这个过程速度是很慢的，如果分片过小，当滑动窗口刚刚打开，数据就传送完毕，会导致建立连接和慢启动在整个过程中占用时间比例过多，因此分片越大，速度也就越快。

上图右边是在不同分片大小下，iphone，Android，pc三端的上传成功率对比，可以发现，分片越大，成功率越低。由于文件越大，对于网络的要求越高，同等网络条件下，传输的时间越长，出现失败的概率也就越大。

LiveVideoStackCon 2019北京 音视频技术大会 初版日程现已上线，扫描图中二维码或点击【阅读原文】了解大会最新日程。