TOP

直播平台的技术架构揭秘(一)
2020-06-20 06:08:17 】 浏览:49次 本网站的内容取自网络,仅供学习参考之用,绝无侵犯任何人知识产权之意。如有侵犯请您及时与本人取得联系,万分感谢。
Tags:直播 平台 技术 架构 揭秘

2020年春节的这场疫情让线下零售降至冰点,但是却带火了直播应用。直播电商、直播教育等各类直播应用可谓赢得了历史性的机会,很多大众开始接受并认可这种新型应用的便利和价值,个人感觉随着5G的普及,『直播+垂直领域+精细化的私域流量』将会是互联网的一个大热点,迎来真正的红利期。

直播行业大概在10年多前就开始兴起了,秀场直播和游戏直播是PC时代比较成功的应用场景,直到16年,随着移动互联网的大规模普及,直播行业迎来了真正的元年,成百上千的直播APP出现在大众视野,大概在18年年初,直播答题当时火了一把,那算是直播类应用的第一次全民普及,然后是19年短视频网站掀起的直播电商。回顾直播行业的发展历程,直播类应用在各个领域遍地开花,那么它背后的技术架构你是否了解?

两年前,我参与了一个支持100万用户同时在线、20万并发的直播答题系统的架构设计,下文将以『直播答题』的应用场景为例,带你了解当前疫情下火爆的直播应用背后的技术架构。内容分成以下4个部分:

1、产品功能简介

2、面临的技术挑战

3、技术选型及依据

4、架构设计方案


01 产品功能简介

直播答题能在当时成为风口,得益于它的玩法足够简单,用户教育成本几乎为0。简单来说就是:全民在线PK、10秒答题、超时或答错即退出游戏、成功答对所有题即可平分奖金,俗称在线版的开心辞典。

在了解系统设计方案和架构之前,先看看直播答题应用有哪些核心功能?下面是APP端的几张产品截图:

1、答题以活动的形式展开,每场活动都会预先公布直播开始时间、答题总奖金、红包雨奖金等信息。

2、活动时间到后,用户就可以进入直播间,看到实时的视频流,有专业的主持人进行串词口播,场控人员会配合主持人同步进行发题、公布答案等操作。

3、题目下发后,用户有10秒的作答时间,答错或者超时即退出游戏,如果用户有复活道具在答错时会自动使用,用户能继续进行答题。

4、为了留住答错用户,活动期间有多场红包雨,用户点击屏幕就有概率抢到。

5、活动期间用户可发弹幕,同时会有弹幕滚屏轮播,以营造热闹的直播氛围。

6、其他功能:邀请新人、活动榜单、奖金提现等。


其他直播类应用在产品功能上和直播答题类似,基本也是这两类:

1、直播的基础功能:连麦互动直播(支持多码率、多协议,多主播同框)、美颜特效、弹幕、IM聊天、点赞、屏幕共享等功能性需求,以及防盗链、涉黄涉政鉴别等非功能性需求。

2、应用本身的个性化功能:比如答题场景中的发题目、作答、公布答案,电商场景中的商品展示、一键下单购买,网红直播场景中的礼物打赏。


02 面临的技术挑战

当时我们做直播答题应用时,面临以下技术挑战:

1、音视频处理及传输:涉及音视频编码、实时美颜、视频推流、CDN加速分发、终端适配和播放,流量统计等诸多技术点,而且我们当时的技术团队没有专门做音视频方面的专家。

2、高并发请求:参考了冲顶大会等答题竞品的用户量级,预计会有100W用户同时在线,1秒内有20W用户同时答题;1秒内单个用户可触屏发起4-5次抢红包请求,并发最大可达到500W QPS.

3、高带宽压力:按照标清视频的标准,观看直播的码流至少为1Mbps,如果100W用户在线,光视频流的出口带宽能达到976.56G bps。1条弹幕可达到130字节,1秒要滚屏20条弹幕,如果需要同时推送给100W用户,弹幕的出口带宽也将达到19.37G bps.

4、高计算压力:1道题目的对错判断涉及到答案比对、复活道具的使用、判断用户是否创了新纪录,同时还涉及一系列的反作弊策略(比如前面的题目答错了将无法继续作答),在主持人口播公布答案的瞬间,如何快速完成100W用户的答题结果计算?

5、资金流的正确性和安全性:单个用户最多抢3个红包如何不多领?财务上如何保证答题奖金、红包奖励不出现1分钱的误差?

6、低延迟性要求:直播场景下如何整合视频流和业务数据流,做到声音、主播画面和题目同步,以保证用户体验?

7、对商城交易业务的低干扰:直播答题仅作为商城的一个运营活动,核心目标是导流,它依托商城原有的用户体系,运营系统,大数据系统,提现通道等,如何做到对商城现有交易系统的低干扰?

可见答题这种泛娱乐的直播场景还是有挺多技术挑战的,它取决于直播应用的用户量级和业务流程。就算是直播电商这种低频交易转化的场景,要是李佳琪在带货,同样也会面临瞬时抢购的高并发挑战,所以架构设计时必须考虑业务最高峰时的压力,并且系统的各个环节必须具备动态可伸缩的能力。


03 技术选型及依据

一. 音视频处理及传输的方案选型

音视频处理及传输,因为技术团队不具备这方面的能力,所以当时调研了各种云厂商的付费解决方案,最终采用了腾讯云的直播解决方案。主持人侧:通过演播室的专业摄像设备,搭载腾讯云提供的obs推流软件,即可进行视频录制和推流。用户侧:APP端集成腾讯云的SDK,动态拿到推流地址后即可观看直播。

二. 业务数据流的方案选型

业务数据是指除音视频以外的,和答题应用场景相关的数据(比如题目、答案、弹幕、红包等)。腾讯云提供了两种可选方案:

1、题目预先设置好,直接由腾讯云的SDK通过音视频通道下发,打入直播流中。

2、让题目先通过腾讯云的IM通道快速送达观众端APP,在观众端先缓存下来,等待播放器通知了预期的 NTP 时间戳之后,再把题目显示出来。

腾讯云的这两种方案都可以提供“音-画-题”的完美同步,但是存在以下局限:用户的答案必须以HTTP请求方式汇总到答题服务器,这一块必须自己开发,另外公布答案、抢红包、弹幕这些业务腾讯云系统都是不支持的,在底层通信通道上仍然需要自行开发。

考虑上述局限以及业务的多变性,我们最终打算自研业务数据流通道。这样视频流和业务数据流会分两个通道下发,因为业务流相对视频流的数据量很小,只要能保证业务逻辑的处理速度和业务数据的下行速度,“音-画-题”的延迟是可以接受的。毕竟当时已经是4G时代,如果用户侧的网速不行,视频流可能都无法正常观看了。

为了做到业务数据流的独立传输,需要实现一个长连接、高性能的网关服务器(支持100W用户同时在线,20W并发答题,弹幕实时推送等要求),我们的技术选型是:Netty、ProtoBuf、WebSocket,选型理由:

1、Netty:Netty是当时最流行的高性能和异步NIO框架,直播答题的业务场景中,涉及到题目下发、弹幕、下红包雨等非常多的推送场景,而且一场答题活动中,客户端和服务端的通信频繁,长连接比短连接在性能上更优。

2、ProtoBuf:作为客户端和服务端的数据交换格式,PB是一种效率和兼容性都很优秀的二进制数据传输格式,在码流和序列化速度上明显优于JSON、XML、hessian等主流格式,同时支持向前向后兼容以及各种主流语言。

3、WebSocket:是 HTML5 一种新的协议,用来实现客户端与服务器端的长连接通讯。

三. 服务端的部署方案选型

前面提过,直播答题仅作为商城的一个运营活动,它依托商城原有的用户体系,运营系统,大数据系统,提现通道等。现有的商城系统部署在我们自建的机房中,为了降低对商城现有交易系统的低干扰,我们采用了『私有云+公有云』的混合部署方案。将高并发的答题系统以及它所依赖的缓存、MQ等公共组件部署在公有云上,方便弹性扩展,同时降

请关注公众号获取更多资料


直播平台的技术架构揭秘(一) https://www.cppentry.com/bencandy.php?fid=97&id=292904

首页 上一页 1 2 3 下一页 尾页 1/3/3
】【打印繁体】【投稿】【收藏】 【推荐】【举报】【评论】 【关闭】 【返回顶部
上一篇为何要搭建港股交易平台? 下一篇BUAAOO 第四单元 & 课程总结

评论

验 证 码:
表  情:
内  容: