大规模实时流处理平台架构-zz

随着不同网络质量下接入终端设备种类的增多，服务端转码已经成为视频点播和直播产品中必备的能力之一。直播产品讲究时效性，希望在一定的时间内让所有终端看到不同尺寸甚至是不同质量的视频，因此对转码的实时性要求也较高。上次卜赫分享了我们实时流网络 LiveNet 的架构，它在整个流分发的环节中起着流传输通道和网络骨干的作用。理论上它和传输内容的类型是无关的，可以传输音频和视频数据，也可以传输其它数据包，因此涉及到编码和转码相关的内容比较多。今天我的分享主要集中于七牛直播云实时流处理平台的架构。

通用直播模型

这是一个通用的直播模型，大家可能对直播产品的架构已经非常熟悉了。无论是自己去建设，还是使用第三方云服务，它的通用架构都差不多是这样的。一个生产环境可用的直播产品应该包含一个主播方，它是产生视频流的源头。主播播出去的视频，最直接的诉求就是希望被观众观看到，我们称之为播放端。

我们知道，一般来讲，内容产生方和消费方一般都不是一一对应的。对于一个直播产品来讲，最直观的体现就是一个主播可能会有很多粉丝。因此，我们不能直接让主播端和所有播放端进行点对点通信，这在技术上是做不到或者很有难度的。主播方播出的视频在到达播放端之前，需要经过一系列的中间环节，也就是图中的「直播服务器」端，它能够把主播方的能力放大，提供更加强大的通信通道供主播方和所有播放端进行对话。

这是一个看起来非常简单的模型，实际上无论是主播端还是播放端，他们的诉求都不会仅仅是拍摄视频和播放视频这么简单。在这个核心诉求被满足之后，还有很多关键诉求需要被满足。接下来我们再看看，实现一个基于这个简单模型的消费级直播产品还需要做哪些事情。

七牛直播云方案

首先，在主播端，他需要通过一定的设备来拍摄视频，我们称之为采集。然后，将采集的这些视频进行一系列的处理，比如水印、美颜和特效滤镜等处理。最后将处理后的结果视频进行编码压缩成可观看可传输的视频流，再通过网络通道传输出去。

对于一个社交直播产品来说，在观众端，他希望能够实时的看到主播端推过来的视频流，并且和主播以及其他观众产生一定的互动，比如点赞、聊天、弹幕甚至是一些高级道具。这就是播放端所需做的事情。

我们前面说过，主播端不太可能直接和播放端进行连接，在这个过程中还有一个中间环节，帮助主播把能力放大，以满足更多的观众，这就是「直播服务器」端。

通常来讲，直播服务器端提供的最核心功能是收集主播端的视频推流，并将其放大后推送给所有观众端。直播服务端由一系列的网络节点构成，它们都能够进行收流和分发视频流，这个流式传输的网络结构我们在上一次分享中卜赫重点介绍过了。除了这个核心功能之外，还有很多运营级别的诉求需要在这个服务端满足，比如鉴权认证，视频连线和实时转码，自动鉴黄，多屏合一，以及云端录制存储等功能。另外，对于一个主播端推出的视频流，中间需要经过一些环节才能到达播放端，因此对中间环节的质量进行监控，以及根据这些监控来进行智能调度，也是非常重要的诉求。

七牛直播云平台框架

接下来我们分享这个流分发网络中涉及到的实时流处理平台的架构。

这里我们先简单的来看下这个实时流处理平台包含哪些内容。这是我们「直播云平台」的框架图，我们今天分享的内容主要集中于「存储与回访」、「转码和内容处理」以及「内容识别」平台的架构，同时它还包含实时转存储的能力，也就是图中间的绿色部分所表示的模块。

为什么需要实时转码？

在分享实时转码平台架构之前，我们先来回答一个问题，为什么需要对视频流进行实时转码？

从字面上看，实时性的要求是直播场景决定的，它需要保证比较低的延时。那么，为什么需要转码？

1. 编码器的多样性：我们知道，经过 30 年的长时间发展，市场上出现了无数多的音视频编码器和编码格式。同时，现在主流的终端设备和操作系统有好几个，它们对于不同编码解码器的支持都不一样。这就导致了在不同设备不同平台之间播放相同的视频可能存在差异。

2. 带宽限制：现在移动 3G 和 4G 网络已经非常普及了，他们的速度也相对较快，但还是存在很多弱网环境，比如偏远地区户外，或者大型活动现场。要保证在不同网络条件下都能流畅的在线观看视频，网络自适应的传输不同码率的视频是目前最好的选择。

3. 终端设备的多样性还体现在另外一方面，也即它们尺寸的多样性。设备屏幕尺寸的大小决定了在它们上面呈现视频的最佳分辨率，因此为了在不同设备下都能获得最佳用户体验，需要在服务端准备多种不同尺寸的视频流。

大规模实时转码面临的挑战

回答了为什么需要实时转码之后，我们再来看一下它面临哪些挑战。网络方面的架构之前卜赫已经分享过，我们假设转码所需数据能够通过 LiveNet 实时流网络获取到，同时转码结果也能够通过实时流网络 LiveNet 实时传输出去。因此，这里讲的第一个挑战「低延时」只涉及到编解码效率和内部路由环节。

其次，直播云服务需要向很多企业级公司提供服务，面临非常大的终端用户量，这是另外一个挑战。

最后，应国家有关部门和业务的需求，直播过程中产生的数据需要存档。在某些业务场景教育直播，直播过程产生的数据具有非常大的存档价值。面对海量的直播流，如何将其实时存储起来是另一个较大的挑战。

低延时带来的挑战

我们先来看一下「低延时」带来的挑战。要做到较低的延时，首先意味着转码性能需提升，也即，要么使用性能更好的硬件（比如 GPU），要么优化编码解码器的能力，降低编码延迟。或者，减少关键帧间隔，增加关键帧出现的频率，这样能够让播放器以较高频率获取到关键帧，直接解码播放，降低等待关键帧的延时。当然，这样做也有它的风险，关键帧的增加会增大视频流的编码码率，或者在码率恒定的情况下会降低关键帧的编码质量，影响关键帧进而影响整个视频流的质量。

「低延时」带来的第二个挑战在于，需尽量缩短流在服务端内的传输路径，动态调整流在服务端内的转发路由。这在传统的树状网络结构下是难以做到的，之前卜赫分享过实时流网络 LiveNet 中流的最优传输路径的选择，这里面不再介绍。

海量终端用户带来的挑战

接下来我们再看看，海量终端用户对于对于实时流处理服务来说意味着什么。

1. 高并发、高在线：大量用户同时直播和访问，意味着同时有大量并发请求需要处理。直播是一种实时性非常强的在线服务，每一个在线用户都需要维持一个长连接，因此对于服务端 IO 和并发能力的要求非常高。此外，每一路用户推流都可能意味着多路不同的转码和处理，处理平台不仅是 IO 密集型服务，也是 CPU 密集型服务。

2. 海量终端用户虽然大都集中在北上广地区，但在庞大的用户基数基础上，长尾用户的覆盖面也非常广泛，因此除了需要在网络上做好规划之外，转码资源的合理利用也需要动态规划和调整。

实时转存带来的挑战

流的实时转存是数据处理平台所需面对的另一个挑战，对于一个企业级直播云服务来说，海量的用户意味着:

1. 出口网络带宽占用的提升。

2. 海量视频文件的存储。

3. 海量的回访意味着大规模的下载分发。

幸好七牛是做云存储服务开始的，可以轻松应对这些海量视频文件的存储和分发需求。

去中心化网络拓扑

了解完实时流转码服务面临的挑战之后，我们再来看一下我们七牛针对这些挑战打造的实时流网络 LiveNet 是如何进行实时转码的。

图中的 5 个实心圈表示 5 个 IDC 机房内的收流、转码和分发节点，一个节点内包含多个部署不同服务的集群，比如收流、分发和不同的转码、处理等功能。图中可以看出，红线表示的数据流 1 从 A 节点收流之后转发到 B 节点，在 B 节点转码之后再分发出去。蓝线表示的数据流 2 从 E 节点收流之后立即进行转码，转码后的流经过 C 节点转发到达 B 节点，再通过 B 节点转发出去。同样的，数据流 3 的转码和流向也类似。至于为什么有些数据流是在靠近推流端的收流节点进行转码，而有些数据流是在靠近播放端的节点进行转码，我们后面会讨论。从这张图可以看出，只要有需要，任意一个 IDC 机房内都可以部署数据处理服务，同时可以在流转发环节的任意一站进行流的处理。这样的灵活性极大的保证了节点故障下的容错度，以及节点计算和 IO 能力的动态调配。

收流、转码节点服务部署

接下来我们再看看下每个收流、转码节点里面服务部署的大致架构怎么样。

首先，在流的入口层有一个网关负责收流，同时会在这里对其是否需要转码，以及转码参数如何等做业务判断。然后，网关将收到的流转发到后端的负载均衡器。对于需要最做处理的流，负载均衡器直接将其分发给后端的业务服务进行处理，如 HLS 切片服务，或者 RTMP 转码服务，以及鉴黄等内容识别服务。处理完成后，处理服务输出相应的 TS 流或者 RTMP 流到下一个路由节点进行后续处理，或者直接由它转发到目标终端用户。

为了最大化资源的利用率，节点上的切片服务或者转码服务可以动态部署，在流量较小的时候不需要部署足够多的服务在那里空转。但为了避免请求过来时候的预热过程导致延迟的增加，每个节点上的服务不完全处于冷却状态，负载均衡器背后至少有一个在线服务可以持续等待请求，请求量增加之后再动态调整服务的副本数。

实时流处理服务的特点

从以上去中心化的网络结构和流实时处理服务部署结构图可以看出，这样的架构更为轻量，同时又能处理海量、高并发的流处理请求，同时由于单个节点成本较低，可以以极低的成本快速的扩容，能够覆盖更为广泛的地域。

其次，由于实时流分发网络的主要职责在于流的分发，是典型的网络 IO 密集型服务，因此节点上的计算能力可能会有浪费。为了满足实时转码的需求，可以在不影响流分发的情况下通过充分利用节点计算能力，做到流的就近处理，以保证转码性能和低延时。同时，分散式的流数据处理服务能够降低录制存储对于上传带宽的要求，充分利用七牛对象云存储的分布式就近上传能力化解单节点带宽瓶颈。

最后，作为实时流处理服务的一大特点之一，我们来解释一下为什么有些数据流是在靠近推流端的收流节点进行转码，而有些数据流是在靠近播放端的节点进行转码。

我们知道，一般来讲，流的目标码率小于原始码率，这样的转码才有意义。因此，对于 RTMP 流来说，在靠近推流端的收流节点进行转码后，后续转发环节可以只转发低码率的目标 RTMP 流。

对于 HLS 流来说，理论上也是目标码率小于原始码率，但 HTTP 是为短连接设计的，内部转发环节效率还是不如 RTMP 流，因此在靠近播放端的节点进行转码是比较好的选择。

新技术下的个性化实时转码架构

从前面转码节点的部署结构图可以看出，我们使用了基于 Docker 容器虚拟化技术的平台来调度转码服务，它可以帮助我们以服务的逻辑单元为单元，隔离不同的处理服务（如切片服务和转码服务），同时又能够充分利用容器虚拟化的灵活性，快速扩容缩容，动态调整所需的物理资源。

除了隔离性和动态扩容缩容之外，它带来了一个非常重要的特性，也即将转码服务模块化之后，即可使用个性化的处理服务替换平台自带的处理服务。例如，可以使用 H.265 编码器替换 H.264 编码器，使用 VP9 替换 VP8，或者同时支持所有这些编码器。

同时，除了支持水印、截图和内容识别等数据处理服务之外，还可以支持其它个性化的数据处理服务。

【Q&A】

Q1：质量监控主要监控哪些内容？

A1：我们会监控很多东西，比如节点的状态和节点内服务的状态，节点状态包括 CPU、内存、网络和服务器句柄数等。同时会对健康节点之间的速度进行定期测试（预留足够的带宽保证测速的时效性）。另外，除了服务端节点质量的监控之外，还会监控直播客户端的网络状况，以及流的质量。

Q2：这种类型的直播视频处理环境，个人想自己搭一个了解相关技术能实现吗？

A2：可以实现。实际上直播是一个包含很多技术的解决方案，幸运的是大部分技术都有开源的实现，比如转码使用 FFmpeg，后端负载均衡使用 Nginx 等，服务资源的隔离和动态调度目前也有比较好的开源容器云平台。

Q3：FFmpeg 这个转码视频质量怎样？

A3：这是一个很大的问题，影响最终视频质量的因素很多，衡量视频质量的维度也很多，分辨率和码率，以及 I 帧频率和 GOP 的大小都可能和视频质量有关，即便是同一个视频流在不同的解码器下解码得到的效果也可能不太一样。我们正在建立一些量化的方法来衡量视频的质量，比如测量 PSNR 值等方式。

Q4：现在的直播平台能支持类似视频会议的播放方式吗 ？

A4：目前的直播一般是为单向传输设计的，因此对互动性比较强的视频会议不太合适。不过在互动社交直播的需求推动下，我们也在尝试使用 WebRTC 技术来提升目前直播的互动性。

Q5：有可操作的 Demo 吗?

A5：我们直播相关的所有 SDK  都在这里 https://github.com/pili-engineering

除了 SDK 之外，我们也做了一些 Demo 可供提前体验：

1. 安卓：

代码：

https://github.com/qiniudemo/qiniu-live-android

App 链接：

http://devtools.qiniu.com/QLive-v1.2.2.apk

2. iOS：

代码：

https://github.com/qiniudemo/qiniu-live-iOS

App 链接：

https://dn-devtools.qbox.me/QNPilePlayDemo-v1.1.0.html

Q6：节点去中心化，IDC 节点之间数据是怎么同步？如 A 节点转码好的视频文件，是怎么被 B 节点或全网其他节点知道的？

A6：这是一个很有价值的问题。我们的架构和传统 CDN 不太一样。A 节点转码好之后，会上报状态到全局调度中心，调度中心将其作为一个源站存在，这样别的节点可以「回源」到它这里，简化了同步的逻辑。