视频云面向海量用户的分布式视频处理技术系统介绍

视频云的视频处理子系统需求模型如下所示：

视频云上层服务根据业务模型，向视频处理子系统发起视频处理任务，处理子系统根据任务类型调度到合适的worker节点做处理。在任务产生事件时，处理子系统会将事件回调通知给上层服务，如录制切片事件、视频转码完成事件。

在过去几年，视频云为网易内部视频应用提供了稳定可靠的大规模音视频处理服务，如青果、云音乐、教育产品。近两年，随着公有云服务模式趋于成熟，网易视频云渐渐以公有云的身份被大家所了解，与私有云相比，公有云的视频云要面临以下两个挑战：

1.     海量用户

2.     资源超售

在内部服务时代，视频云需要服务的应用数量有限，调度系统和回调系统压力较小，而且可以为一些应用定制特殊功能。而在公有云服务中，面向海量企业用户，调度系统承担的压力更重，在保障公平调度的基础上，需要实现调度能力的水平扩展。

在为内部应用提供服务时，为了保障各个应用的服务质量，一般不做处理资源超售，但是在公有云中，由于用户太多，资源闲置是一种常态，不超售会造成极度的资源浪费。因此，在保障公有云的服务质量前提下，最大限度的节约成本是视频云在公有云场景下需要攻克的重要课题之一。为了做好这一点，公有云提供了比以前更加细致的任务统计，资源监控，便于公有云的容量规划。

系统架构

视频云的视频处理系统架构如下图所示：

²  sdk：接口层，上层服务通过SDK向视频处理系统发起任务和事件回调

²  scheduler：调度子系统，又分为在线调度器和离线调度器

²  worker：任务执行器，一般包含10-1000个slot，每个slot对应一个处理任务

²  notifier：事件回调子系统，收集各个worker中的任务事件，并通知SDK

²  configserver：集群管理，元数据同步，任务统计和资源监控等

²  dashboard：可视化运维的WEB工具

以上模块和子系统的实现，满足了视频云对用户管理、任务调度、任务追踪、事件回调和文件存储等核心功能需求。在非功能性方面，视频云实现了调度子系统的高可用和水平扩展，worker宕机重试。configserver在架构中属于单点，通过主从架构实现高可用。

核心技术

FlickRpc框架

FlickRpc是视频云团队自主研发的一个通用rpc框架，是各个组件模块互相调用和通信的基础。FlickRpc采用了netty长连接和json通信格式，使用google的gson库实现json格式的序列化和反序列化，与grpc，avro一类的开源RPC框架相比，FlickRpc无需定义消息格式，可像使用本地方法一样调用RPC，并且 FlickRpc中不存在json反序列化与JAVA继承的冲突，更加简单易用；FlickRpc提供了同步调用和异步调用两种模式，可以通过静态上下文获取RPC远端信息；虽然FlickRpc是为视频云开发，但其本身是一个通用RPC框架，可以在任何系统中使用。

FlickRpc的使用极大简化了视频云在通信层的开发量，未来FlickRpc会独立开源。

灵活的调度模式

视频云视频处理系统有在线和离线调度器两种不同调度子系统，在线调度器适用于录制、截图以及在线视频合并等在线视频处理。这种任务的特点是具有很强的时效性，需要实时调度。例如录制任务，如果调度产生较大延迟，会导致录制内容丢失。

离线调度器适用于各种类型的转码业务，特点是任务可以积压，可以慢慢异步消费。如点播系统的视频转码，一个用户可以一次性提交很多待转码视频，只要在一个笼统的时间范围内完成即可，无需所有任务实时调度。

离线调度器是视频云超售的基础，因为只有允许一定的任务积压，才能在保证服务可靠的前提下节约资源成本。

租约与高可用

configserver和其他组件通过租约的方式实现元数据同步和高可用，以离线调度器高可用为例，如下图所示：

调度器A和调度器B负责调度不同用户的离线任务，A和B在启动时会向configserver注册，并获取元数据和租约信息，以及他们各自需要调度哪些用户。A和B每隔一段时间（5s-60s）会向configserver续租，如果A在某个时间宕机，一段时间后configserver会发现A持续多个周期没有续租，为了保障用户调度的高可用，configserver需要将A负责的调度任务交由相邻节点B继续执行，为此configserver会更新B的租约，在下次B续租时可以更新到新的租约和元数据，并触发reload。

通过租约机制，可以实现不同组件的元数据同步，调度器的水平扩展和主从模式等。

负载均衡

一个视频处理集群中，可以部署多个worker group，任务参数中可以指定在哪个worker group中执行，worker group的划分使视频云可以在容量规划中因地制宜，例如录制任务需要大量的IO操作，因此录制任务的worker group需要配备SSD和千兆网络，而录制过程几乎不会耗CPU资源，可以在CPU配备上节约成本，而转码任务反之。

在一个worker group内，任务调度在没有超过worker slot上限的前提下，采用取模哈希的方式满足负载均衡，当worker调度到的任务数到达slot上限，会从调度器中剔除，直到新的slot空闲出来。