视频平台设计思路大灌顶

抖出干货，一句话， 无论多大规模、多么复杂，任何Web应用都是立足于Request/Reply的通讯模式而解决一个问题，这个问题是，如何把这个Request投送到未知规模的设备集群中进行求解，而后做为Reply返回。这里的Request是逻辑Request，即不仅仅说HTTP Request，或者是SQL Request，而是Business Request。

 

好了，以上这段话能够涵盖目前世界上全部接触到的Web应用，从搜索引擎到短视频应用，涵盖全部系统的后端核心思路。

 

这里具体结合实际状况来展开论述。

 

首先存在几个来自现实世界中的约束

1. 任何的商业都是但愿本身的业务规模能够无暂停的无限增加。
2. 随着业务量的增加，围绕业务逻辑的计算量也在增长。
3. 机器资源老是有限的，包括任何一台设备的IO带宽、CPU、内存、存储等。

对于视频平台的应用来讲，其实能够分2大类

• 视频点播类(VOD)
• 实时直播类(Live)

固然一个网站固然能够提供2种服务，可是在实际世界中，这两个类别存在交集以及不一样的点。

 

这里的业务请求逻辑主要分为两大类

• 内容发布者
• 内容观看者

内容请求者的类别又有两个大类

• 预制做内容上传
• 实时流媒体上传 

预制做内容上传

这个问题能够概括为，如何收集完整的用户内容，提供给后续的处理程序。这里的问题是

• 用户不须要理睬数据的流向，只有一个入口。
• 服务器系统必需要保证待处理的数据的完整性。

这里的解决方案能够采用，准备若干强大的高带宽高速网络传输节点。以用户上传请求做为一个Session，根据后端处理节点的资源空闲程度，从前端直接经过Broker输入到某个后端的某处理节点。后端处理节点的特点是，计算能力能够很强，存储空间很大。当用户全部的内容上传完毕以后，则告知处理节点开始处理，同时处理节点发布Session的处理进度，进而前端获取并推送给用户。当处理完毕以后，转码也完成，能够告知后续节点生成永久性的播放地址，刷新CDN，将新通知发往前端。前端刷新一次，得到更新后的网页，直接点击播放。

 

实时流媒体上传

这个问题能够概括为，如何把用户持续性的数据分配给内部处理程序进行。

• 用户通常来讲有固定的输入点，譬如RTMP的URL。
• 可能须要多协议的支持，譬如WebRTC。 

这里同样须要高带宽、兼容某种协议的网络前端节点，做为固定的资源分配给用户，譬如Twitch，每个注册用户都知晓本身的RTMP URL。每当用户开始发送数据的时候，根据视频带宽和码率的差别，须要从后端分配一个或者共享计算节点进行流媒体的实时编解码。每个计算节点在计算量容许的状况下可能能够执行若干转码工做处理几路视频。每个程序的执行各自独立，在处理的过程当中会不停的向Broker发送每个Session的处理状态，同时直接将处理后的原始媒体数据交给后续的处理环节，在这个过程当中已经生成了MP4片断，而且能够直接发送给CDN。同时前端的播放器直接不停的抓取最新的生成片断用来播放。

 

那么全部的短视频应用其实都是属于第一大类，而近年来兴起的网络直播平台如Twitch则属于1+2类。

 

寥寥几语，已经把这个地方归纳完毕。至于用什么多媒体库如FFmpeg、x264作什么的这些内容，都是具体的执行细节，在此不阐述。由于这些都是具体节点的工做逻辑，能够和架构的设计完全解耦合，成为功能独立的程序，只要稳定执行，就没有问题。至于具体的媒体问题，譬如H26四、H26五、AV1，AAC音频处理等具体媒体相关的处理，仍是HLS或者DASH，本质上这个独立的程序均可以完成。而且这个程序必定能够在不一样的硬件环境下经过媒体片断进行测试，获知系统综合性能，进而优化系统的资源利用率和开销。

 

对于播放来讲，虽然也有两大类

• 观看已经录制的视频内容
• 观看正在直播的视频内容

可是对于播放端来讲，只是一个Request/Reply抓取数据的过程。其实任何的网络视频应用都是不断的抓取片断，丢入本地的缓冲进行播放。不管是MPEG-Dash仍是HLS，本质上都是定义了一组媒体文件序列，由客户端不断的抓取。可是对于播放这一个动做来讲，不管是来自VOD仍是直播的内容，本质上并无任何区别，由于数据都是须要处理后按照次序丢入CDN，客户端经过HLS或者MPEG-DASH的索引进行下载。这个地方的设计主要在于客户端的设计和编码，并没有过多的技术难度。

 

抖音类别的短视频，其实都是第1类。快手视频直播是第2类。又有录播又有直播的算1+2，通常是传统视频平台。有没有纯粹属于第2类的呢，固然也有，并且通常应用场合为B2B，非C2C。