视频直播框架

从直播数据流、CDN分发、消息队列、业务逻辑、交互功能、体验优化、业务数据/性能数据统计监控、场景化、平台架构等9大方面简单列举一个真实直播应用所涉及到的东西。

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

历经了音视频采集→视频前处理（美颜滤镜、特效等）→音频前处理（回波消除、降噪等）→音视频编码→推流→流媒体服务器（转码、转封装、录制等诸多云端功能）→拉流→解码→播放 等一系列流程。

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

❶ 推流端框架： 
采集：AVFoundation 
滤镜：GPUImage 
编码：FFmpeg/X264/Speex 
推流：Librtmp

❷ 流媒体服务器： 
nginx-rtmp 
SRS 
BMS

❸ 播放端： 
解码：FFmpeg/X264 
播放：ijkplayer/video.js/flv.js

2、CDN分发 
上面所述的直播流中，虽然能从推流跑到播流，但如果观看者数量众多，单靠堆砌流媒体服务器是很难支撑的，所以真实的直播应用都有CDN分发这一环节，正因为如此之前讲流媒体系统组成中，我们也将CDN纳入了大型流媒体系统中必要的组成部分。 
除了极少应用有能力自建部分CDN节点，大部分直播APP会采用成熟的第三方商用CDN。直播CDN之前讲过，是在标准的CDN架构之上，必须依靠独立的流媒体服务器设备组进行流式协议的分发，完整的直播CDN系统主要包括流媒体服务器（Nginx/BMS/SRS等）、负载均衡、路由重定向（DNS/HTTP DNS等）、防盗链、缓存等。

我们用DIG命令去追溯ME平台分享页面的地址，可看出ME分享页面使用的CDN是YY自建CDN。 
3、消息队列 
消息队列指的是直播APP中众多基于消息队列的异步通信机制，主要包括账号/关系链、消息/提醒/通知/评论/弹幕/点赞/虚拟礼品、红包、商品/支付等等。消息本身不难做，但要保证一个APP中大规模、高并发、多类型的消息队列的高稳定性也是有不小的难度，比如我们经常听说的一场直播中弹幕超超1亿条这种。所以消息队列服务，部分直播APP也会采用第三方服务。 
下图为ME平台中消息系统：

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

5、交互功能 
直播过程中，主播与观众，观众与观众，观众与直播内容之间的交互统称为交互功能，这里面包括连麦这样的流媒体技术互动，大型聊天室这样的消息互动功能，实时调查问卷这样的业务互动，也包括商品识别等基于内容的互动。 
 
6、体验优化 
我们在看直播的时候都有低延迟、高清流畅、极速秒开等基本的体验诉求。为了满足这些观看体验要求，就需要流媒体技术在各个细节点上做针对性优化。这里面我们需要知道，哪怕是我们视为理应的如延迟降低1秒，流畅度提升5个百分点，首屏加载控制到1秒内，其背后都是技术提供商大量的方案论证与研发投入，这绝不是简单用开源组件把流程跑起来那么简单。

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

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

8、场景化 
场景化指的是对不同垂直直播特点而提供的特有功能组成的针对性解决方案。 
另外，还有如大型活动直播需要云端导播，多平台发布等。