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