直播技术干货分享：千万级直播系统后端架构设计的方方面面

本文由网易云信技术团队分享，原题“如何保障一场千万级大型直播？”，即时通讯网收录时有修订和改动。

本文以TFBOYS“日光旅行”七周年这场直播演唱会为案例，为你分享大型直播系统后端架构设计的方方面面，包括：基本架构、稳定性保障、安全性障、监控报警、应急预案等技术范畴。

案例中的这次演唱会采用了在线实时互动及演唱会现场的多场景导播切换，提供了主机位和三个艺人专属机位流，同时每个机位流实时转码四个清晰度档位，用户可以根据喜好选择自己想看的内容。这场演唱会最高同时在线人数达78.6万，打破线上付费演唱会世界记录。

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] 直播系统聊天技术(七)：直播间海量聊天消息的架构设计难点实践