总结：从一个直播APP看流媒体系统的应用

通过第一篇流媒体原理和第二篇对流媒体系统的描述，我们大概能了解流媒体技术中的基本概念，以及一个大型流媒体系统中大概有哪些部分组成。

本篇文章我们从一个实际应用来对照着看前面所讲内容到底是如何应用到一个直播APP中的。今天我们拿欢聚旗下的ME平台来举例，这款应用于今年2月上线，在直播应用中并不强势，不过它是最早加入连麦功能的平台之一。

所有直播平台，不论是PC上的游戏直播、秀场，还是映客类移动直播，功能都大同小异。主线功能就是下面三张图：

作为观众进入应用看到列表，从众多主播中选一个进入房间观看直播：

作为主播发起直播，别人重复上面的流程：

以上只是直播APP最基本的功能，一个真实的直播平台背后所涉及的东西要比我们所看到的复杂得多。下面从直播数据流、CDN分发、消息队列、业务逻辑、交互功能、体验优化、业务数据/性能数据统计监控、场景化、平台架构等9大方面简单列举一个真实直播应用所涉及到的东西。这里面有流媒体技术相关的，我们从这里面着重讲流媒体原理和流媒体系统中讲的点予以对照理解，也有和流媒体技术本身不相关的，这些方面只需知道一个直播APP还会用到这些即可。

一个完整的直播流程即主播发起直播→观看进入房间观看→主播结束直播，我们能看见的就是上面图中给出那样，点几个按钮即可。然而看不见的背后是下面这张图给出的直播流在数秒内的历程。

这个流程是直播APP最核心也是研发难度最大的部分，包含了我们之前讲流媒体系统组成部分中最重要三大环节，直播的数据流在这里面历经了音视频采集→视频前处理（美颜滤镜、特效等）→音频前处理（回波消除、降噪等）→音视频编码→推流→流媒体服务器（转码、转封装、录制等诸多云端功能）→拉流→解码→播放 等一系列流程。

由于技术门槛高，需投入研发资源和时间成本极高，通常这部分内容直播APP都不自研，而是托管给观止云、又拍云这样的直播云服务平台。如果是自研一般也在端上发力，之前文章给出了众多研发这些环节中经常会用到的一些开发框架：

❶  推流端框架：

采集：AVFoundation

滤镜：GPUImage

编码：FFmpeg/X264/Speex

推流：Librtmp

❷  流媒体服务器：

nginx-rtmp

SRS

BMS    

❸  播放端：

解码：FFmpeg/X264

播放：ijkplayer/video.js/flv.js

上面所述的直播流中，虽然能从推流跑到播流，但如果观看者数量众多，单靠堆砌流媒体服务器是很难支撑的，所以真实的直播应用都有CDN分发这一环节，正因为如此之前讲流媒体系统组成中，我们也将CDN纳入了大型流媒体系统中必要的组成部分。

除了极少应用有能力自建部分CDN节点，大部分直播APP会采用成熟的第三方商用CDN。直播CDN之前讲过，是在标准的CDN架构之上，必须依靠独立的流媒体服务器设备组进行流式协议的分发，完整的直播CDN系统主要包括流媒体服务器（Nginx/BMS/SRS等）、负载均衡、路由重定向（DNS/HTTP DNS等）、防盗链、缓存等。

我们用DIG命令去追溯ME平台分享页面的地址，可看出ME分享页面使用的CDN是YY自建CDN。

DIG映客地址，可看出映客分享页面部分使用的CDN是网宿CDN。

消息队列指的是直播APP中众多基于消息队列的异步通信机制，主要包括账号/关系链、消息/提醒/通知/评论/弹幕/点赞/虚拟礼品、红包、商品/支付等等。消息本身不难做，但要保证一个APP中大规模、高并发、多类型的消息队列的高稳定性也是有不小的难度，比如我们经常听说的一场直播中弹幕超超1亿条这种。所以消息队列服务，部分直播APP也会采用第三方服务。

下图为ME平台中消息系统：

这层主要是直播APP自身的业务结构，主要包括房间逻辑、用户/管理员逻辑、荣誉体系设计等。

直播过程中，主播与观众，观众与观众，观众与直播内容之间的交互统称为交互功能，这里面包括连麦这样的流媒体技术互动，大型聊天室这样的消息互动功能，实时调查问卷这样的业务互动，也包括商品识别等基于内容的互动。

我们在看直播的时候都有低延迟、高清流畅、极速秒开等基本的体验诉求。为了满足这些观看体验要求，就需要流媒体技术在各个细节点上做针对性优化。这里面我们需要知道，哪怕是我们视为理应的如延迟降低1秒，流畅度提升5个百分点，首屏加载控制到1秒内，其背后都是技术提供商大量的方案论证与研发投入，这绝不是简单用开源组件把流程跑起来那么简单。

之前观止云，以及各友商的流媒体技术团队几乎把其中每一个优化点都无私的分享了，此处就不搬砖了。

运营一个大型直播APP，其中每天都会积累大量的运营数据，通过采集、分析大量运营数据，我们能从中抽象出指导产品运营的方向。运营数据一般需要APP在播放器中直接采集原始数据，指标项如观看人数、观看人次、观看总时长、人均观看时长，人均观看直播流、跳出、观看路径等等指标，以及他们在多维度、多层面的交叉统计。

直播流程繁复，是个特别容易出故障的业务。要排查、处理直播故障，我们需要从整个直播数据流中的各个环节去抓取几十项性能数据，并从这海量性能数据中不断优化产品的技术架构。性能数据可自研，也可采用第三方性能监测服务，指标项如建连时长（DNS，TCP，首包等）、首次等待时长、卡顿率、卡顿次数、连续卡顿事件、人均卡顿等等。

另外，还有如大型活动直播需要云端导播，多平台发布等。

以上8点都是以ME为例对直播APP中独立的模块列举，虽然说这些模块基本都有开源方案或者成熟的第三方商用服务，但要将这些模块或系统完美的整合起来，就要求有极高的平台架构设计，做到高承载、高稳定、高灵活、易扩展。这里面包括就包括我们在第一篇讲流媒体涉及技术中提及的基于云架构的计算、数据库、网络、存储、消息队列等等云计算技术应用。