七牛云：大规实时流处理平台架构.docxVIP

七牛云：大规模实时流处理平台架构 随着不同网络质量下接入终端设备种类的增多，服务端转码已经成为视频点播和直播产品中必备的能力之一。直播产品讲究时效性，希望在一定的时间内让所有终端看到不同尺寸甚至是不同质量的视频，因此对转码的实时性要求也较高。上次卜赫分享了我们实时流网络 LiveNet 的架构，它在整个流分发的环节中起着流传输通道和网络骨干的作用。理论上它和传输内容的类型是无关的，可以传输音频和视频数据，也可以传输其它数据包，因此涉及到编码和转码相关的内容比较多。今天我的分享主要集中于七牛直播云实时流处理平台的架构。 通用直播模型 这是一个通用的直播模型，大家可能对直播产品的架构已经非常熟悉了。无论是自己去建设，还是使用第三方云服务，它的通用架构都差不多是这样的。一个生产环境可用的直播产品应该包含一个主播方，它是产生视频流的源头。主播播出去的视频，最直接的诉求就是希望被观众观看到，我们称之为播放端。 我们知道，一般来讲，内容产生方和消费方一般都不是一一对应的。对于一个直播产品来讲，最直观的体现就是一个主播可能会有很多粉丝。因此，我们不能直接让主播端和所有播放端进行点对点通信，这在技术上是做不到或者很有难度的。主播方播出的视频在到达播放端之前，需要经过一系列的中间环节，也就是图中的「直播服务器」端，它能够把主播方的能力放大，提供更加强大的通信通道供主播方和所有播放端进行对话。 这是一个看起来非常简单的模型，实际上无论是主播端还是播放端，他们的诉求都不会仅仅是拍摄视频和播放视频这么简单。在这个核心诉求被满足之后，还有很多关键诉求需要被满足。接下来我们再看看，实现一个基于这个简单模型的消费级直播产品还需要做哪些事情。 七牛直播云方案 首先，在主播端，他需要通过一定的设备来拍摄视频，我们称之为采集。然后，将采集的这些视频进行一系列的处理，比如水印、美颜和特效滤镜等处理。最后将处理后的结果视频进行编码压缩成可观看可传输的视频流，再通过网络通道传输出去。 对于一个社交直播产品来说，在观众端，他希望能够实时的看到主播端推过来的视频流，并且和主播以及其他观众产生一定的互动，比如点赞、聊天、弹幕甚至是一些高级道具。这就是播放端所需做的事情。 我们前面说过，主播端不太可能直接和播放端进行连接，在这个过程中还有一个中间环节，帮助主播把能力放大，以满足更多的观众，这就是「直播服务器」端。 通常来讲，直播服务器端提供的最核心功能是收集主播端的视频推流，并将其放大后推送给所有观众端。直播服务端由一系列的网络节点构成，它们都能够进行收流和分发视频流，这个流式传输的网络结构我们在上一次分享中卜赫重点介绍过了。除了这个核心功能之外，还有很多运营级别的诉求需要在这个服务端满足，比如鉴权认证，视频连线和实时转码，自动鉴黄，多屏合一，以及云端录制存储等功能。另外，对于一个主播端推出的视频流，中间需要经过一些环节才能到达播放端，因此对中间环节的质量进行监控，以及根据这些监控来进行智能调度，也是非常重要的诉求。 七牛直播云平台框架 接下来我们分享这个流分发网络中涉及到的实时流处理平台的架构。 这里我们先简单的来看下这个实时流处理平台包含哪些内容。这是我们「直播云平台」的框架图，我们今天分享的内容主要集中于「存储与回访」、「转码和内容处理」以及「内容识别」平台的架构，同时它还包含实时转存储的能力，也就是图中间的绿色部分所表示的模块。 为什么需要实时转码？ 在分享实时转码平台架构之前，我们先来回答一个问题，为什么需要对视频流进行实时转码？ 从字面上看，实时性的要求是直播场景决定的，它需要保证比较低的延时。那么，为什么需要转码？ 1. 编码器的多样性：我们知道，经过 30 年的长时间发展，市场上出现了无数多的音视频编码器和编码格式。同时，现在主流的终端设备和操作系统有好几个，它们对于不同编码解码器的支持都不一样。这就导致了在不同设备不同平台之间播放相同的视频可能存在差异。 2. 带宽限制：现在移动 3G 和 4G 网络已经非常普及了，他们的速度也相对较快，但还是存在很多弱网环境，比如偏远地区户外，或者大型活动现场。要保证在不同网络条件下都能流畅的在线观看视频，网络自适应的传输不同码率的视频是目前最好的选择。 3. 终端设备的多样性还体现在另外一方面，也即它们尺寸的多样性。设备屏幕尺寸的大小决定了在它们上面呈现视频的最佳分辨率，因此为了在不同设备下都能获得最佳用户体验，需要在服务端准备多种不同尺寸的视频流。 大规模实时转码面临的挑战 回答了为什么需要实时转码之后，我们再来看一下它面临哪些挑战。网络方面的架构之前卜赫已经分享过，我们假设转码所需数据能够通过 LiveNet 实时流网络获取到，同时转码结果也能够通过实时流网络 LiveNet 实时传输出去。因此，这里讲的第一个