陌陌直播质量保证与 CDN 拨测实现

陌陌直播系统上线以来，来自主播的并发量连创新高，如何快速准确的定位CDN故障就成为保证用户体验的关键。通过建设一套监控系统，收集全链路日志分析，实时与CDN互动，并任务化的主动拨测CDN，成为有效的定位故障的手段。本文由陌陌直播高级研发工程师龚清华在见云沙龙的分享整理而成。

来陌陌直播看什么？

大家来陌陌看什么呢？来陌陌大部分的人都是为了看妹子，我们陌陌总共的注册用户现在应该有五六个亿了，我们的男女比例大概在7：3或者是6.5：3.5，新的用户是比较多的，所以它吸引了大量人在陌陌看妹子，每天你可以喜欢活跃的、淑女的或者劲爆型的，各种类型的都有。大家下班了也可以看一下，除了妹子，陌陌上面也有很多有才的男神，大家写代码，如果写代码也算一种才能，我们也可以试一下。

除了这一块上陌陌还能够看什么？看明星，我们陌陌做得一个哈你现场，相当于我们就是线下的一个中国好声音，经常会请明星，比如说风凤凰传奇、张亮。经常每周有这种活动，这种相当于比较高端的PGC产生内容。如果来陌陌，大家都能够看妹子，看男神，看明星，大家玩儿的很爽，我们技术人员就Happy了，每天喝免费咖啡，如果只有这些就好了，但是我们现在面临了大量的问题。

潘多拉盒子

不知道你看平台有没有发现这样的问题。

1.播不了 。我喜欢的妹子播不了，那我没办法在里面骂。花了钱为什么播不了？这种情况我们就会接到用户的投诉，我们压力很大。

2.妹子卡死了 ，妹子说谢谢大哥送我礼物，谢谢送我火车，送我火箭，可是用户没有看到他说谢谢，我的钱白花了。这种情况肯定用户也会找你投诉，投诉的话，前端的运营人员也Hold不住了，最终也到我们这里来了。

3.播着播着妹子去哪了？ 不见了 ，这都是我们常见的一些直播情况，当然我们所见的问题肯定不只这些。通过分析我对直播常见的一些问题做了分类。

常见故障分类

大家很多人可能见到过，但是不一定所有的故障都见到过。

1.业务层故障：

（1）房间状态错误，明明我喜欢的妹子7点开播，我没有收到她的开播通知，可能她已经在直播唱歌，唱的挺欢，但是我却看不到她的一个开播状态。

（2）URL错误，后台把妹子搞错了，比如我喜欢A妹子点进去，他播的B妹子的视频，这种是比较低端的错误。

（3）踢出房间，房间大家可能在里面说一些比较露骨的话，可能会被踢出房间，这种你被踢出房间之后，你也进不了别人的空间，这种业务层的一些Bug都是我们常见的。

2.网络层故障：

（1）网络连接不上，就是我刚展示的第一个图，我想看一个直播，那就连不上。

（2）加载缓慢，我家的网可能是联通的网，一百兆，就是加载慢，进去之后，三秒钟都不出来东西，这时候大家生气也很糟糕。

（3）卡顿，讲话不连贯。

（4）跳帧

3.应用层故障：

（1）音视频不同步，这种情况大家看的比较少，可能我们见到的比较多一点。例如妹子在唱歌，已经到“你是我的小苹果了”，她还没站起来，这种情况我们见到比较多。

（2）视频丢失

（3）音频丢失，没有声音了。

（4）黑屏，可能是视频丢失，它可能里面还有内容，传的是一个黑场的东西，也可能是我们内容里面就没有这个视频，两种情况有一点不一样，但是表现的现象都是我看不到东西了。

4.其他故障：

（1）播放器故障，播放器挂掉了这种故障也比较多。

（2）运营商网络故障，骨干网，因为各家运营商太多了，他们之间的打通存在问题，经常出现故障访问不了。

通过我们一些常见的故障，分了这么多类，我们的技术人员面对着这么多的问题，我们该怎么办呢？

全景监测

主要讲两套系统，一个系统做产品检测叫亡羊补牢，这种方式大家可能用过，在APP里面各个地方，它是基于日志分析系统，我可以在APP、后台还有CDN里面，各个地方进行一个埋点，做日志分析。实时的分析，发现问题了马上切走或者采取一些应急的分配措施。这种情况为什么叫亡羊补牢？因为只有用户发生了之后，我才能够避免损失继续扩大化，当然它已经对我的系统造成一定损失。

这是陌陌用的CDN架构，我们整体上分为推流端、CDN、播放三大块，推流端我们总共有三类推流形式。

1.手机 ，随时可以手机开播，可以看到我们现场妹子也在搞直播，但是我不知道是不是用我们的陌陌在直播，就是用手机进行一个推流.

2.PC端 ，YY是最早用PC端。PC端一般会有很多开源的工具，我们自己也开发直播的一个助手进行摄像头的采集，大多数人还是用的OBS，直接通过采集卡或者摄像头。

3.专业导播 ，电视的主持人怎么玩儿的我们也是怎么玩儿的，你可以通过摄像机采集，会选择一家主推CDN，因为CDN也不能保证是百分之百可靠。我们也遇到过CDN挂的情况，所以为了保证CDN是可用的，我们做了 一个互推，一路流推到CDN上以后，我们会把这个流按照我们的规则推到CDN2或者CDN3上去。最终播放端，通过我们的智能调度，我想选择哪家CDN就可以选择哪家CDN给你分发，我们选择策略的好坏包括看的质量好一点，还包括一些价格因素，他家CDN太贵，我不能把大量的压到他家，这样成本会很高，这就是我们的一个调度策略，整个一个CDN架构。

CDN调度及日志采集

日志采集总共我们分为三大类：

一、  终端类 ， APP 里面肯定是有埋点的。

二、CDN类 ，CDN要把它收到的质量指标汇报给我，为什么需要这个？是因为很多情况下我是拿不到的。我们的OBS直播到CDN上去的质量到底怎么样我拿不到，因为它是借助第三方的。包括我的摄像机，它的指标到底怎么样我不知道，我只能通过CDN给我反馈，你喂给我的值是什么样的，我再判断是不是一家CDN有问题。

三、后台类 ，我们的日志会采集业务的交互流程，包括主播开播停播，或者你开始播放、停止播放。我们还可以在IM里面看到这个卡字样，非常 高的时候，那我也要预警出来了，包括后台类的日志。

日志的采集方式大概有三个类，我们到底采集哪些日志？不只这些，作为质量保证最主要的是这两块：

1.事件：

（1）事件开播、直播，你开始了，我要知道，你停止了，我要下掉。这样就保证我各个采集纬度。比如我说在线用户是正常的，你上来就上，下来就下，这样就保证了我的在线用户数是准确的。

（2）心跳，为什么要心跳？APP可能有故障，我是收不到这个停播的，导致用户在线数不准确。

2.指标 ，针对我们质量监控，最主要有三个东西。

（1）带宽，带宽是多大的，你的带宽只有两KB，那你永远都播不了，所以带宽是很重要的。

（2）卡顿，卡顿主要是针对于播放端的，比如我们老板经常会在群里说，我又卡了，他有可能是为了给大家营造一种紧张的气氛，他吼一下，肯定下面大家都是积极响应。这个是真的吗？我没有看到卡顿，我们为什么要响应你？这样的话就会让大家造成一个精神压力，你卡我给你解决，你没有卡，你在那喊，喊破喉咙我也不会理你的。

（3）帧率，现在我们为了保证你能够正确的比较流畅的看到这个直播，有时候我们会选择将帧率降低一些，当然你听声音是比较流畅的，但是画面可能不是那么流畅。所以我们用了一个帧率上做了变帧率的策略。

通过一套系统，我收集了大量的日志，大量的日志收集了之后，我要干什么？

业务架构图

这是我们产品监控的业务架构图，从底层我们收集了三类日志，三类日志全部报到我们的后台系统，后台系统经过了三层分析。

1.实时日志分析 ，我们基本上能够做到三秒到五秒的级别。某一块主播卡顿了，我三秒钟就能知道，马上就能够采取策略，这个实时分析系统基本上从实现方式、执行方式上全部采用基于内存的方式，在集群里通过内存的方式进行分析。

2.准实时日志分析系统 ，这一块本身是日志分析，可能Elasticsearch大家也用过，我们会采用一个搜索引擎，将这个准实时数据存到搜索引擎里面，他主要是包括报警等数据，因为我们的人员不可能24小时在线，今天早上来上班，发现群里或者邮件里面收到特别多的这种工单，我会查一下昨天的东西。昨天东西怎么样，那我放在哪呢？我们现在做了一套准实时的一个系统，这个系统的目标是存7天，现在不只存7天了，那个集群还是比较大的。

3.大数据分析系统 ，这个系统也不是我们做得，因为我们公司有大数据分析系统，我把数据丢在上面就可以了。比如说，老板每个月、每个季度是要看一下运营数据，那我们就要在大数据里面挖。我们会把日志丢给他们，实时分析系统拿到这些日志，我们做了维度的一个分析。

全网维度，陌陌在线用户数是多少人，我肯定非常的清楚，有多少人推流我也非常清楚，推流其中有多少人卡，我也非常清楚。包括CDN维度，这里为什么来提一下域名维度？大家可能在做CDN或者大规模并发的时候都知道，一个CDN域名里面它存在的流是有限的，像我们陌陌这样的量级，好多个域名都不一定扛的住。因为我们会对域名维度做一个统计，比如说我们用 了一家CDN，这家CDN上面可能有三四个域名都是服务我们，它每个域名又是不同的设备组。

此外，还有节点维度、房间维度、时间维度、房间类型维度。房间类型维度，我们就是说做了一个手机维度的，还有OS，还有官方房间陌陌的现场。最终还有个终端维度，观众维度。观众维度我们看到唐岩她看了几个，今天晚上看了多少次，卡了多少次，这个我们都可以帮她做定位。

通过上面这些维度，我们做了一个全景的监控平台，监控平台相当于一个Web平台，Web平台对我所有后台统计数据做了一个可视化的东西。因为我们的运营人员可能不管上面是怎么实现的？对它来说有个可视化的东西，就是比较不错的。我们做了一 个全景监控平台，对这些东西做一个可视化的东西。接下来是报警中心，我去设计一些门限，比如说门限互联网会说到底怎么报警，这是我们全景的一个业务的框架图，基本上也是这么实现的，我得到的这些统计数据，我肯定需要对这些统计数据做一个量化。

量化的话，它最主要的核心就是我刚说的在线用户，我需要知道第一件事情就每个维度，它的在线用户数是对的。如果我都不知道这个维度的在线用户数是多少，其他的全部都是空谈。我们第一个就是把在线用户数通过我开始说的开播、停播，心跳三个策略，让它在线用户数维持的比较准确了之后，我们围绕在线用户数做的。我们肯定不止这六个纬度，这是作为质量纬度最重要的一个维度。

统计指标量化

1.卡顿率 ，卡顿率是什么意思呢？比如说某一个房间有一万人在线，如果其中一个人卡了，那么卡顿率就算万分之一，如果我是一万人的房间，一个人卡了，这一个人卡了一万次，这个卡顿率依然是万分之一。这个算法是为了衡量一个卡顿对于我统计维度的一个影响的范围。一万个人才影响一个人，卡死了，我也不会管你的。除非你是老板，统计卡顿率肯定不是特别客观。

2.人均卡顿次数 ，我会把这个房间出现的所有的卡顿次数除以我的平均人数，这样我就能得到你这个房间的严重程度。我刚说的一万人在线，卡了一万次，这个卡顿率百分百。从另外一个角度，我是不是应该关注呢？这就看我们的策略。

3.卡顿时比 是一个重要的指标，你卡了之后，我每次卡一秒，我每次卡十秒，这个差别是很大的。我会把你卡顿的时间除以总的播放时间，这样做一个比值就能够得到这个房间或者是这个统计维度，一个整体的播出质量。举一个例子，还是我说的这个案例为准，一万个房间，每个人在上面都看了一分钟，那整体的观看就是一万分钟，比如说他卡了10分钟，那我就是用这十分钟除以上面的一万分钟，这就是我整个房间的播出质量。

4.开播故障率 ，你开播不了，这也是有时间的。最终开播失败的，因为CDN某个节点挂了，那肯定都播不了了。就是说像CDN一般它在一个城市只有一个节点，北京的节点挂了，所有北京都看不了了。在短时间内，我们要比CDN更早 的发现。CDN的问题响应还是比较延迟的，我们要及时的把这个切走。

5.播放故障率

6.平均接入延时 ，从我进房间到我看到视频这个时间到底是怎么样的。通过这么一套系统，基本上我们运维人员可以7×24小时的有事干了，因为基本上随时都有问题，不存在没有问题的时候，因为我们的量实在是太大了，这个已经可以把运维人员车轮战了。

我刚说它是一个被动的系统，你只有事情发生了，我能够知道，当然通过现在的一些大数据分析或者大数据模型，我能够做这种预警，但是这种预警可能技术水平比较高，国内的直播发展也是初步阶段，我相信应该还没有人能够做得比较不错。为了解决这个情况，我们能不能先发制人呢？

CDN拨测系统

拨测系统的核心思想是模拟一个客户端，向CDN发起一个链接，我测试一下，这路流的质量是不是好的。在我们老板唐岩一开播，我马上就能测十个节点，比如他在美国开播，我马上在中国测，能看我就不紧张了。这就是在第一时间先发制人。

基于DNS调度的播 放流程

说到CDN拨测系统，在这我们科普一下常用的DNS播放调度的流程，大家可能也知道，我在这简单说一下。终端进来一个房间或者是拿到了一个流的地址，会有以下步骤：

1. 向ISP的这个DNS查询这个流到底在哪台服务器上。你是联通的，你接入联通的，他肯定有Local DNS。 

2. Local DNS，它会通过我们服务器一个DNS系统，包括root回源等一大套，它最终肯定要回源到CDN的一个叫做GSLB全局负载均衡。他会通过本地的Local DNS知道你这个用户在哪个位置，他就会根据位置返回到离你最近的IP。终端会向离你最近的CDN节点发起流媒体的连接，拉流、播放。这里第五步和第六步有些CDN有，有些CDN没有，它主要是做了一个集群的负载均衡。开始我不知道每一 个IP负载量很高了，我怎么给附近的节点？通过DNS，因为每次都比如说我瞬间参加什么活动，上来一万人，那DNS解析肯定是已经存在的。不然到这台机器上，我怎么给另外一个IP，这里DNS，CDN做了一个SLB，它会做三级二跳转，把你跳转到它附近的节点。如果这个节点都扛不住了，他会跳到别的节点。 

但是接入DNS会有一个问题，第一国内的运营商不是那么规范，尤其是小运营商，这样量级的算比较大的，一些小运营商的话，他会为了降低成本减少运营商之间的一个结算，平时你们家接入是一百兆，这个一百兆，一般的意思是，在你接入的运营商之内的带宽是 一百兆。你是歌华的，我是歌华的，我们之间的带宽是一百兆，但是我歌华在访问电信，二级运营商都向一级运营商申请一定的带宽，我再对外发展用户，这个带宽基本上国内的价格，八十到一百万，一个亿，这个是很贵的。他不想让你访问对外的出口，但是我的内容又在这个接口，所以有时候他会给你劫持，在本地会做缓存，在我内部访问。比如一万人都要看外面的节点，那我自己向外面拉一个流分给你们好多，但是他自己拉的流质量又没法保证，所以有很多DNS劫持的一个现象。

另外Local DNS定位不准也是非常常见的一个问题。我们自己APP一般都是自动获取的，好多技术牛人喜欢填，比如说我把Local DNS填成4个8，我明明在北京，你给我调到美国去了，我看了之后卡死在外面了，或者我填大家很多的用114什么的，这个节点在杭州玩儿的。我记得喜欢填这玩意，那肯定定位就不准。DNS系统是通过Local DNS来的。还有什么情况呢？我某个节点挂了，DNS是有延时的，可能这个节点某一个IP挂掉了，你访问的时候，本地这个DNS缓存，它是会缓存的，我就没法及时的知道，还向这个节点发。好多CDN也给我们提供了这么一个模式，借助APP的一个DNS调度，他与Local DNS差别也是挺大的：

1. 终端第一次向我BO，就是我们的业务后台。我要进一个房间的时候，他连我肯定要向我拉一个播放地址，我就能知道它的出库IP，从这一刻起，我BO就知道这个功能到底在哪了。

2. BO用你这个终端的出口IP，向CDN的这个GSLB做一个扩展定位，这个定位就是比较准确的了，用户他改不了它的出口IP的，这个位置99%都是正确的，除非你真的是按照这些高科技的手段做反向代理，这种情况我们一般也不会搞。

3. BO向GLSB拿一个你的终端的出口地址定位，这样这个出口地址就真正的向你分的流媒体发起一个请求，这种情况任何一个流媒体挂了，它不存在DNS延时。任何一台流媒体挂了，我能够实时的知道，因为它的DNS我知道哪台挂了，我就不往那调了，你马上第二个能播或者是播第二次，进那个房间，那他就能够非常准确的给你调到另外一个节点，这就是常用的一种APP DNS。

这种解析方式也不是万能的，它主要有这么几个缺点：HTTP DNS，现在CDN提供的QPS还不够大，因为国内的这种CDN基本上都是服务好多家，要全部都是访问某一个GSLB，它的压力是很大的，DNS比一般的网站什么的量大太多了，它的响应时间不是特别长，不是特别快，也会导致有一定的延迟，这个延迟的问题还是比较严重的。所以有时候我们会在BO这个地方做一个缓冲，我认为一定的时间内，它这个LiveStream流媒体服务器会挂掉或者不会扩展，那么我就会做一个简单的缓存了。10秒钟这个位置，我就不会向你DNS做回源，这也是一种解决的手段，这就是我们做得一个拨测系统的架构。

CDN拨测系统架构

CDN拨测是模拟APP向CDN发起请求，模拟一个流观看，看一下这个质量到底 怎么样，它主要分为五大块：

1.终端

（1）手机，我们的波终端是有好多种的，一种在手机上，我可以给你手机发条指令，你就可以给我干活，这是一种终端。这个终端基本上我们自己测试用。

（2）PC，我们在全国各地自己也有很多的机房服务器节点，我在里面随便给你挂一个终端，给你发个指令，你帮我播一下某个目标地址。

（3）PAD，他觉得和iPhone差不多，就是这种各终端类型。这是具体干活的，你给我一个任务，我就试一下，这个东西好或者不好，给你一个结果。

2.策略中心 ，它非常重要，也是我们最核心的。我认为它应该用什么策略，我告诉你什么时候去播。像我们陌陌量这么大，我不可能所有直播都播测，这样也就别给我们发工资了，这是非常贵的，带宽太高了，几万块钱一个G，我们很容易就能够上很大的量。策略中心来决定哪些东西需要播，哪些东西不要播，哪些东西什么时候播。

3.BO维护整个陌陌后台的直播业务逻辑 ，我要播的时候，地址是什么，状态是什么，我要向BO去拿。他给我提供API，我告诉你，我现在要播唐岩的房间，唐岩的房间她的url是什么呢？他会先用这个BO去查。

4.报警中心 ，可以给你发短信，给你打电话，给你发陌陌，全都可以。当出现问题的时候，第一时间通知你，我马上处理。

5.监控中心 ， 他也是一个APP，所有的数据能够通过一个可视化的平台观看，现在的状态是怎么样的，我能够通过Web中心去查看。我现在房间在播，可能策略中心就没管它，没把他当一个大主播。因为他开播了10分钟，观看人只有一个，他老婆在看，那就不会管他，但是我要及时的通过监控中心去你给我试一下，好不好使。不好使的话，那他的压力就很大了，所以监控中心差不多就是我们的一个门户吧。

拨测指标量化

波测指标是怎么量化的，这一块就是我上面说的各个端到底是怎么干的，它到底要测的一些什么指标？现在这个系统主要是我们运维在用，我们现在最主要的测试在两个层面：

1. 网络层 ，第一个层面的内容就是 DNS时间，一个你要走Local DNS，我要测Local DNS，第二个你要是测HTTP DNS，我就要装APP DNS的方式。第二个是TCP建连时间，我拿到DNS之后，有可能这个服务器的网络不好，部署的不够边缘，从时间也能拿HTTP时间，就包括发起一个HTTP请求，一直到HTTP的返回两百，这里的话也是为了测这个节点能不能回源，有时当我发起拨的时候，这个节点，这个直拨已经下线了，CDN是回不了源的。他向主播推流这个节点拿不到数据，这种情况我也是需要知道的，HTTP的时间，看一下它回源的这个效率，首包时间，首帧时间，I帧时间，这种都是有时间的测量。

2. 内容层 ，在内容层现在最主要的看内容的完整性，因为我们的应用场景里流必须有视频和音频，哪怕你对着黑音或者什么，你觉得没有视频也是全当视频的，所以我会对视频和音频的完整性做个监测。

I帧序列号这个比较专业一点，因为好多CDN会做Group缓冲，因为我们在FLV解码的时候，我拉回来FLV流，解码器一般要遇到第一个I帧才能够开始解码，如果CDN给我一个流随便砍一刀发现不是I帧，我就要从这个时间往后面一直等，等到下一个I帧出现才开始解码，那这段时间用户是不能容忍的。有些播放器已经解码出来，发现前面是一些马赛克，所以CDN会给你做一个缓冲，缓冲从这一刀砍的时候，我那边我给你缓冲了，我会朝前一点点，把前面I帧发给你，那就延迟一点点，如果你的网络比较好了，播放器的视频会偷偷的给你跳 一帧，你不就赶上了吗，这种用户感观会好一点。这里的I帧序列号，我们就是为了干这个事情的，我拿到的第一帧I帧，如果拿到别的帧之后，你会对我这种策略造成一定的影响，那我就让你CDN改，你不改，我就不给你，不用你了还不行吗。这种的话，I帧序列号就 是这样。视频丢失音频丢失，视音频不同步，也就是做这样一个内容层面上的监测。

通过这些监测之后，我就能知道某一个流到底是好或者是坏的。是坏的，他马上给我报出来各种指标是怎么样的，那我就马上去找对应的环节去解决。

拨测策略

拨测策略主要是分为三种任务：

1.自动任务

（1）CDN质量评估和CDN的分发巡检，这两个是什么意思呢？因为我们陌陌用了各家CDN，我现在要确定各家CDN是不是可用的，所以我们在后面的话，引入我们的测试流，我会以某个方式推一个流，同时通过这种方式获得解码器，推到四家CDN。之后我的拨测终端会有一个任务，会分别从这四家CDN，7×24小时拉流，从CDN的各个节点去拉，我要保证这个流百分之百可靠，如果我在CDN上拿不到这个流，我可以判断你这家CDN有问题，不管是你整个 CDN挂了，还是整个节点挂了，这个节点我马上解决，不解决就调度走，CDN巡检就这个意思。

（2）在线主播轮询，我们这么大量的直播，我不可能看的，我有一定的策略，我会觉得10分钟之内，开播一分钟之内上线数超过一千人的，或者是其他的一些策略。比如北京我出20个直播，南京出20个直播，这种策略的话，我会做一个在线主播的一个轮询，保证我的大部分主播真正推流了，都能够被看，这个是自动任务。自动任务不需要管的，有问题了我赶紧处理，这个策略也要调整，我们都已经进到内部。

2.手动任务

（1）故障定位，某人投诉了，某个终端投诉了，或者是我们自己发现了某个卡，那我就要定位。比如唐岩他们家在看某个节点播不了了，那我就通过CDN的方式，去看一下，唐岩到底播的是哪家CDN的哪个节点。我给拨测终端发一个任务，告诉你去把这个节点给我拿一下。如果你能拿下来，那就好使，那就唐岩家网络不行或者APP不行，我至少能找到人；如果你拉不下来，那我就要找CDN，这个相当于是一个故障的边界。看清楚这个东西，要是看不清楚，你找人别人看都不看你，APP终端的人他根本就不知道后台是怎么样的，后台的人他肯定会骂，你那个APP肯定有问题，所以你搞清楚故障，这种故障我们现在怎么用的。

（2）灰度拨测，我要在上面上线一个功能，或者是我们现在那个互动玩法，我们陌陌上也有这个功能，我新上功能了以后，那这些功能真正上CDN了，这些CDN能不能准确的分发。我要创建一个批量的新任务帮我看一下这些东西好不好。

（3）压力测试，压力测试也是和第二个差不多，我上新任务了之后，比如说迅达云，他们也是和我们合作的厂商，他们吹牛说，我能够干一百个T，能不能干一百个T呢？那我就测试一下你，就说这个压力测试也是可以做这么一个功能用的。策略任务的话，就是有一个报警联动，因为我们通过第一个系统，我能知道某一个房间，我们现在用的策略任务最多的是在房间维度，某个主播的房间，它的卡顿率达到了60%。只要我的策略中心去试一下，这个房间他到底主推的哪家CDN，各种调度在哪些CDN的节点，我都去试一下，这些节点是不是好的。如果是坏的话，我就要把这些节点调走，整个的监测系统差不多就做了这么多活，因为监测系统它有一个和业务系统不一样的，最主要的区别就是监测系统。我不干具体的活，我发现问题，我去监管，发现问题了之后，业务系统去调整，或者是去解决这样的一个问题，我们只是发现定位问题，知道是什么。

问答

Q ：卡顿、黑屏分别是什么引起的？

A：我们现在看的话，国内卡顿90%以上是网络引起的，网络又分为两种，分为三类，一类，第一公里主播把自己的流要推到CDN上去，因为国内的网络情况比较特殊，它的一般网络下行的团队会告诉，但是你的上行带宽的话，是基本上只有一百K，或者什么这样一个情况，我说的比较极端，具体我们也测过一些，上线网络不够，这个卡顿，它一卡，全部都卡了，达到80%，70%的五这种情况，我们第一个故障定位点就要去找主播的上行带宽是不是OK的。如果你上行不OK，这是两个问题，第一个，让你测试一下你的陌陌的服务器，确保你家的带宽上行带宽是够的话，那你家上行带宽够，我就可以认为你家上行带宽够，但是把你调到了错误的节点上去了，这是第一公里，卡顿。第二公里，卡顿的就是CDN之间，它非常的复杂，一个美国人要到中国来，这个中间走的我们都不知道，CDN，有可能从香港的节点，韩国的节点，他们的中间做了很多东西，中间这一层我们不管。

Q：我是北京的，广州的它应该用一些专线，这个专线应该延迟很小些？

A ：这种专线的话也不是能够保证的，因为国内的骨干网，你不管是做专线，或者是做民用的，它最终的底层就是三大运营商的提供，他不可能让你自己去铺光纤。

Q：你们统计，发现是第一公里的问题多，还是CDN的问题多一些？

A：基本上第一公里和CDN的比例在7：3，70%的人是第一公里，30%的人是在CDN内部，CDN内部是服务中心，它差不多，基本上是这个数。

Q：你们是用那个http协议吧？这种应该是可靠的，来说他们怎么会坏？

A：因为是这样的，这个情况非常多，编码器导致的情况也非常多，这个不用置疑了，推上来的东西就是黑的，这个编码器肯定是有问题的，第二种情况，因为我们现在大部分的情况，推到CDN上的时候，协议，推上去，CDN它会做一个格式转换，RTMP到FLV这转换的话，它有可能把这个视频弄丢了，或者是搞错了，或者把里面的内容篡改了，这个是CDN的故障，第三种就是说我们播放器，我们播放器可能因为某种情况挂掉了，所以我们进行拨测测检测，播放器搞错了某个参数，它就搞不定某种格式。

Q：我们初创团队基于这种成本，还有技术资源，就是在直播这块，我们想走更远的话，比如现在我们当前技术策略是，就是像你刚刚说的，我们更多的采用CDN厂商直播流服务，我们自己的推拉流器，我们用这种CDN的这种给我们提供的这种直播流服务，但是当前呢，像刚说的卡顿，黑屏我们都遇到了，因为我们现在主要是在做海外，基本上我们在一个移动环境下在当地商场超市做一些直播，像刚刚那个问题卡顿率会非常高，但是我们基于第三方的去开发，我们没办法去解决，即便我们想去加速好多这种第三方的它也不支持这种，就是另外加的这种CDN加速，像对于我们这种创业，您给我们一个技术方面的一个包括技术选型，还有一些好的这种CDN的这种厂商支持国外的，有什么好的建议吗？

A：第一方面，因为你的量级不够大，你没法驱使CDN帮助你去做定制开发，你要什么我就帮你解决，但是现在好多CDN对外是提供了这些标准的服务，它的SDK，帮我们采集到了点，它的QoS是质量指标，质量服务指标，它是对外 报的，就是作为创业团队，你们去做这样一个日志分析，技术上也没有那么难，关键是你知道需要做什么，第二个，你们的活动，你可以做一个测试，比如说对于这种重点的人，比如说你们，我就瞎猜的，奥巴马播，那我能不能派一个运营人员，到奥巴马，我就溜达一下，先测试一下，有问题的话，CDN帮我调到另外一个节点。

讲师介绍