目录

想打造一个在线视频服务，首先要解答的问题可能就是如何选择音视频方案，下面将依次阐述方案选取的原则，列举一些点播服务面临的主要技术挑战，以及讨论直播和CDN方案。

由于音视频技术的特性，视频处理的环节和播放环节相互影响较大，在线视频公司搭建端到端的音视频系统时，在准确评估用户需求的基础上，应合理地划分处理环节，选择合适的方案并进行通盘考量。

1、直接集成现有视频云服务

下面是腾讯云的视频点播方案

视频云都支持将内容上传、管理、转码、分发至客户端SDK、广告自动销售和插入等功能，在监控报警服务上也较完备，研发团队只需将对应的SDK集成在网页或客户端程序中，并实现浏览、选择、调用SDK等操作即可完成全部功能，工程师可以集中精力在登录、支付、网页和内容导入等独有部分的开发，视频部分最快仅需耗费数周级别的工期。

2、半自制的端到端方案

例如：

  • 租用IDC机房的主机或使用AWS的EC2虚机，部署内容管理系统
  • 在转码环节选用AWS的Media Convert服务，分发时选择自行部署的Wowza服务器
  • 分发时选择自行部署的Wowza服务器
  • CDN则接入Akamai或Level3
  • 客户端基于JWPlayer、Exoplayer等开源方案
  • 监控和部署需要较多的自定义开发，若在某一环节上使用多家不同供应商，还需对流量进行调控。

一则避免对供应商的路径绑定，且能货比三家，或增加谈判砝码，或汰弱留强；

三则建立研发团队对服务整体性的理解，为进一步优化和扩张奠定基础。

3、完全的自行研发模式

首先是厘清公司战略，公司的发展方向是长视频为主还是短视频为主？是点播业务还是涉及直播？是否考虑涉足游戏直播、秀场直播？

其次是划分处理环节，大致需要内容导入、审查和管理，视频存储、转码和分发，CDN，客户端几个基础的方面，对整体QOS的衡量往往独立拆分出来，形成独立的数据团队。上述不同环节虽然相对独立，其方案又互相影响。例如，若决定以MPEG-DASH作为流媒体协议，在机顶盒客户端上引入Chromium支持可能是经济划算的选择。

点播服务设计挑战

存储挑战

在线视频公司的内容存储是一大挑战，与其他数据不同，单独的花絮、垫片、视频广告或短节目需要以数MB到数百MB不等，高清长片的文件大小往往以GB计，一份完整视频库动辄数十PB乃至EB级的存储不论在源数据中心还是CDN边缘节点上，都理应获得特别对待。

亿级以下的长视频存储只需要简单的主从架构就可以处理，由主节点存储元数据而从节点负责文件的实际读写，即使数量亿级以上（譬如Netflix宣称其在视频文件数目在数十亿级别，YouTube很可能还超过此数），或许应部署主节点集群进行文件管理和路由管理，其中的技术重点在于冗余备份机制的设计。

作为很可能是公司最重要资产的视频，如果发生丢失、混乱或暂停服务将导致覆灭级的灾难，故而其服务可靠性和备份安全性理应获得特别对待，首要的需求将是保障视频文件以多副本状态存在，且分布于不同的数据中心（倘在AWS应保证不同的AZ或Region）。同理，视频文件的元数据（即主节点）包括数据库亦应分处于不同数据中心，且数据库应考虑具备冷拷贝。存储系统需要对删除操作有详细记录，并在一段时间内可完全恢复，下面给出一份示意的设计图（如下图）。由于视频文件较少改动，接口无论选择对象存储或者文件系统都是常见方案。

（跨数据中心文件存储服务示意）

由于上亿或数十乃至数百亿的文件，其元数据的索引和访问消耗很大，令本就繁重的硬盘访问雪上加霜，业界对小文件存储给出的方案可以参考TFS和SeaweedFS，其主要思想是利用单独的数据库而非文件系统存储元数据，从而使用大文件分割存储小文件，降低单一系统中的文件数量。

对视频公司而言，无疑在小文件存储上也有类似痛点，鉴于缩略图之间的顺序关系并未被充分考虑，其存储和访问效率或许还能够进一步提高，假设从视频中产生了一系列缩略图，在许多场合下，它们也将被按同样的顺序批量读取，此时合并读取请求可以降低IOPS，而合并多个小文件为少数大文件返回也能有效降低网络响应时间。（视频缩略图是大多数人与视频进行交互时首先看到的内容。缩略图也是搜索结果中显示的内容。缩略图在包含很多媒体文件的库中特别有用，因为它们为查看者提供视频内容的预览。）

存储服务的瓶颈通常在硬盘而非网卡，因为较新的服务器容易成为访问热点，在设计时提供集群的再平衡功能是简单有效的选择。与存储相对应的挑战在于计算，不论是视频转码，还是图像处理，都既是I/O密集型，也是计算密集型应用。

另有一些公司则独辟蹊径，采用定制甚至自研的存储服务器，乃至专用的http服务器和路由器组成“存储局域网”，此时转码任务需要专门高计算能力的集群完成，这种方案的优点是对存储和转码方案的容量可以分别规划，但需要着意关注存储和计算集群之间的通信连接，不令其成为系统的瓶颈。

考虑到算法在视频质量优化中的核心位置，播放端的设计可能需要打破以往固定、嵌套的模式，面向算法进行设计，例如设计数据通路、抽象决策行为、设立上下文传递机制等，将可能提供最大的灵活性和经济性。

直播服务架构设计

最后，是个性化定制的播放体验（包括广告体验）。在线视频公司常常弱化频道的概念，将直播节目的组织呈现围绕用户需求设计，例如在一场NBA直播的前后提供推荐观看的花絮短片，为比赛提供回放、时移、录像等功能，对直播中的广告根据个人好恶进行替换等。

谈及可靠性与备份，除直播流冗余备份外，DASH或HLS等基于HTTP的协议将天然具备优势，因为所有流媒体分发行为都可以被视为下载，服务端会话中断、时序错乱和抖动均可以稍多的缓冲为代价避免。

CDN方案选择

线视频公司使用一家或多家第三方CDN服务是常见的选择，可以免去部署和管理大量分布在各地的节点的负担。然而当规模扩大时，自建CDN将是在线视频公司的必由之路。

首先，自建CDN可以完全按需设立节点和服务容量。其次，能够与视频公司统一资源分配目标并实时获取整条播放链路上流媒体分发的运行状态。最后，大量基于大数据进行的，对服务质量精细地优化（例如算法决策、分发调度、缓存调配等）仰仗于视频公司对CDN的拓扑以及所有节点上的服务器有完全的控制能力。上面的Akamai架构图中描述了常见的CDN搭建方式。

Netflix因为很早就欲图扩展全球业务，打造了其独树一帜的名为Open Connect的CDN架构，其主要概念基于OCA，即Open Connect Appliance。WSNetflix在各类符合条件的机房或数据中心中安装OCA，服务器硬件由Netflix提供而ISP提供电源、机架和网络等部件。

下面是OCA服务的运行过程：

Netflix定义Open Connect标准的主要优势在于标准化第三方提供的服务，得以快速地在各个国家和地区部署，同时享有自建CDN的主要好处即优化整体网络分发的能力。在此架构下，将所有节点的服务器进行虚拟化，部署视频缓存甚至部分服务、数据库都将成为可能，而由于全部OCA都处于完全可控状态，可以轻易地根据BGP路径或地理位置、OCA本身属性等，分层或改变拓扑，构建出类似传统CDN的多级架构，令整体成本最低。

由Netflix的实践可以推断，视频CDN的发展趋势在向云化和智能化发展，具体体现在网络拓扑方面和在算法调度方面的进化。

于网络拓扑方面，底层的节点管理从树型结构正在过渡到网状结构。在流媒体分发路径的设计上，为C端直播、视频会议、连麦等需求，设立边缘融合节点以对视频或音频流进行实时处理，甚至任意节点均可承担融合处理任务，此时分发路径将不再固定，且允许动态变化。

拓扑的进化得益于调度管理方面的进化，于算法调度方面，综合考虑DNS、ECS和HTTP。

DNS请求的DNS资源调度，结合CTR点击预估、峰值流量预测、用户QOS反馈进行内容缓存预热调度、流量调度、播放器算法选择等都将成为系统运转的核心。

最后，CDN不仅提供静态下载和简单的边缘计算，急需解决的问题还有大体量下为了得到最快的响应速度，如何将核心的动态服务部署到边缘服务器，并保证数据读写的一致性，这或许需要新的编程模型。