这是一个通用的直播模型，大家可能对直播产品的架构已经非常熟悉了。无论是自己去建设，还是使用第三方云服务，它的通用架构都差不多是这样的。一个生产环境可用的直播产品应该包含一个主播方，它是产生视频流的源头。主播播出去的视频，最直接的诉求就是希望被观众观看到，我们称之为播放端。
这是一个看起来非常简单的模型，实际上无论是主播端还是播放端，他们的诉求都不会仅仅是拍摄视频和播放视频这么简单。在这个核心诉求被满足之后，还有很多关键诉求需要被满足。接下来我们再看看，实现一个基于这个简单模型的消费级直播产品还需要做哪些事情。
首先，在主播端，他需要通过一定的设备来拍摄视频，我们称之为采集。然后，将采集的这些视频进行一系列的处理，比如水印、美颜和特效滤镜等处理。最后将处理后的结果视频进行编码压缩成可观看可传输的视频流，再通过网络通道传输出去。
对于一个社交直播产品来说，在观众端，他希望能够实时的看到主播端推过来的视频流，并且和主播以及其他观众产生一定的互动，比如点赞、聊天、弹幕甚至是一些高级道具。这就是播放端所需做的事情。
我们前面说过，主播端不太可能直接和播放端进行连接，在这个过程中还有一个中间环节，帮助主播把能力放大，以满足更多的观众，这就是「直播服务器」端。
从字面上看，实时性的要求是直播场景决定的，它需要保证比较低的延时。那么，为什么需要转码？
2.带宽限制：现在移动3G和4G网络已经非常普及了，他们的速度也相对较快，但还是存在很多弱网环境，比如偏远地区户外，或者大型活动现场。要保证在不同网络条件下都能流畅的在线观看视频，网络自适应的传输不同码率的视频是目前最好的选择。
3.终端设备的多样性还体现在另外一方面，也即它们尺寸的多样性。设备屏幕尺寸的大小决定了在它们上面呈现视频的最佳分辨率，因此为了在不同设备下都能获得最佳用户体验，需要在服务端准备多种不同尺寸的视频流。
其次，直播云服务需要向很多企业级公司提供服务，面临非常大的终端用户量，这是另外一个挑战。
最后，应国家有关部门和业务的需求，直播过程中产生的数据需要存档。在某些业务场景教育直播，直播过程产生的数据具有非常大的存档价值。面对海量的直播流，如何将其实时存储起来是另一个较大的挑战。
我们先来看一下「低延时」带来的挑战。要做到较低的延时，首先意味着转码性能需提升，也即，要么使用性能更好的硬件（比如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，或者同时支持所有这些编码器。
同时，除了支持水印、截图和内容识别等数据处理服务之外，还可以支持其它个性化的数据处理服务。
Q1：质量监控主要监控哪些内容？
A1：我们会监控很多东西，比如节点的状态和节点内服务的状态，节点状态包括CPU、内存、网络和服务器句柄数等。同时会对健康节点之间的速度进行定期测试（预留足够的带宽保证测速的时效性）。另外，除了服务端节点质量的监控之外，还会监控直播客户端的网络状况，以及流的质量。
A2：可以实现。实际上直播是一个包含很多技术的解决方案，幸运的是大部分技术都有开源的实现，比如转码使用FFmpeg，后端负载均衡使用Nginx等，服务资源的隔离和动态调度目前也有比较好的开源容器云平台。
Q3：FFmpeg这个转码视频质量怎样？
A3：这是一个很大的问题，影响最终视频质量的因素很多，衡量视频质量的维度也很多，分辨率和码率，以及I帧频率和GOP的大小都可能和视频质量有关，即便是同一个视频流在不同的解码器下解码得到的效果也可能不太一样。我们正在建立一些量化的方法来衡量视频的质量，比如测量PSNR值等方式。
Q4：现在的直播平台能支持类似视频会议的播放方式吗？
A4：目前的直播一般是为单向传输设计的，因此对互动性比较强的视频会议不太合适。不过在互动社交直播的需求推动下，我们也在尝试使用WebRTC技术来提升目前直播的互动性。
Q5：有可操作的Demo吗
除了SDK之外，我们也做了一些Demo可供提前体验：
1.安卓：
代码：
App链接：
2.iOS：
Q6：节点去中心化，IDC节点之间数据是怎么同步？如A节点转码好的视频文件，是怎么被B节点或全网其他节点知道的？
A6：这是一个很有价值的问题。我们的架构和传统CDN不太一样。A节点转码好之后，会上报状态到全局调度中心，调度中心将其作为一个源站存在，这样别的节点可以「回源」到它这里，简化了同步的逻辑。