以【优酷】为例，浅谈电信级多媒体运营平台的实现方式（1）

当前，流媒体视频技术已经应用到了各个领域，像 Youtube、优酷、爱奇艺、腾讯视频、抖音、花椒直播、一直播、学而思网校、TutorABC等等，这些不同行业的视频运营平台均获得了极大成功，然而这些平台底层基础架构都离不开视频发布技术，也是这些平台可以成功运营的核心技术支撑。

下面根据我在优酷团队多年来的产品开发经验，谈一下自己的总体感受，对未来在视频应用领域的创业者也许会有一些帮助。

首先，是底层技术架构

视频发布平台的底层基础架构一定要设计合理，这里需要考虑到如下特性：

稳定性、高性能、易扩展、标准开放、兼容性、技术前瞻、容灾机制。

稳定性：

在视频流媒体发布平台中，主要的技术环节包括视频编码、视频预处理（去隔行、降噪、视频缩放、水印叠加、视频过滤、去黑边、画面增强、关键帧提取、人脸美颜、动作识别）、流媒体多协议发布、视频转码、大视频上传、多终端解码、实时消息服务，每一个技术环节的技术实现都关系着整个应用平台的运行效率。

在这些关键的技术环节实现中，主要依赖于软件层面的技术实现。这些关键技术，可以通过多种编码语言去实现，可以用C++，C#, Java，GO等。从实现的难易程度上来说，C++实现是最难的，Java的实现最简单；从程序的稳定性和性能上来说，C++语言是稳定性和性能最高的。因此，在优酷平台的开发实现上，我们在关键环节采用的都是C++语言实现的。

高性能：

对于运营平台来说，软件的性能至关重要，因为它直接关系到平台大规模部署运营时的运营成本。

因此，在核心技术环节的实现上，我们必须要考虑到性能这一关键的技术指标。

比如，在做流媒体服务器开发时，我们曾经选用Java语言去实现，团队中的一个小组用了4个月时间就写了一款完整的流媒体服务器，但是部署上线后发现，选用Dell R720 （双志强E5-2650CPU+32GB内存）这种配置的服务器只能支撑500并发用户访问，而且CPU占率用达到了90%，内存资源占用率达到了70%，Java虚拟机的内存垃圾回收机制存在严重问题。

相反，团队中的另外一个小组采用C++语言花了半年多时间（之前已经有基础功能实现）实现的流媒体服务器，在同样的硬件配置环境下可以支撑2000并发用户访问，CPU占率用为40%，内存资源占用率为20%，说明软件层面仍有很大的优化空间。

再比如，团队在开发大文件上传服务器时，其中一个小组基于Github上的开源PHP上传模块进行开发，服务器端采用Nginx，服务器同样采用Dell R720 （双志强E5-2650CPU+32GB内存）这种配置，测试后发现单台服务器最高支持200用户同时上传，并且无法做到4GB以上的大文件浏览器端无插件上传和断点续传。

另外一个小组采用C++语言花了5个月时间开发了一款上传服务器，基于异步I/O架构实现，同样的服务器硬件配置，在不考虑带宽瓶颈的情况下，单台服务器支持2万并发用户上传，并且采用HTML5浏览器可以支持4GB以上的大文件上传和断点续传，同时不需要浏览器端安装任何插件。

再比如：在视频转码服务器的实现上，团队中的一个小组直接采用开源的FFMPEG来实现视频转码功能，由于FFMPEG的软件功能已经很完整，这个小组花了半年时间就实现了这个转码服务器模块，但是项目上线运行后发现，这款转码服务器非常不稳定，经常出现各种奇怪的崩溃、死锁事件，而且用以上配置的DELL R720服务器，转码1080P的高清视频只能达到3倍速的转码效率，后来经过不断优化，最终也仅仅达到5倍速的转码效率，这种情况持续了2年多时间，因此在平台的快速扩张阶段，平台部署了2000台转码服务器，和流媒体服务器的部署数量相当，。

另外一个小组基于C++语言自主开发的视频转码技术，基于同样配置的DELL R720服务器，外加了2块Nvidia Tesla视频卡，实现了1080P H.264的20倍速转码，视频转码效率得到了极大提升。

还有，在当前的视频服务平台中，实时消息服务也是一项核心的功能模块，主要用于直播时的文字互动、视频播放时的实时弹幕发布，由于这种交互式消息服务具有高并发的特点，比如在优酷的平台上当有1万并发用户在线时，其它每当一个用户发布一条消息，服务器端都需要将其同时转发给1万个终端，可想而知，当每秒有10个用户同时发布消息时，服务器端就需要每秒处理10万个消息。对于这种应用，业界通常采用Node.js作为服务器端，然后客户端浏览器通过WebSocket与服务器端建立长连接实现。然而，采用这种方式测试后发现，Node.js服务器最多只能处理2000个并发连接，因此导致优酷这种动辄数十万并发的应用平台，需要部署大量的消息服务器，投入实在太大。

为了解决这个难题，团队专门成立了一个研发小组，请来了几万高手专门研究这个消息服务平台，研发小组先后研究了Kafka，它是由Apache软件基金会开发的一个开源流处理平台，采用Scala和Java编写。Kafka是一种高吞吐量的分布式发布订阅消息系统，它是通过Hadoop的并行加载机制来统一线上和离线的消息处理，也是为了通过集群来提供实时的消息服务。

与其它方案相比较而言，Kafka的确是一个现实可行的应用方案，而且它实现了集群式部署应用。然而，基于Kafka的消息服务平台上线后，仍然暴露了很多弊端，主要体现在单个节点的性能瓶上面。这种系统虽然经过一些技术团队的改进和优化有了一定的性能提升，比如当前大家熟知的Bilibili团队改造的GOIM系统（http://www.zhiboshequ.com/news/595.html

），但是仍然无法解决这个开源项目的固有缺陷。

Kafka的缺陷：由于kafka是基于Scala和Java语言开发实现的，注定定它必须依赖于Java虚拟机环境运行，这又击中了Java虚拟机固有的弱点，那就是并发处理性能无法提升，无论你写的代码如何优化都无能为力。由于Java是解释型语言，首先它由编译器编译成.class类型的文件，这个是java自己的文件类型，然后再通过虚拟机(JVM)从.class文件中读一行解释执行一行；它不像C、C++ 那样，经过一次编译之后便可以由操作系统直接执行，因此基于Java语言开发的系统永远都比C、C++开发的程序在效率上相差几个数量级。

因此，公司还是基于运营成本的考虑，不得已再次组建研发团队对这方面技术进行技术攻关。

依托于公司中那几位从事了十多年C语言开发的技术高手助力（他们曾经开发了公司使用至今的高性能流媒体服务器和高性能上传服务器），这个消息服务器系统有重新从零开始研发，架构上仍然采用著名的异步I/O模型，支持在Windows和Linux平台是编译运行，解决了跨平台的问题，客户端与服务器端通信模式仍然采用长连接的WebSocket协议，该系统实现后，经过实验室环境测试，单台Dell  R720服务器可以支撑五十万并发的连接，而且，文字消息的长度无限制，不像很多其它系统要求消息长度必须小于256字节。

易扩展：

对于这种高并发应用平台来说，平台的扩展性至关重要。由于单台服务器和单个节点集群支持的并发用户都有上限，平台必须支持多服务器负载均衡和多节点分布式部署，并且提供CDN（Content Delivery Network）功能，这样才能实现覆盖全国的大并发应用。

标准开放：

既然是基于互联网的应用，就必须遵循国际标准化组织所制定的相应标准，包括视音频编解码标准（H.264/H.265/ AAC），视频封装标准（MP4/TS/FLV），流媒体协议标准（HTTP-FLV、HLS、RTMP、DASH、RTSP、UDP）。

兼容性：

兼容性主要体现在如下几个方面：

1. 服务器平台的兼容性

为了降低运营成本和减少对特定服务器平台的依赖，服务器端软件平台需要兼容Linux和Windows操作系统平台，并且支持x86架构的CPU和ARM架构的CPU运行。

2. 客户端浏览器的兼容性

对于这种电信运营级的平台，你无法要求终端用户必须使用哪种浏览器，因此必须兼容当前主流的大部分浏览器内核，包括市场占有率最高的Chromimu内核浏览器（Chrome、Firefox、Opera、360极速浏览器、UC浏览器），IE内核浏览器，Safari浏览器，QQ浏览器、微信浏览器、遨游浏览器等。因此，平台采用的客户端播放器必须兼容这些主流的浏览器，当前的技术变革趋势是采用兼容HTML5标准的播放器，无需用户进行插件的下载和安装，并且对这些浏览器均能很好地适配。

3. 客户端解码能力的兼容性

这方面要求服务器端平台在输出内容时要充分考虑到多种终端的解码能力，比如网络电视机、PC、主流的Android手机、苹果手机等。

4. 流媒体传输协议的兼容性

由于不同的终端设备所能支持的传输协议不同，服务器在向客户端传送数据时，需要能够自动检测终端设备类型，并采用终端可以接受的传输协议来发送数据。

比如，苹果移动终端只能支持HLS协议传输流媒体数据，PC终端在IE8以下版本的浏览器环境下只能支持RTMP协议调用Flash播放器来播放，Webkit内核的浏览器可以支持HTTP-FLV、HLS和DASH协议，因此要求服务器端平台能够支持所有这些主流协议，并且与终端自动适配。

其次，是网络层架构

对于这种大规模运营级平台来讲，平台的网络层架构也至关重要，因为不合理的网络层架构会带来更高的运营成本和平台维护成本。

举例来说，优酷平台的运营团队在北京，如果将平台所有的业务服务器都放在北京本地的IDC机房，那么就会存在服务器托管成本高、带宽成本高、其它省份用户体验差等众多弊端。因此，在平台建设初期，运营团队就考虑到了这个问题，结合国内三大电信运营商三足鼎立，互联互通性差的现实，我们设计了分布式网络架构模式，平台建立之初，将源站放在北京的BGP机房，在Chinanet的八大核心节点分别部署二级节点服务器群。随着后期用户量的快速增长，已有的八大节点已经无法满足用户需要，特别是华北、华东和华南几个区域的用户量增长很快，运营团队又在此基础上对平台进行扩容和升级，在用户量大的省份的省会城市部署了三级节点服务器，再后来，我们将服务器节点部署到了经济发达省份的二线城市。

而且，我们在三大电信运营商的IDC机房中均有部署，这在很大程度上解决了用户收视体验差，运营成本高的问题。这些服务节点最终组成了一个星形与树形拓扑结构想结合的CDN内容分发网络，如下图所示。

 

 

再次，是内容存储架构

众所周知，像优酷这种级别的运营平台，节目数量非常庞大，每个互联网节点的内容存储成本很高。我们在中心节点部署了大容量的磁盘存储阵列，但是如果在其它每个节点都部署同样的磁盘存储阵列，运营成本将会非常高昂。

为了解决这个问题，我们对平台的内容存储模式进行了改造，将内容存储服务器通过分布式方式进行部署。在中心节点部署磁盘阵列，这里存储有整个平台的完整内容镜像。然后，我们在每个区域节点不再部署磁盘阵列，而是采用服务器上挂载十二块大容量硬盘方式实现，这将极大地节省了全国数千台服务器的内容存储成本。

但是，对于优酷这种体量的内容发布平台来说，服务器本地磁盘的存储能力还是非常有限，那么怎么办呢？经过团队的反复验证，我们发现在平台上被大多数用户访问的节目数量在1万个左右，这样的一个数据量本地服务器存储容量基本上可以应付。因此，我们通过内容热度排行统计系统给出的结果，将1万个热度最高的节目分发到每个节点的流媒体服务器端，同时将热度排行在1万以上的全部删除，当有用户需要点播收看一些冷门的节目时，我们通过平台的调度系统将用户引导到源站节点服务器来为其提供服务，这样既满足了大部分用户需求，也满足了个人用户需求，而且节点服务器的存储成本得到了有效控制。