共计 5975 个字符，预计需要花费 15 分钟才能阅读完成。
本文由网易云信技术团队分享，原题“如何保障一场千万级大型直播？”，有订正和改变。
1、引言
本文以 TFBOYS“日光旅行”七周年这场直播演唱会为案例，为你分享大型直播零碎后端架构设计的方方面面，包含：根本架构、稳定性保障、安全性障、监控报警、应急预案等技术领域。
案例中的这次演唱会采纳了在线实时互动及演唱会现场的多场景导播切换，提供了主机位和三个艺人专属机位流，同时每个机位流实时转码四个清晰度档位，用户能够依据爱好抉择本人想看的内容。这场演唱会最高同时在线人数达 78.6 万，突破线上付费演唱会世界记录。
学习交换：
- 挪动端 IM 开发入门文章：《新手入门一篇就够：从零开发挪动端 IM》
- 开源 IM 框架源码：https://github.com/JackJiang2…
（本文同步公布于：http://www.52im.net/thread-38…）
2、本文作者
费曼：网易智企服务端开发工程师。硕士毕业于华中科技大学电信系，2016 年退出网易云信，热衷于大规模分布式系统和音视频相干技术，爱好文学、体育和电影。
3、架构方面
3.1 根本
上图是该次 TFBOYS 在线演唱会的直播媒体架构简图。
能够看出一场大型流动直播涵盖的技术计划点十分庞杂，本节接下来的内容咱们将以推拉流链路、全局智能调度、流量精准调度以及单元化部署，对这套直播计划做一个开展介绍。
3.2 推拉流链路
如上图所示，直播技术架构，分为几大部分：
1）视频直播核心（LMS——Live Manage Service）：负责直播流的逻辑治理和操作控制，包含存储和下发实时转码、加密等媒体解决的配置信息；
2）实时互动直播服：由连麦互动和直播两局部组成，主播和连麦者的音视频数据在互动直播高性能服务器合成为一道流后推流到直播流媒体服务器；
3）直播源站服务（LSS——Live Source Service）：网易云信自建的直播流媒体服务器节点，联合全局智能调度零碎，提供第一公里的最佳链路抉择，同时交融反对接入多家 CDN 厂商；
4）媒体解决服务（MPS——Media Processing Service）：提供实时水印、实时转码、媒体数据加密等弱小的流媒体解决能力；
5）交融 CDN 与全局智能调度（GSLB——Golabal Server Load Balancing）：提供麻利智能的 CDN 调度策略和调配算法，联合全链路、端到端的流媒体管制，来达到最终端侧低劣的用户体验；
6）客户端 SDK：提供推流、拉流以及上下行的调度能力，便于用户疾速接入应用网易云信平台一站式的音视频解决方案。
3.3 交融 CDN 与智能调度
这是一个端到端的服务，通过平台的 SDK 执行一个相似 HTTPDNS 的调度，来做到真正依据用户 IP 做就近的接入。
针对国内绝对简单的运营商网络环境，在直播上行方面通过 BGP 网络以及与相干运营商在网络接入方面的单干，可能更加精准地管制网络链路的抉择。
而对于上行，也提供了播放端的 SDK 接入，通过端到端的调度策略就近抉择适合的上行链路。
调度的准确性以及最终成果，依赖及时精确的数据撑持。
咱们有一个全链路、平面的数据监控体系，一方面利用 CDN 上的一些实时日志，另一方面联合自建节点、客户端侧上报收集链路上探测的数据，而后整合做一个实时计算来撑持整个调度的策略。
交融 CDN 计划，通过调度、监控、高可用等技术和伎俩来解决 CDN 网络方面的问题。然而对于技术人员来说，就和在应用一个传统的 CDN 网络一样没有大的差别，这些技术细节对技术人员通明无感知。
3.4 流量精准调度
大型演唱会直播流动，尤其是正式开播时的进场阶段，突发流量峰值会十分高，这就须要实时精准的智能调度策略。
交融 CDN 的智能调度蕴含两大部分：CDN 调配调度和节点调度。
节点调度：比拟常见的是 DNS 协定解析调度和 IP 调度（302/HTTPDNS）。前者因为 DNS 协定起因，调度失效工夫较慢，而后者则能够做到申请级别的调度，也就是反对任意比例的负载平衡，更加及时精准。在咱们的智能调度的场景里，失常状况下会遵循 IP 调度，在 IP 调度解析失败时，客户端上会启动 loacl DNS 解析逻辑，两者的联合确保了调度的精准和稳固牢靠。
Don’t put all your eggs in one basket.
“永远不要将鸡蛋放在同一个篮子里”。
从危险管控的角度来说：大型流动保障的 CDN 厂商资源，通常没法通过一家 CDN 资源进行满足。交融 CDN 计划则是将多家 CDN 厂商进行整合与流量调配调度。
通常在一次大型直播中，多家 CDN 厂商提供的容量（区域带宽、最高带宽）、品质会各不相同。咱们则是通过动静调整调度比例，在确保不超过最大带宽的前提下，精确化按比例调配流量，以及尽可能地确保体验。
咱们设计了一套针对 CDN 厂商的打分算法：影响因子蕴含以后带宽、保底带宽、最大带宽、带宽预测、带宽品质。
算法遵循以下准则：
1）没超保底的带宽，比超过保底的带宽，得分更高；
2）没超保底的时候，残余保底和残余总带宽越大，得分更高；
3）超过保底的时候，残余总带宽越大、品质越好，得分更高。
各 CDN 的分数之比决定了调度比例，CDN 打分算法是在继续地迭代更新计算，最大化调配应用各家 CDN 的带宽，而后再调配各家 CDN 厂商的保障之外的资源。同时优先选择品质较好的厂家，防止单价 CDN 厂商超调配。
3.5 单元化部署
下面所说，在大型直播流动中，短时间大量涌入的用户申请，对以全局智能调度服务为主的相干非媒体流链路利用，也提出了更高的并发解决挑战。
除了上行的推流链路咱们做了主备两个单元的部署，非媒体数据链路上的服务也采纳了单元化的部署计划。
在此部署计划下，可用性做到任意单元机房故障，不影响整体可用性，即异地多活。
单元化部署遵循以下准则：
1）单元化的依赖也必须单元化（外围业务）；
2）单元化粒度为利用，非 api；
3）单元化技术栈对利用尽量避免产生侵入性。
如上图所示：非单元化的业务部署在主机房，单元化的业务则部署在主机房和单元机房。
4、稳定性保障
4.1 上行链路稳固
超大型直播计划最外围的诉求就是直播稳定性，上面咱们将以该次在线演唱会为案例，重点论述一下直播的全链路稳定性架构。
上图是咱们直播的媒体流链路示意简图：整体计划能够接受任何单节点、单线路、单机房网络进口的故障。
如直播源站局部：采纳了多线策略收流，蕴含机房专线和 4G 背包计划，一主一备两个线路。同时每个单元的源站集群都有 4 层负载平衡，一台机器宕机不会影响整体可用性。LMS、LSS、MPS 都是跨机房部署，所有服务模块都可配置专有资源池供应用，保障不会受其余租户影响。
整个推流链路：采纳双路热流、互为主备，且部署上是相互独立的两个单元，能做到反对 Rack 级别的故障灾备。双路热流实现了主动主备切换，端上无需专门增加应用层的线路切换逻辑。当任何一个链路呈现问题的时候，观众的直播流不会受到影响，端上均匀卡顿感知工夫在 1s 以内。
除了推流链路的整体主备单元容灾，每个单元的服务自身也会有容灾伎俩。比方 UPS 接入，能够承受 30min 的供电故障，比方当实时互动流呈现问题时，导播台会推垫片流以保障链路数据不中断。
4.2 上行链路稳固
在访次直播流动中，全局智能调度服务会接受较大的峰值压力，在单元化部署的根底上，咱们通过多轮压测和性能调优，模型上可撑持千万级用户在半分钟内全副进入直播间。
除了上述对于推流链路的高可用，上行链路也有相干的容灾策略。当 GSLB 智能调度服务整体不可用，在客户端 SDK 预埋了交融 CDN 的 local DNS 灾备逻辑与比例配置，将云端的全局智能调度 fail-over 到客户端的本地兜底调度，并放弃大数据统计层面的各 CDN 厂商的流量调配平衡。
同时：客户端也会有播放体验方面的容灾策略，诸如清晰度降级、线路调整等。
5、安全性保障
除了直播全链路的稳固之外，直播平安也很重要。
该次直播流动中，为 TFBOYS 流动链路多环节都提供了平安保障机制（如防盗链鉴权、IP 黑白名单、HTTPS 等能力），以及地区、运营商等上行调度的动静限度，实现全链路平安保障。
在此基础上：此次流动采纳了端到端的视频流数据加密。
直播场景的加密有几点根本要求：压缩比不变、实时性和低计算复杂度。
除此之外：在交融多 cdn 的计划背景下，视频流的加密必须思考到 CDN 厂商的兼容性。
比方须满足以下要求：
1）不毁坏流媒体协定格局、视频容器格局；
2）metadata/video/audio tag 的 header 局部不加密；
3）对于 avcSequenceHeader 和 aacSequenceHeader tag 整体不加密。
具体加密算法，能够采纳一些流式加密算法，这里咱们不再赘述。
6、监控与报警
6.1 概述
一场大型直播将会有大量的计算节点参加，除了媒体数据处理与散发的各个服务器节点，还有散布在国内外的海量客户端。
咱们对网络链路、服务节点、设施端的衰弱与品质感知，都离不开数据监控零碎。
同时：咱们在现有零碎无奈主动 fail-over 的故障场景下，须要人工预案染指，而后者的决策判断，也强依赖于欠缺的全链路数据品质监控与报警零碎。
6.2 全链路监控
整个直播链路的监控蕴含了：
1）上行推流链路的流品质；
2）媒体流实时转码解决；
3）端上播放品质；
4）智能调度零碎的可用性；
5）业务量水位等相干监控数据。
上行链路常见的 QoS 指标有：帧率、码率、RTT 等，其维度蕴含主备线路、进口运营商、CDN 厂商节点等。
端上的 QoS 指标则蕴含了：拉流成功率、首帧时长、卡顿率、httpdns 缓存命中率，维度则笼罩蕴含 CDN 厂商、国家、省份、运营商、直播流、清晰度档位、客户端等。
此次直播中：内容上反对了多种机位流以及多个清晰度的转码输入流，同时通过多个 CDN 厂商进行散发，咱们把上行链路中节点的码率、帧率，直观地通过 N 个指标卡集中展现在单个大盘页面上，并且通过减少预警值进行异样显示和弹窗音讯告警。流动作战室现场，咱们采纳了多个大屏展现，十分直观地展示以后主备双推流链路的实时帧率、码率等状况，为现场地指挥保障提供了弱小的数据决策撑持。
以下图为例：蓝色示意上行帧率，绿色示意失常的上行码率，红色示意码率值过低，N/ A 示意以后没有上行推流数据。
而在上行播放链路中，比拟罕用的指标就是卡顿率。
上面是咱们对卡顿相干的形容：
1）一次卡顿：播放器继续 2s 产生缓冲区空，即播放器 2s 没有拉到流；
2）一分钟用户卡顿：1 分钟窗口内，用户只有卡顿一次，则该用户计作卡顿用户；
3）一分钟用户卡顿率：1 分钟窗口内，卡顿用户数 / 总的用户数；
4）一分钟用户零卡顿率：1 分钟窗口内，(总的用户数 – 卡顿用户数)/ 总的用户数。
为什么会抉择用户卡顿率这个指标，而不是应用整体的卡顿采样点 / 总采样数呢？
是因为：咱们更想看到有多少用户没有呈现过卡顿景象，这更能直观体现优质网络的整体占比。通过对各省份用户零卡顿率、用户数排行，以及各省用户卡顿率的察看，咱们能够十分直观地找到卡顿重大的地区，以便重点关注，进行资源调度优化。
7、应急预案
任何一个零碎，无论你号称它被设计得如许强壮，它依然会有故障工夫的存在。
硬件故障、软件 bug、人为操作失误等等，这些都无可避免地存在着。他们未必是一个必须多少工夫内将其彻底解决的问题，他们是咱们必须认清并承受共存的一个事实。
所以：预案治理是大型直播流动保障中不可短少的一环。
咱们遵循以下的预案准则：
1）预案信息明确：大盘主动监控不具备二义性，确保预案信息起源正确，触发执行预案的条件明确且有数值化束缚；
2）预案操作简洁：所有的预案操作都有有简洁明确 (开关型) 的操作输出；
3）预案操作平安：所有预案要通过充沛预演，同时预演操作自身须要有明确的确认机制，以确保在失常状况下不会被误触发；
4）预案影响验证：明确理清预案操作的影响，QA 在预演阶段须要对相干影响进行充沛验证。
此次流动的后期筹备中，咱们总计进行了 3 次直播全链路的拟真演练，以及 2 次联结互动现场、导播台现场的流动全流程级别的彩排，另外进行了大大小小总计数十次的各类危险预案演练。所有演练过程中发现的问题，都会进行专项解决。
危险预案这块，蕴含了各类资源故障、上下行链路品质、地区性网络故障、CDN 异样流量水位等在内的场景应答。其中资源故障蕴含了机器宕机、机架整体断电、重叠交换机宕机、机房外网进口不可用，咱们均进行了危险预案演练笼罩。
上面列举几点直播解决方案中的局部预案机制：
1）如果因为误操作等导致非正常解密等，可在推流不中断的状况下，动静停止流加密，客户端无任何感知影响；
2）某家 cdn 在某地区运营商呈现大面积故障瘫痪，该地区相应运营商线路的 QoS 指标会大幅度降落并触发报警，将故障 cdn 在该地区运营商进行黑名单解决，动静进行对其的调度，将流量调度至失常提供服务的 cdn 厂商；
3）在两路热流均失常的状况下，然而正在散发的一路呈现品质问题，计划可反对手动触发主备切换，让监控数据品质更好的另一路流参加散发，客户端感知工夫在 1s 以内；
4）因为一些不可抗因素，某机房呈现大面积故障整体不可用，触发链路报警，此时咱们会紧急将流切至另一机房，故障感知与复原的工夫在一分钟内。
8、相干文章
[1] 挪动端实时音视频直播技术详解（一）：开篇
[2] 挪动端实时音视频直播技术详解（二）：采集
[3] 挪动端实时音视频直播技术详解（三）：解决
[4] 挪动端实时音视频直播技术详解（四）：编码和封装
[5] 挪动端实时音视频直播技术详解（五）：推流和传输
[6] 挪动端实时音视频直播技术详解（六）：提早优化
[7] 淘宝直播技术干货：高清、低延时的实时视频直播技术解密
[8] 爱奇艺技术分享：轻松滑稽，解说视频编解码技术的过来、当初和未来
[9] 零根底入门：实时音视频技术基础知识全面盘点
[10] 实时音视频面视必备：疾速把握 11 个视频技术相干的根底概念
[11] 网易云信实时视频直播在 TCP 数据传输层的一些优化思路
[12] 浅谈实时音视频直播中间接影响用户体验的几项要害技术指标
[13] 首次披露：快手是如何做到百万观众同场看直播仍能秒开且不卡顿的？
[14] 直播零碎聊天技术(一)：百万在线的美拍直播弹幕零碎的实时推送技术实际之路
[15] 直播零碎聊天技术(二) 阿里电商 IM 音讯平台，在群聊、直播场景下的技术实际
[16] 直播零碎聊天技术(三)：微信直播聊天室单房间 1500 万在线的音讯架构演进之路
[17] 直播零碎聊天技术(四)：百度直播的海量用户实时音讯零碎架构演进实际
[18] 直播零碎聊天技术(五)：微信小游戏直播在 Android 端的跨过程渲染推流实际
[19] 直播零碎聊天技术(六)：百万人在线的直播间实时聊天音讯散发技术实际
[20] 直播零碎聊天技术(七)：直播间海量聊天音讯的架构设计难点实际
（本文同步公布于：http://www.52im.net/thread-38…）
