欢迎您访问兴发娱乐官方网站!网站地图
当前位置:主页 > 新闻中心 >

直播云平台架构如何构建? 附PPT

2019-02-04 06:51

  注:每一种架构在一定程度上都有参考的意义。UCloud 将邀请到了在直播、抱抱直播、一起玩耍科技的技术专家,分享他们在海量服务架构探索过程中的技术实践。

  如感兴趣,您可以点击文末“阅读原文”,或将如下链接复制到浏览器打开了解并报名参加活动。

  主要负责UCloud视频云和 CDN 产品的研发工作。拥有近十年的互联网研发经验,在云计算领域具有丰富的经验。此前,曾任职于腾讯,分别负责海量云存储系统、海量CDN系统以及微信支付、彩票系统的性能优化等工作。

  本次主要为大家解析UCloud自有直播云平台架构,分析平台架构短板以及在用户规模快速增长下的架构演进过程。

  首先,介绍当下很火的直播场景。目前对直播场景的基本分类主要有媒体&活动直播、游戏直播、秀场直播和社交直播。

  特点:单向,无交互,流数少,延迟容忍度高 10s;包含电视转流、演唱会直播等。

  特点:单向,无交互,流数多,延迟容忍度高 5s;目前国内CDN产商抢得最激烈的一块。

  本身的业务场景其实并不需要那么低的延迟。延迟是2秒、5秒还是10秒其实对体验的影响不是十分大。不过由于竞争激烈,拉高了延迟门槛。

  特点:单向,文字交互,流数量多,延迟容忍度低 2~5s;这个是目前大家都能看得到盈利模式的一种。除了主播在播外,观众可以点赞,文字,送礼物,有一定的交互性。所以对直播的延迟要求苛刻,越低越好。推流主要是专业主播PC端,流数量多。

  此类直播也称为美女秀场,市场上存在大大小小公司,基本带宽在1~5G。 秀场平台非常多。

  特点:单向,文字交互,流数量非常多,延迟容忍度低 2~5s;社交直播和秀场直播,在交互上类似,区别比较大有两点:1. 秀场一般都是有限的主播把内容运营起来,推流的数量较少,一般是100路;2. 社交直播是路人即可产生内容,所以直播的流数会上升到1000,甚至10000。

  目前最火的一块,有映客,在直播,花椒等。整体直播云的设计是以满足技术及并发要求最高的社交直播需求为主要目标。

  要完成这类直播产品,需要有哪些模块支撑?通常包括直播内容采集、直播后台系统和直播内容播放三个模块。

  内容采集:采集的方式有很多,从一般几十块PC摄像头到几十万的专业录制编码设备,还有移动端的手机前后置摄像头;分布式推流:这里是比较成熟的架构,用户在推流之前会通过名字服务,一般是DNS智能解析或是自有按IP调度系统获取最靠谱的推流节点,然后把流上传到服务器。

  直播后台系统:在分布式推流节点“接入”了用户流之后,后续一系列的分发、转码、截图、录制、存储等构成了直播后台系统;这里根据不同的业务需求,需要有不同的后台服务来支撑。

  直播内容播放:这个就比较好理解了,一般输出是PC屏幕、手机、现在还有VR头盔。

  直播云的云化,主要是解决了视频流 上传、处理和分发 的一系列问题。用户只需要实现采集和播放即可。

  直播云最核心、难度最大的部分是直播的流分发网络的架构和分发算法设计,直接决定了整套服务可支撑的并发数和质量以及服务成本。

  以下重点分析UCloud核心分发网络这块的设计和演进。直播云架构主要有核心的流分发网络、运营子系统和业务逻辑子系统三大部分构成。

  调度系统:实现直播索引及调度的能力,主要解决三个问题:用户去哪个IP推流?流如何分发?用户去哪个IP观看?

  监控系统:实时监控整套分发体系的上行压力、下行压力、中间网络质量及服务状态等。

  实时转码:是一个集群,作用是在用户推流码率较高(比如720P)、但是会有移动端观看的用户时,需要实时转成360P低清晰度的流;这个子系统实际服务能力非常有限,一台8核设备只能实时转10 路流,如果来1000路,就需要100台。这里给一个重要经验:如果做不到按流的按需实时转码,建议不要搭建实时转码集群。因为成本极高!

  那么,庞大复杂的直播云背后,核心架构的挑战到底有哪些呢?以下介绍一下UCloud直播云最核心直播流的分发网络架构的演进。

  高并发,高上行,高在线亿中国人已经离不开在线倍 ,每人每天花近一个小时用于在线年,有效使用时长更是增长15倍 ;不同于传统的CDN分发模型,直播是流式的数据,主播产生内容、云服务进行实时的处理和分发,对上行的带宽和质量要求也非常高。以最近融资的映客为例,同时在线 。

  透过我们对大量直播客户的带宽观察发现,直播的高峰期集中在晚上22点~0点,产品以“你丑你先睡,我美我直播”为宣言,在此期间的带宽是平时的5~10倍。

  传统的视频点播,有一个源站,一份文件可以在发布的前一天把文件分发到离观众最近的节点,上行哪怕再慢些也无所谓,在直播的场景,越来越多的交互形式,需要实时把直播内容尽可能快且稳定的传输到观众端。

  使用多线BGP进行全国覆盖,凭借BGP技术解决解决了多运营商间转播的问题,电信主播、移动观看也流畅,同时也能兼顾到一些小运营商。

  对于中小型的UGC 产品来说,带宽上已够用了。但是BGP的瓶颈仍然存在,并且合作CDN的质量不可控。下行的延迟起到了一定的优化,但和行业最优还有不小的距离。于是又诞生了V2.0。

  架构V2.0 对于架构V1.5 来说, 单路流的成本其实是有上涨,但是质量上起到不小的优化。在V2.0 中我们也对BGP进行了带宽扩容以应对业务增长。

  整套架构由BGP、三通机房、OC机房和合作CDN构成,中间的转发策略和链路非常多,需要通过主播所在地域、观众所在地域,热度、质量、成本的折中来实时调整分发的路由。

  前期静态纯人工路由维护,运维压力非常大,多路由容灾后起码节省了30%的故障处理人力。

  分级:单IP、单OC、三通点、BGP、合作CDN 的故障处理算法略有区别,通过对负载数据的线性规划算法,可以求出成本和负载最优,风险最低的负载均摊调度算法。

  Q2:负载均衡跨机房分摊有没有什么具体指标呢?动态变化多吗?如果发生动态变化,一般需要多少时间去处理?

  Q8:实时转码:一台8核设备只能实时转10 路流,这里是用的cpu核?实时转码需求大吗?

  Q9: 目前我知道的CDN延迟都在5s左右,厉害的到2s。既然这是使用了CDN,如何做到40-100ms的延迟的?

  Q10:关于推流。如果客户端源从摄像头到如ppt类的切换,那么推流方式有在技术上何不同?如何完成从摄像头到个人PC桌面内容的切换推流。

  Q11: 关于播放。如果不是m3u8(不知道有没有记错),安卓客户端要如何播放?

  Q12:如果通过微信公众号接入直播服务,是否需要特定的页面与cdn推流及播放对接?这是否需要写一个播放页出来?