大家好，我叫薛宁，非常荣幸能参加今天的会议。我目前就职于映客，主要负责映客直播CDN调度和服务器优化方面的工作，我今天主要和大家分享下映客直播在调度方面的一些实践经验。

大家好，我叫薛宁，非常荣幸能参加今天的会议。我目前就职于映客，主要负责映客直播CDN调度和服务器优化方面的工作，我今天主要和大家分享下映客直播在调度方面的一些实践经验。

今天的分享将从以下3个方面进行展开

直播与CDN

CDN的全称为内容分发网络，主要用来解决由于网络带宽小、用户访问量大、网点分布不均匀等导致用户访问网站速度慢的问题。其实现是通过在现有的网络中，增加一层新的网络架构，将网站的内容发布到离用户最近的网络节点上，这样用户可以就近获取所需的内容，解决网络拥塞、访问延迟高的问题，提升用户体验。目前映客的直播系统也是基于cdn构建。　　

经典使用场景如图所示，内容提供商通过主动预热或者被动更新的方式，把内容缓存在CDN上，当用户访问资源时，从就近CDN节点上获取到所需资源，平常大家浏览网页和和观看网络视频资源，大部分都是通过以这种方式。

直播CDN与通常的CDN使用方式上稍微有点不同，主播开始进行直播，向智能DNS发送解析请求； 智能DNS返回最优CDN节点IP地址； 主播端采集音视频数据，发送给CDN节点，CDN节点进行缓存等处理； 观众端要观看此主播的视频，向智能DNS发送解析请求； 智能DNS返回最优CDN节点IP地址； 观众端向CDN节点请求音视频数据； CDN节点通过内部网络同步其他节点的音视频数据；之后将音视频数据发送给观众端；

可以看出移动直播的交互过程比传统CDN更为复杂一些，在视频内容上也更具实时性，对延迟非常敏感，CDN内部并不能做太长时间的内容缓存。主播方上行网络到CDN节点网络状况的不确定性，观众在观看视频过程中，更容易遇到视频打不开、黑屏、观看直播卡顿、延迟大，观看直播音画不同步、音画丢失、花屏等现象。

排除观众和主播网络自身问题，问题更可能出现在与cdn的交互上，直播调度的目标就是在cdn的基础上来提升用户使用直播的用户体验。

　映客直播调度系统

在讲诉调度系统之前，先介绍下映客的流媒体场景，这是映客目前的流媒体的系统组成框图。

主播发起视频直播后，会选取一个CDN或私有媒体云作为推流方式，把采集的视频数据推到CDN上，为保证整个系统的稳定性，我们使用多家cdn，在CDN与CDN会做视频互推，映客为支持视频审核和视频录播等功能会拉一路流到映客服务器内部。普通cdn比较难以支持更低延迟的视频直播比如连麦互动，所以我们内部也建立了私有媒体云，用于支持更低延迟的视频直播。

在当前的媒体系统基础上，我们设计了cdn调度系统，整个系统由日志收集平台、直播调度平台、数据监控平台、日志处理平台4个部分组成，整个系统中日志占了比较大的比重，我们整个系统以正是以日志数据为驱动的。

日志收集系统对整个媒体系统做全链路的日志数据收集，包括端上的日志、CDN日志、媒体中心日志、媒体云日志。

端上的日志由客户端或者网页端上报到埋点服务器，这一部分日志也是我们整个日志收集系统最重要的一部分，为保障客户端的日志能稳定上报，我们把日志系统部署在多个多线的BGP机房、同时在客户端层面也做了比较多的上报容错机制，端上的日志收集包含开停播事件、卡顿、速率、延迟等相关的数据。

CDN日志由CDN厂商的提供，日志收集平台会通过轮询方式去CDN平台拉取，这部分数据包含当前在CDN上直播数、每路直播的上行速率、帧率、视频数据丢弃状况、流量等相关数据。

媒体云会实时上报媒体服务器的数据，这部分数据和端上的日志类似包含开停播时间、速率、帧率、延迟等相关的数据。

媒体中心相当于客户端，会拉取所有的直播到媒体中心的服务器上，媒体中心会采集到每一路直播的下行相关数据汇报到日志收集系统。

我们通过日志采集系统获取到大量的日志，这些日志统一交由内部kafka消息队列，我们对收集的日志做了3类处理：实时分析、准实时分析和大数据分析系统

实时分析会实时分析统计每个主播和用户的上下行数据，某个主播或者用户出现卡顿了，我们在10s之内就能知道，针对这种情况，可以马上就能够通知实时调度平台采取策略。实时分析系统从实现和执行方式上全部采用基于内存的计算模型实现。

第二类数据通过开源的elasticsearch实现，端上和媒体中心日志在经过格式化和数据提取后会准实时存储到ES中，ES本身也即是一个存储系统也是一个搜索引擎，调度系统的监控平台会会从ES里面读取处理后的数据做一些粗粒度的监控，比如当前多少用户有推流日志等，ES的主要功能是提供日志检索功能，通过ES可以很快的查到某个用户的实时推拉流情况。

最后一类数据是借用大数据部门的spark-hive集群做数据处理，hive集群提供原始日志存储，可以服务于内部数据分析和报表系统，也支持详细的日志检索功能；spark会对数据按照一定的指标和维度做基于时间窗口的聚合，聚合后的数据输出到报警中心。

spark做聚合计算的时候分别从主播和观众方主做5个维度的指标分析。拉流端卡顿率、首帧时间、播放延迟、成功率、有效内容比，卡顿率定义为用户的卡顿的时间比例用来衡量观众观看直播的流畅度；首帧时间也即从打开直播看到的第一个视频画面消耗的时间，如果时间小于1秒大家经常说的秒开，用来衡量加载时间；播放延迟是指观众方观看到画面与主播产生的画面之间的延迟时间，用来衡量CDN分发过程中产生的延迟；成功率也即播放直播的成功率，定义为若干秒没有看到画面的的比例；有效内容比定义为用户观看到的直播与播放时间的比例，由于卡顿或者其他因素，视频在播放过程中会出现视频帧丢弃等现象，这个指标用来衡量丢弃的比例。推流端成功率、有效内容比、编码速率、网络速率和失败时长，成功率和有效内容比和观看方的类似，网络速率直接反映了主播的网络速率，由于播放器的码率自适应，我们加入了编码速率来作为网络速率的参考值，失败时长定义为推流失败的时间可以直接反应出主播推流的失败影响的时间。

基于这些指标，我们对数据做多维度聚合统计，全网维度、CDN厂商维度比较好理解，由于映客同时直播并发量比较大，单家CDN的单域名难以承载并发的直播数量，我们在一家CDN也会存在使用多个域名。

此外我们还会以CDN的节点的维度做数据统计，有时CDN是好的，可能某些节点有故障；映客除了普通直播还会有游戏直播合作厂商的直播，直播类型也是我们聚合的一个维度。有时候有一些大型合作活动，我们会对这些房间做特殊的数据聚合；

我们经常会遇到一些与设备类型相关的故障，同一app在不同机型上可能存在不同的表现，我们对设备类型也做了聚合统计。

地区+运营商作为业内衡量cdn的数据必备的维度，这两个维度也是我们的数据聚合的一个点。

基于各个维度的数据，我们做了一套监控报警的可视化系统，监控指标有很多项，这里主要列出重要的几点，监控的指标会从上面的多个维度上做统计，卡顿率定义为：当前维度下出现卡顿的人数除以当前维度下总人数，失败率定义类似为打开失败的人数除以打开直播的人数，这两个指标直接衡量了当前维度故障的影响范围；流媒体系统错误了定义为流媒体中心拉流的失败率，这个从一定程度上反映了直播的稳定性；平均首屏时间，直接反应了观众打开直播观看到内容的速度，从一定程度上反映出了cdn的调度的准确性；我们对各个维度的流量和并发推流数也会做监控，通过流量与推流数的对比关系，可以比较直观的看出当前cdn上观众有没有出现明显的故障，比如某个地区流量突然下跌，这个地区的cdn节点可能存在异常。

对于这些监控指标，我们做了不同的报警策略，：对于质量我们衡量质量的波动性，比如首屏时间是否出现了比较大的波动；对流量和直播数量我们做同比环比策略，比如此时昨天1000并发，今天600，同时直播量突然从1000降到800肯定，肯定是那里出现了故障；我们对于活动的特殊直播间做有白名单的监控，对活动的白名单房间做特殊的监控策略；有时我们发现故障可能来自内部的开播或者观看服务，我们开播次数和播放次数的同比波动。

当报警或者异常产生时，我们需要将异常转移走，我们设计了全平台的地址调度系统，调度平台由地址分配系统、策略管理系统、配置系统组成。调度平台对整个 开播、观看和媒体处理的地址做统一分配，cdn的地址统一由地址分配系统分配，带来的好处时域名管理是收拢的，新增删除或者配置不同比重是很方便的统一处理；策略管理系统管理地址和策略的关系，配置平台管理用户或者地区对应的策略关系。如果我们要接入一家cdn，只需在策略管理系统增加一条地址规则，通过配置平台分配用户。

调度模块最核心的模块是调度策略，我们的调度策略有常见的基于用户出口IP位置的调度策略，会针对用户的出口IP选择一个最优的接入方式；用户在观看或者直播过程中，如果效果不理想，会在运行的过程中不中断的访问调度服务器获得一个备选的地址；有些用户通过IP策略调度效果始终不满意，我们会基于之前的历史数据对用户的IP调度策略做再次纠错；在IP调度使用过程中，会经常发现ip库给的地理位置是不准确的，我们结合用户的gps数据对IP的位置数据做再次纠错这个是基于第三方服务实现；如果用户对多个cdn的效果都不理想，我们会适当分配媒体云的资源给用户尝试，我们的私有媒体服务器都部署在bgp机房，连通性要比普通机房更好。

尽管我们有多种调度策略，有时候任然会遇到一些用户个例，一些用户会在线反馈，这类用户都期望能快速的解决当期那问题，这种情况下需要一个很方便定位问题的平台，基于调度平台的全链路日志收集功能，我们专门做了一个工具，即使是客服或者运维的同事可以很方便定位到用户故障原因。

目前调度在映客内部使用支撑起了直播监控、质量优化、故障定位、流量调度、音视频优化以及成本核算工作。通过调度系统的报表监控系统可以发现直播系统中潜在的异常问题，为cdn的优化提供指导方向，调度系统提供的各个组件也在持续帮助QA和音视频团队提升工作效率。

调度系统未来

我们的调度系统做了很多工作，但是有很多地方还不是很完善，我们也正在做下面的一些工作：

调度系统目前还是事后调度，异常发生到故障处理的延时还是比较大，我们正在做一套全网拨测的系统，通过全网拨测，提前感知到CDN系统的故障，当用户访问的时候提前转移

私有媒体云现在承载这映客的一部分核心功能，私有媒体云采用的是私有协议，目前运行上发现有些网络与私有媒体云的有连接不通的状况，需要对私有媒体云的链路再做优化。

目前调度平台仅仅依靠人力调度，在这一点上需要做一套智能调度系统，主动发现问题主动切换。