[转]直播云平台架构如何构建？附PPT

悠悠 2022-09-23 03:38 106阅读 0赞

来源：http://mt.sohu.com/20160505/n447773387.shtml

> 　　本文根据4月26日 UCloud流媒体研发总监曾凯源于〖KVM社区&UCloud技术微信群〗线上分享内容整理而成。欢迎关注〖KVM社区 & UCloud〗线上系列分享

![83e07f16fb1f41c1b01d4161e6a45d48_th.jpg][]

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

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

http://form.mikecrm.com/0Whn1K\#rd

讲师介绍

![d0457fda404b4108a060d8b05e81a76c_th.jpg][]

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

演讲提纲

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

![a3fe8c30e2274ec0961b43e4bbe6f8df_th.jpg][]

1.  直播场景简介
2.  直播云架构
3.  核心架构演进
4.  容灾及故障处理

直播场景&直播服务架构

直播场景

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

![ded65970b0494ec8a9f5880c3620628b_th.jpg][]

媒体&活动直播

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

这类目前对于直播的技术要求较低，低上行，高下行。

游戏直播

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

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

秀场直播

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

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

社交直播

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

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

直播服务架构解析

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

![c29bc5f76176440cbcb691f97e77af8d_th.jpg][]

1.  内容采集：采集的方式有很多，从一般几十块PC摄像头到几十万的专业录制编码设备，还有移动端的手机前后置摄像头；分布式推流：这里是比较成熟的架构，用户在推流之前会通过名字服务，一般是DNS智能解析或是自有按IP调度系统获取最靠谱的推流节点，然后把流上传到服务器。
2.  直播后台系统：在分布式推流节点“接入”了用户流之后，后续一系列的分发、转码、截图、录制、存储等构成了直播后台系统；这里根据不同的业务需求，需要有不同的后台服务来支撑。
3.  直播内容播放：这个就比较好理解了，一般输出是PC屏幕、手机、现在还有VR头盔。

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

直播云架构

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

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

![5aabbae5af854669b5821a4d1ab45abb_th.jpg][]

运营子系统包括了调度系统、监控系统和故障处理系统。

1.  调度系统：实现直播索引及调度的能力，主要解决三个问题：用户去哪个IP推流？流如何分发？用户去哪个IP观看？
2.  监控系统：实时监控整套分发体系的上行压力、下行压力、中间网络质量及服务状态等。
3.  故障处理系统：负责IP、机房、片区网络不可用时的处理。

业务子系统包含了非常多的系统，这里列举几个常见的。

1.  实时转码：是一个集群，作用是在用户推流码率较高（比如720P）、但是会有移动端观看的用户时，需要实时转成360P低清晰度的流；这个子系统实际服务能力非常有限，一台8核设备只能实时转10 路流，如果来1000路，就需要100台。这里给一个重要经验：如果做不到按流的按需实时转码，建议不要搭建实时转码集群。因为成本极高！
2.  实时截图：架构和实时转码类似，一般单机可处理100 流。
3.  实时录制：即将直播内容实时保存下来存储成点播文件。

核心架构演进

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

![30e54a3704dc4efa9fd44b4fcb0470c2_th.jpg][]

直播流的分发网络主要挑战：

*  高并发，高上行，高在线。
    
    　　5亿中国人已经离不开在线娱乐，2006年-2015年，月度覆盖人数增长5倍 ，每人每天花近一个小时用于在线娱乐，2007年到2014年，有效使用时长更是增长15倍 ；不同于传统的CDN分发模型，直播是流式的数据，主播产生内容、云服务进行实时的处理和分发，对上行的带宽和质量要求也非常高。以最近融资的映客为例，同时在线主播10000 ，观众50000 。
    
    　　对比于传统的CDN，这里有个重要的架构考虑是需要支撑高上行的带宽。
 *  热点时间集中直播流的分发网络。
    
    　　透过我们对大量直播客户的带宽观察发现，直播的高峰期集中在晚上22点~0点，产品以“你丑你先睡，我美我直播”为宣言，在此期间的带宽是平时的5~10倍。
 *  带宽成本高。
    
    　　上行带宽，下行带宽，中间转发的带宽，总体带宽成本非常高。
 *  分发质量要求高。
    
    　　传统的视频点播，有一个源站，一份文件可以在发布的前一天把文件分发到离观众最近的节点，上行哪怕再慢些也无所谓，在直播的场景，越来越多的交互形式，需要实时把直播内容尽可能快且稳定的传输到观众端。

总结：这可能是迄今为止最难设计的分发网络。

核心架构演进

直播云最核心的架构－直播流的分发网络经历了三次大演进。

V1.0 版本——一级DC

![ced603e9d1694945844b3ae36ef78770_th.jpg][]

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

1.  全国延迟区间在40ms~100ms；部分地区用户网离BGP距离长，路由极易不稳定，高峰期容易卡顿。
2.  由于成本较高，在最初期仅支持4000路上下行，能满足较小规模的直播客户，并且需要设置较大的播放缓存来对抗网络丢包和延迟，直播内容延迟高。
3.  容灾方面，单机房无异地容灾，遇到光纤挖断，机房变更等会是致命打击。

V1.5版本——高突发架构

![153e133be1764256a5ae7b77aea0e0b7_th.jpg][]

1.  高突发架构：引入了CDN供应商到架构中，快速优化下行瓶颈的问题，下行容量增大N倍，基本不成为瓶颈；
2.  流转推：将热门主播推流到合作CDN进行分发，从架构层面看，是同一分出流量进行了多份的复制；
3.  DNS智能解析：使用智能解析DNS按运营商、省份、用户比例将播放带宽切到CDN供应商。

![3aca27d4396b4413afa7d0cad2111c65_th.jpg][]

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

V2.0 版本——两级DC＋OC架构

![459b38da80f64815bf2c0f06dd1ee220_th.jpg][]

1.  架构优化：引入离用户最近的OC小机房，推流端也通过DNS智能解析的方式，将上行分散到各个OC点。
2.  质量上，OC到BGP机房的路由是可控的，进行针对优化，拉城域或区域专线，流分发稳定性非常高，已可支持1秒播放buffer，整体的直播延迟最低可以做到1秒。
3.  瓶颈：由于仍要通过BGP对跨运营商的流做中转，所以上行瓶颈问题没有得到解决。
4.  缺点：BGP的分发带宽上升，对于不活跃的主播，从BGP 1 to N 的形式， 演变成 1 to M to N，在调度上需要算法来决策是否要下行放到OC上。
5.  容灾能力：BGP机房仍然是链路单点。

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

V3.0 版本

目前最新的架构V3.0，引入了区域三通点，为BGP机房做容灾，对于同一区域如都在华东的推流和分发，直接走区域三通机房，BGP机房和三通机房部署多个，故障是只要调整路由即可。

三级多通架构

![c85f8d95eeb8495ca7a2dc57b42e3f21_th.jpg][]

架构优化：引入区域三通点，为BGP机房做容灾，对于同一区域如都在华东的推流和分发，直接走区域三通机房，BGP机房和三通机房部署多个，故障是只要调整路由即可。

1.  分发策略：对同区域的同运营商的OC先进行分发，如广东电信有10个OC机房，如果推流和播放是发生在这10份机房内，就可以完全不经过BGP和三通点，降低了BGP和三通架构上的带宽瓶颈。

![c26abd46fd7540faa6df0a611e9c496f_th.jpg][]

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

两级多路由回源容灾

除了引入三通点外，还做了一些容灾设计，这里介绍一个典型的多路由容灾。

![17b984033b5c428a8bcd531fa6cb64fb_th.jpg][]

1.  客户端到接入OC：使用DNS做负载均衡，同时配置多个OC节点的IP，降低单点故障影响，同时监控单线路如广东电信配置是否存在单点。
2.  OC回源：使用自有索引体系管理路由，为每个OC节点至少分配两个以上的回源路由，并实时监控上报各个oc回源质量与各中转节点负载信息。

![1c21fa38e589456199ca1ddc499e4b1d_th.jpg][]

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

故障自动处理

对于庞大数量的机房，故障的处理也不容易，比如一个机房IP down了，人工判断如何迁移 IP的带宽 是可以的，如果是一个OC机房或三通机房，纯靠人工计算带宽和配置，就很容易出错。

所以有了直播云非常重要的一个故障处理模块： 带宽、负载动态路由规划系统。

![d567e58f38f04bb3abdc7b409a3924d1_th.jpg][]

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

故障负载均摊优先级：

1.  均摊负载到 同一OC机房，这样负载均摊就控制在机房内；
2.  将负载均摊到相邻同省份机房，负载问题控制在省内消化；
3.  将负载均摊到区域机房，区域内消化；
4.  将负载均摊到合作CDN；
5.  将负载均摊到三通、BGP中转点.

这里优先级也不是必然，需要根据实际情况来动态调整。

Q&A

> 　　Q1:UCloud的多路推送怎么做的负载均衡，转码过后怎么推送出去的，另外集群调度是怎么实现的？

答：多路推送靠DNS配置多IP轮转来做负载均衡，转码过后不需要推出去，当有观众的时候再主动回来拉取。集群以DNS就近接入的方式调度。

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

答：1. 带宽，基于直播场景，其实CPU,内存不是瓶颈。2. 第二是根据实际用户直播的延迟上报数据。

动态变化不算特别多。IP 级别的容灾是自动化，5分钟左右。 OC机房的自动处理要看规模， 2G左右的机房一般能在10分钟内容完成带宽迁移。20G带宽的机房就需要人工介入，可以优先切到合作CDN 再二次决策更优的方案。

> 　　Q3:不同网络环境网络不一样的时候码率，和帧数怎样控制？

答：目前直播很少做动态码率帧率调整，一般是固定的码率和帧率。 网络质量差的情况下做动态码率，帧率的调整效果不佳，难以使直播流畅，最终用户还是会放弃。

> 　　Q4:云CDN和传统CDN方式什么区别？

答：云CDN，最大的特点是 和其他云产品如主机、存储、计算等能有机的结合起来。传统的CDN，仅负责对内容进行分发。

> 　　Q5:CDN方面目前有没有API接口，支持脚本调用不？

答：有API接口的，详细的刻可以浏览：https://docs.ucloud.cn/api-docs/ucdn-api/index.html

> 　　Q6:OC回源链路是什么？什么情况/场景下需要回源？怎么回源？

答：回源链路就是决定OC去什么地方拉直播流。OC机房当前没有用户要看的直播流时，需要往上拉流。

> 　　Q7:直播后台系统内部，底层使用什么协议？

答：上行RTMP，内部转发有RTMP协议，也有自研UDP协议，播放走RTMP/HTTP协议。

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

答：用的CPU核。要看具体场景，如果是PC推流，有手机观察的用户，转码就有需求，大屏录制转小屏观看的情况。

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

答：这里说的40-100ms的延迟是指纯网络时间，CDN延时在5s是指的直播内容级别的延迟，是由于在不同设备上的转发，各层级加上了不同大小的缓存造成，另外还有客户端录制和播放的消耗。

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

答：摄像头和PPT只是采集方式不一样，出来的两路流在播放的时候进行切换即可。 个人PC桌面内容的推流及合并可以用OBS，可以做串流处理，同时展示摄像头和屏幕内容。

> 　　Q11: 关于播放。如果不是m3u8（不知道有没有记错），安卓客户端要如何播放？

答：使用内嵌浏览器的方式即可，一般安卓都会使用librtmp之类的播放RTMP，不会播m3u8.

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

答：需要写一个简单的播放也面，只要直播服务支持HLS格式就行，公众号里面可以直接播放。

> 　　Q13: 客户端接入那个服务端是怎么做的？需要测速么？

答：从DNS或其他方式获取到具体的IP后，进行基本的PING测速选定服务器IP。

> 　　Q14: 推上来的流只有一路，怎么做到双路由回到bgp 或者三通？

答：双路由仅指在播放的时候。

下期预告

参与方式详见：

30天四场技术分享，我赌上程序员的尊严解析UCloud产品技术实践

![e26df678aa164b94886ebecd0bbeac07_th.jpg][]

[83e07f16fb1f41c1b01d4161e6a45d48_th.jpg]: /images/20220721/08c4e64a2c7a4a1dbfa7fbb7135e6c0c.png
[d0457fda404b4108a060d8b05e81a76c_th.jpg]: /images/20220721/6da5fc927d314d9cab94f776970b82da.png
[a3fe8c30e2274ec0961b43e4bbe6f8df_th.jpg]: /images/20220721/f0812524b0aa4cd19b2869535353e284.png
[ded65970b0494ec8a9f5880c3620628b_th.jpg]: /images/20220721/002bcfdd66f3457689cd5df1e1538579.png
[c29bc5f76176440cbcb691f97e77af8d_th.jpg]: /images/20220721/5955fbbf3d5b45e989749d88f1ad48ea.png
[5aabbae5af854669b5821a4d1ab45abb_th.jpg]: /images/20220721/cb688a8620004dd8bceffc140cf37caa.png
[30e54a3704dc4efa9fd44b4fcb0470c2_th.jpg]: /images/20220721/952d2d838d45458296a9707e21e2208f.png
[ced603e9d1694945844b3ae36ef78770_th.jpg]: /images/20220721/f1c355997cba49e1b63fee8f1b4daf6e.png
[153e133be1764256a5ae7b77aea0e0b7_th.jpg]: /images/20220721/24badf0bd78d452fb16c5892fe726ef0.png
[3aca27d4396b4413afa7d0cad2111c65_th.jpg]: /images/20220721/219bd801d89a4aaebff422dae4b72b89.png
[459b38da80f64815bf2c0f06dd1ee220_th.jpg]: /images/20220721/9ee023ca11d64a7b8a8e62bf09915b15.png
[c85f8d95eeb8495ca7a2dc57b42e3f21_th.jpg]: /images/20220721/ecd7798290b14768b1abbf305d732797.png
[c26abd46fd7540faa6df0a611e9c496f_th.jpg]: /images/20220721/94fbe79d48c5452a87951df2da4511d6.png
[17b984033b5c428a8bcd531fa6cb64fb_th.jpg]: /images/20220721/3beb8b70cf8e4205809b85afe2a041df.png
[1c21fa38e589456199ca1ddc499e4b1d_th.jpg]: /images/20220721/3aadb81468ed441e9117137382d3e0e8.png
[d567e58f38f04bb3abdc7b409a3924d1_th.jpg]: /images/20220721/5b4c5c97d1974d3aa1643441b9987229.png
[e26df678aa164b94886ebecd0bbeac07_th.jpg]: /images/20220721/13b87bb0bb7d4c75a52960ff592e98e5.png