本文根据4月26日，UCloud流媒体开发总监虚拟甜瓜对“〖KVM社区UCloud技术wechat”组在线共享内容进行整理。 欢迎分享“KVM社区UCloud〗”在线系列
注意：每个体系结构都有一定的参考价值。 UCloud将邀请现场直播、拥抱直播、Shou.tv以及一起玩技术的技术专家，分享海量服务架构探索中的技术实践。
如果您感兴趣，请单击文章末尾的“阅读原文”，或者将以下链接复制到浏览器中打开，然后参加活动。
3358格式. Mike CRM.com/0 whn1k # rd
讲师介绍
虚拟甜瓜
云流媒体开发总监
主要负责UCloud视频云和CDN产品的开发。 拥有近10年的互联网研发经验，在云计算领域拥有丰富的经验。 此前，他曾在腾讯工作，负责屏蔽云存储系统、海量存储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核心分发网络这一设计和演化。 实时云体系结构主要由核心流媒体分发网络、运营子系统和业务逻辑子系统三大部分组成。
c1?from=pc">运营子系统包括了调度系统、监控系统和故障处理系统。
调度系统：实现直播索引及调度的能力，主要解决三个问题：用户去哪个IP推流？流如何分发？用户去哪个IP观看？
监控系统：实时监控整套分发体系的上行压力、下行压力、中间网络质量及服务状态等。
故障处理系统：负责IP、机房、片区网络不可用时的处理。
业务子系统包含了非常多的系统，这里列举几个常见的。
实时转码：是一个集群，作用是在用户推流码率较高（比如720P）、但是会有移动端观看的用户时，需要实时转成360P低清晰度的流；这个子系统实际服务能力非常有限，一台8核设备只能实时转10 路流，如果来1000路，就需要100台。这里给一个重要经验：如果做不到按流的按需实时转码，建议不要搭建实时转码集群。因为成本极高！
实时截图：架构和实时转码类似，一般单机可处理100 流。
实时录制：即将直播内容实时保存下来存储成点播文件。
核心架构演进
那么，庞大复杂的直播云背后，核心架构的挑战到底有哪些呢？以下介绍一下UCloud直播云最核心直播流的分发网络架构的演进。
直播流的分发网络主要挑战：
高并发，高上行，高在线。
5亿中国人已经离不开在线娱乐，2006年-2015年，月度覆盖人数增长5倍 ，每人每天花近一个小时用于在线娱乐，2007年到2014年，有效使用时长更是增长15倍 ；不同于传统的CDN分发模型，直播是流式的数据，主播产生内容、云服务进行实时的处理和分发，对上行的带宽和质量要求也非常高。以最近融资的映客为例，同时在线主播10000 ，观众50000 。
对比于传统的CDN，这里有个重要的架构考虑是需要支撑高上行的带宽。
热点时间集中直播流的分发网络。
透过我们对大量直播客户的带宽观察发现，直播的高峰期集中在晚上22点~0点，产品以“你丑你先睡，我美我直播”为宣言，在此期间的带宽是平时的5~10倍。
带宽成本高。
上行带宽，下行带宽，中间转发的带宽，总体带宽成本非常高。
分发质量要求高。
传统的视频点播，有一个源站，一份文件可以在发布的前一天把文件分发到离观众最近的节点，上行哪怕再慢些也无所谓，在直播的场景，越来越多的交互形式，需要实时把直播内容尽可能快且稳定的传输到观众端。
总结：这可能是迄今为止最难设计的分发网络。
核心架构演进
直播云最核心的架构－直播流的分发网络经历了三次大演进。
V1.0 版本——一级DC
使用多线BGP进行全国覆盖，凭借BGP技术解决解决了多运营商间转播的问题，电信主播、移动观看也流畅，同时也能兼顾到一些小运营商。
全国延迟区间在40ms~100ms；部分地区用户网离BGP距离长，路由极易不稳定，高峰期容易卡顿。
由于成本较高，在zzdxhd期仅支持4000路上下行，能满足较小规模的直播客户，并且需要设置较大的播放缓存来对抗网络丢包和延迟，直播内容延迟高。
容灾方面，单机房无异地容灾，遇到光纤挖断，机房变更等会是致命打击。
V1.5版本——高突发架构
高突发架构：引入了CDN供应商到架构中，快速优化下行瓶颈的问题，下行容量增大N倍，基本不成为瓶颈；
流转推：将热门主播推流到合作CDN进行分发，从架构层面看，是同一分出流量进行了多份的复制；
DNS智能解析：使用智能解析DNS按运营商、省份、用户比例将播放带宽切到CDN供应商。
对于中小型的UGC 产品来说，带宽上已够用了。但是BGP的瓶颈仍然存在，并且合作CDN的质量不可控。下行的延迟起到了一定的优化，但和行业最优还有不小的距离。于是又诞生了V2.0。
V2.0 版本——两级DC＋OC架构
架构优化：引入离用户最近的OC小机房，推流端也通过DNS智能解析的方式，将上行分散到各个OC点。
质量上，OC到BGP机房的路由是可控的，进行针对优化，拉城域或区域专线，流分发稳定性非常高，已可支持1秒播放buffer，整体的直播延迟最低可以做到1秒。
瓶颈：由于仍要通过BGP对跨运营商的流做中转，所以上行瓶颈问题没有得到解决。
缺点：BGP的分发带宽上升，对于不活跃的主播，从BGP 1 to N 的形式， 演变成 1 to M to N，在调度上需要算法来决策是否要下行放到OC上。
容灾能力：BGP机房仍然是链路单点。
架构V2.0 对于架构V1.5 来说， 单路流的成本其实是有上涨，但是质量上起到不小的优化。在V2.0 中我们也对BGP进行了带宽扩容以应对业务增长。
V3.0 版本
目前最新的架构V3.0，引入了区域三通点，为BGP机房做容灾，对于同一区域如都在华东的推流和分发，直接走区域三通机房，BGP机房和三通机房部署多个，故障是只要调整路由即可。
三级多通架构
架构优化：引入区域三通点，为BGP机房做容灾，对于同一区域如都在华东的推流和分发，直接走区域三通机房，BGP机房和三通机房部署多个，故障是只要调整路由即可。
分发策略：对同区域的同运营商的OC先进行分发，如广东电信有10个OC机房，如果推流和播放是发生在这10份机房内，就可以完全不经过BGP和三通点，降低了BGP和三通架构上的带宽瓶颈。
整套架构由BGP、三通机房、OC机房和合作CDN构成，中间的转发策略和链路非常多，需要通过主播所在地域、观众所在地域，热度、质量、成本的折中来实时调整分发的路由。
两级多路由回源容灾
除了引入三通点外，还做了一些容灾设计，这里介绍一个典型的多路由容灾。
客户端到接入OC：使用DNS做负载均衡，同时配置多个OC节点的IP，降低单点故障影响，同时监控单线路如广东电信配置是否存在单点。
OC回源：使用自有索引体系管理路由，为每个OC节点至少分配两个以上的回源路由，并实时监控上报各个oc回源质量与各中转节点负载信息。
前期静态纯人工路由维护，运维压力非常大，多路由容灾后起码节省了30%的故障处理人力。
故障自动处理
对于庞大数量的机房，故障的处理也不容易，比如一个机房IP down了，人工判断如何迁移 IP的带宽 是可以的，如果是一个OC机房或三通机房，纯靠人工计算带宽和配置，就很容易出错。
所以有了直播云非常重要的一个故障处理模块： 带宽、负载动态路由规划系统。
分级：单IP、单OC、三通点、BGP、合作CDN 的故障处理算法略有区别，通过对负载数据的线性规划算法，可以求出成本和负载最优，风险最低的负载均摊调度算法。
故障负载均摊优先级：
均摊负载到 同一OC机房，这样负载均摊就控制在机房内；
将负载均摊到相邻同省份机房，负载问题控制在省内消化；
将负载均摊到区域机房，区域内消化；
将负载均摊到合作CDN；
将负载均摊到三通、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产品技术实践
欢迎报名：云计算存储技术峰会.成都站
加速会：加速你对世界的理解，内幕全在这里！请关注加速会微信公号：jiasuhuihao
加速会主编微信：leaderweb