腾讯1300场NBA直播背后的技术力量
《腾讯1300场NBA直播背后的技术力量》要点: 作者简介李震东 前言我们在一些重要工作的挑战过程中逐步在提升技术,本文就介绍我最近一年多做海量直播的工作内容,其中选择了最具代表性的,每年有1300场的NBA直播. 1、直播业务的火热发展从2015年起到2016年,是整个直播行业兴起的阶段,涌现了大量直播的业务.直播为什么在这一两年带来飞跃的提升?其实主要是有四个点组成.
大家能够掌握到第一手的资料,满足八卦心理的时候,大家也是非常愿意的.这里其实不仅仅是女生爱八卦,男生其实也爱八卦,只是内容不一样而已. 整体这些因素的出现,包括整个技术的辅助,是把我们整个直播的行业带来了一些新的高度,可以说是最火的高度,什么都可以直播,现在也在直播,感谢直播团队,我知道他们很辛苦. 2、优秀直播需要具备的特征一个优秀的直播需要什么样的要素?人人都想直播,但是直播怎么才能做得好?我当时是有面临压力的,腾讯这一个大互联网公司,如果直播搞不好,用户不满意的话,会面临巨大的口碑问题. 一些优秀的技术点我列举了一下,包括画质一定要清晰,比如看一场维密秀,一定要有添屏的感觉,关键部分不是很清晰的时候,弹幕都受不了,1080P 画质还不如720P. 你看一场球赛,别人都已经要投篮了,这时卡住了,然后这个球没进,不知道当时看直播的人是什么心情,什么破直播. 还有音画同步,这种场景也是非常重要的,比如有些互动环节,我说大家有个提问环节,请线上的朋友有什么问题想问的,然后我发现难道大家对我的演讲不喜欢吗,后面有人发微信告诉我,信号还没传到,我就多等两分钟,估计下面的人要崩溃了. 包括延时还有音画同步,在演唱会过程中,弹幕突然骂了,又在假唱.歌星说明没假唱,这次是真唱.还没假唱,截图,录了一段视频确实,歌词明明已经唱到很前面了,嘴型还不对,这就是典型的音画不同步. 当然还有更多的情况,后面我还会具体的介绍,这么多的技术要求给到我们的直播时,因为直播确实是需要有非常高的体验要求的业务,怎么做好才能减少挨骂?才能减少干不好就别干的概率呢? 3、直播行业的技术选型接下来跟大家介绍NBA过程中的典型场景,我们面临这么多的技术要求,这么多的用户压力,怎么去做技术的选型?直播还是一个蛮复杂的技术,因为它包含着很多环节. 3.1视频直播流程比如整个视频直播包括从视频采集、传输、包装、编码、推流、转码、分发解码和播放等多个环节,不算其他我们总共有十八个环节,再比如说机位1机位2机位3,要做简单的信号处理,上卫星或者是网络传输,网络传输再传到节目制作中心,再进行包装,包装完了以后开始分发给用户. 除此以外还面临着各种用户的需求,各种清晰度的需求,因为用户的网络受众都不太一样,清晰度可能不太一样,这是需要多清晰度的,还要设多个终端,比如说 FLV 和 HLS,再经过一定的分发去走内容分发的网络,最后到各个用户的终端,终端还要进行适配技术,整个过程是非常复杂的. 3.2 播放体验上的挑战简单先介绍我们在NBA直播过程中面临的技术问题和当时怎么解决的.主要我列了四个点.
但是大家都有监控,腾讯也有这个课程,现在的监控是已经到了新的层面,除了现在必要的监控的各个环节以外,另外是大数据的冲击.每天整个监控的信息,一天差不多有2000亿条,这数据如何收集起来,如何进行分析,如何快速的在极短时间内发现问题所在,帮助我们快速定位.这是一个巨大的挑战,这就涉及到大数据处理. 我现在就开始一个个说当时我们是怎么来解决这个问题的.这是2015年的夏季,当时接到这个任务的时候挺开心的,NBA是很大的投入,腾讯每年投入一个亿,还是美金,公司把这么重要的任务交给我们,要体现我们的价值.干得好,升值加薪不在话下,干得不好,可能就要去财务领工资了,所以风险和机会永远是并存的. 4、面对传输问题的挑战4.1 挑战一:传输过程中容易出现花屏和断流但是直播第一天的时候傻眼了,因为画面这样了,有深深无助的压力.领导说,你这问题怎么解决?因为以前从来没搞过直播,我们就开始分析,因为传播过程中为了满足低延时和实时性都采用 UDP 的传输. 但是是像车队一样,很容易造成一些卡顿的情况,因为一旦传输要进行一些同传的时候,包卡在那里,视频的画面都是经过大量的压缩,一个包丢失的话可能是一个区块,一个像素的影响,我们在传输过程中那么远的距离传输,势必导致丢包,一旦丢包就出现了画面的卡顿.当时不管是运营还是各种技术,都说要解决.其实有解决的办法,我后面再说. 4.2 挑战二:传输过程中容易出现花屏和断流我们当时选择的方式是网络传输,从美国的新泽西机房一直到传过北美大陆,传过太平洋,再从香港的节点到北京,这么大的距离,我们当时测了一下距离,是17286.59公里,这么远的距离,大海有自然因素,可能会有海啸,非常容易导致整个线路的不稳定. 可能有些同学就说了,为什么不用卫星传输?卫星传输是很简单的,只要经过两个卫星就行,美国卫星发过欧洲的卫星,欧洲的卫星再中转给中国的卫星. 卫星传输确实是简单,但是价格是非常昂贵的,可以说通过卫星传输的话,差不多是网络传输的价格的50倍,网络传输价格已经很贵了,如果1300场都用卫星传输不太现实. 4.3 传输优化解决方案
5、面对制作技术的挑战5.1 视觉优化-字幕当信号完美传到制作中心的时候,这时候就开心要进行一些节目制作中的包装了,比如说加一些字幕,通过字幕机把球员信息转化成中文的信息. 5.2 视觉优化-AR我们还可以利用一些AR技术,将我们在比赛过程中一些互动的过程,或者一些数据的分析加到直播画面过程中. 5.3 视觉优化-多角度比较重要的一点是多角度,这是提升用户在观看过程中的吸引力,比如加了英文的原音还有低角度和右篮板多视角的技术.整个过程完成了节目的传输和制作包装的过程. 6、面对播放问题挑战6.1 问题一:播放流畅度问题到了重点的地方了,节目已经准备好了,接下来就要传给用户,传播给用户的过程中,具体是有要求的,就是流畅度.
6.2 解决方案-CDN技术首先是最普世的技术,CDN 的技术,我们在全国部署了500个 CDN 的节点,包括新疆、香港这些地区,包括很偏远的云贵地区. CDN 是一个比较成熟的技术了,把用户的内容推到离用户最近的地方,拥有500个节点以后,还做了提升用户接入速度的技术,我们直接使用IP的调度,没有经过 DNS 的解析,节省了用户在接入过程中的时间.另外就是我们会对整体状况进行实时统计. 有了优秀的 CDN 技术和覆盖以后,是不是就真的能够满足两秒打开的要求?其实不是的,因为直播过程中有一个重要的特点是,直播开始的效率. 直播不是24小时都有的,有时候信号没有了,用户根本就不用去看,但是一旦直播开始,比如说一场球赛开始,这时候用户会有非常强的直播效应就是进入效应. 6.3 问题二海量用户播放体验保障问题像腾讯拥有包括微信、QQ的渠道,NBA一场比赛开始的时候,一分钟内我们的用户就能够达到峰值,每一分钟进入大概都是在200多万. 人多的时候就会拥挤,不是技术无能,是用户实在太多了,我们可以去想象一下,每次在刷票的过程中,看到12306的时候,每个人都骂12306的时候,我是坚决不骂的,因为那个量确实太大了,每天有多少人,具体的数据12306都会公布. 在海量用户的时候,大家都想在那个时刻进入的时候,确实是很难支撑的,那怎么办?生活还是要继续,尽量还是要保住饭碗. 6.4 解决方案—调度策略在快速海量的用户进入的过程中,在这么强大的用户冲击下面,它会造成对用户的冲击分为哪些方面,我这里总结了是两个方面. 第一个是用户快速进入的时候会造成局部系统的拥塞,另外就是用户实在太多了,我的系统没办法支撑了,这时候该怎么办?局部的拥塞是用预调度的策略,就是用户来得快,我的应对机制更快. 第二是柔性降级,是海量技术里非常重要的一个思路,其实是通过服务有损的方式对用户提供服务. 举个例子,比如说现在只准备了一百个位置,却来了两百人的时候,这时候该怎么办?如果是无序的,什么都不干,可能会在现场打起来,那会引起更大的混乱. 这时候怎么办?如果你的平台的能力已经无法完全支撑这么多用户,预估是不准的时候怎么办?就需要有柔性降级的策略,我接下来详细说. 天下武功唯快不破.当用户快速进入,势必而言会对局部系统给出很大压力,我们怎么快速分解这部分压力?这里用了两个重要方式.
之前我们跌倒就是因为延迟只有一分钟,但是一分钟过程中用户进入这个领域的时候,已经完全把机房冲跨了,但是我们开始预测,只要前一分钟的曲线,可能会出现把机房冲爆,就不再给机房导流.提前进行分流,通过预调度方式解决局部的拥塞问题,就是快,甚至是通过预测的方式. 调度策略—柔性策略 方法一:排队 第一个方法就是排队,当一个用户去预测,比如只有五百万人,却来了五百零二万人的时候,这时候不要直接挤进来,直接进来就容易进行资源的竞争,直播是一个高资源带宽的业务,一旦形成资源竞争,用户下载不到足够数据就会产生卡顿,这时候就让他先不进来,让他先等一等. 方法二:柔性降级 这就是柔性降级的重要策略,千万不要因为超出预期了,让这部分人去无序和现有已经能够服务很好的人造成资源竞争,如果产生这种竞争的话,整个服务体系就会全部崩溃了,所以一定要有预案,要有一个准入机制,或者有一些降级的丰富的手段,既能保证现有的用户,体验不受到影响,也能对想进来的人有一个很好的预案去解释. 调度策略就是这两种,如果用户在快速进入过程中的话,如果只是局部的,那就是以快制快,通过更快的速度拿到我们现场的机房流量,另外一个方式就是通过柔性方式,当用户来得我们无法承担的时候,不是说用户从A机房挪到B机房能够解决的时候,这时候就要极少解决,排队或者降级策略,比如说音频或者低清晰度画质,来满足部分用户,避免他造成全局用户的影响. 把2秒法则和卡顿解决之后,通过在应对各种用户场景的技术的情况下,就能够很好的把流畅度需求解决掉,用户还是会有一些需求的,两秒是用户基本的耐心,但是用户还想更快看到画面,这里有个重要的技术就是秒开的技术,就是如何让用户更快看到画面,事情无绝对,能做到极致. 6.5 解决方案—提升用户看到画面的速度这里用的是I帧压缩去掉图像的空间冗余度,I帧是可以完全解码的,只是帧内的压缩,没有掺杂时间的属性,I帧能够独立解码出来,P帧需要依赖于I帧,这时候是解不出来画面的,需要去参考前面的I帧,通过I帧把背景信息和运动信息补齐,这里是带运动参数才能解出来,而B帧是双向帧,也是解不出来,它还要依赖于后面的P帧,所以基本上就是这样的画面压缩逻辑.B帧就需要同时拿到I帧和P帧,根据拿到的压缩数据去解压. 之前是一个无序的过程,就是可能会给你I帧,也会给你B帧,也会给你P帧,如果你下的是B帧,那解不出来,把I帧先下完,再把P帧下完,才能够解压出来.这种情况就会出现需要下载更多的数据,等待更长的时间才能看到画面,这样对于追求技术极致的人是没办法忍受的. 我们就用了一个技术,让用户更快看到画面的技术,首先我都是下I帧,这个和播放器一起去改造,用户下到I帧马上画面就出来,降低用户的时间,降低了接近两百毫秒,让我们的上帝去看到画面的速度又提升了两百毫秒. 但在体育大型的赛事直播,尤其是个人主播的时候,体现的优势会更加明显,通过这些技术,我记得有一个有意思的问题.当时有一个同学说,这个东西很难吗?我说其实感觉不是特别难,概念一说很清楚,改造的话估计一两个星期就可以了. 他说,为什么不难的技术,其他的直播或者行业做不到呢?我当时回答的是,我觉得做技术或者海量的话其实应该有两个点,第一个是单纯一个点解决起来是不困难的,困难的是把一个技术体系,针对于这个业务,这个方面遇到的各种问题解决. 我们解决了 CDN 问题,解决了纯属问题,在 CDN 上又直接调度问题,解决了流畅性上海量冲击的问题,再加上解决了打开画面快速的问题,实际上是有很多的点去解决的.把整个点再复盘一下,才慢慢形成一套方法,并不是一两个点能够来解决. 所以海量技术并不是容易解决,而是过程中不放弃,把每个技术点做到极致,而且是非常适合自己的业务体验的极致. 7、面对海量监控问题的挑战7.1 监控的目的最后说一下关于监控的问题,全流程监控是为了发现质量问题,比如说基础监控是最底层的,包括 CPU、内存、网卡、IO硬件,还有网络,因为现在都是互联网服务,网络监控是必须的,比如说点到点 ping 的延时,udp探测,链路分段检测,慢速这些监控,另外就是播放,播放属于业务层,这个时候就需要有包括对播放量、打开时间、卡顿时长、卡顿率和失败率,包括一些码流去监控. 另外针对直播的业务属性,更加偏向业务的监控,比如说直播流,比如说黑屏能不能监控,用户看到的画面是不是屏幕已经变黑了,或者可能是马赛克,可能有慢速或者丢包导致的情况,另外就是静音,直播过程中用户是不是听不到画面了,或者爆音,用户听到刺耳的声音,还有转码这些过程.这是一个立体化的模型,所有这些点聚合起来的时候,前面我提到各种数据上报,包括后台日志. 7.2 监控的挑战-日志分析效率日志整体一天是2千亿条,未来可能会超过5千亿条,这么大的量半天以后拿到结果或者一天后再拿到结果,黄花菜都凉了,怎么办?我们需要的是分钟级的. 传统的方式已经不再适应需求,现在面临的是每天千亿的数据,每条可能有一百个维度,数据量每天超过100,我们还需要有一个秒级的响应,要求打开的速度是10秒钟响应,延迟是30秒.这时候我们就要引入新的技术,面向分析,面向搜索的技术,去推进我们在监控领域面临的数据量的挑战. 7.3解决方案-大数据处理
这是我们的大数据处理流程,其实是一个比较经典的大数据处理流程,是从各个终端,包括苹果、安卓、TV、PAD、PC web 这些,把数据上报以后,通过日志式的采集系统接收,经过简单的清洗和Kafka传递到Spark集群,计算维度,统计完了以后生成我们的数据产品. 鹰眼日志就是基于ES来进行开发的,这里就是把大数据的经验分享一下,主要是运用实时运算,来实现播放流程的监控和 CDN 测速监控,这套架构基本上满足天2千亿条和100T以上的数据,维度是非常多的,差不多一条日志一百多的复杂的数据. 一旦有了监控的数据,能够快速得到的时候,你就真的能够先人一步去发现问题,什么样的问题也能够快速获取.这里的技术其实涵盖很多方面,虽然说起来很简单,但是涵盖了海量运营的技术基础,涵盖流媒体的基础,涵盖大数据技术. 怎么把数据拿出来,实时分析出来,还涵盖了 CDN 的网络传输技术,怎么保证网络数量,怎么在 CDN 的过程中快速加速,还有怎么把原来 DNS 的方式变成IP直联的方式,其实是包含很多方式的,这可能不是一下子能够说得很清楚,相当于是抛砖引玉. 8、总结海量的运营技术是很大的体系,希望大家遇到这种情况的时候,能够勇敢站出来,面临挑战,只要我们有一个追求卓越的心不断尝试,大部分人都是能做到更好的,这就是我的一点心得 文章来自微信公众号:高效运维 (编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |
- scala – 如何使用Array [String]元素调用String
- 用户权限设计(二)——用户认证管理设计方案【转】
- angular2 primeNg 表格插件 排序
- angularjs源码笔记(2)--loader modules
- twitter-bootstrap – Accordion Inside Accordi
- 使shell’source’文件使用相对路径
- 如何在Jmeter中使用Bean Shell采样器?
- 用于在Omnicomplete框中上下导航的Vim样式键
- angularjs – 以编程方式单击以更改UI-Bootstrap
- angularjs – 在Angular ui-calendar中访问fullc