如何保障一场千万级大型直播？

导读：TFBOYS“日光旅行”七周年演唱会近日成功举办，最高同时在线人数达78.6万，口碑票房双丰收。网易云信的大型直播解决方案全程支撑了网易云音乐的这场活动，本篇文章将和你们分享这场稳定、流畅、清晰的线上演唱会背后的故事。

文｜ 费曼

网易智企服务端开发工程师

8月22日，TFBOYS“日光旅行”七周年演唱会在网易云音乐平台上与广大粉丝们见面。据官方数据显示，这场演唱会最高同时在线人数达78.6万，打破线上付费演唱会世界记录，取得了口碑票房的双丰收。

这次演唱会采用了在线实时互动及演唱会现场的多场景导播切换，提供了主机位和三个艺人专属机位流，同时每一个机位流实时转码四个清晰度档位，用户能够根据喜爱选择本身想看的内容。

网易云信的大型直播解决方案，全程支撑了网易云音乐这场活动，今天咱们来聊聊一场稳定、流畅、清晰的线上演唱会背后的故事。

大型直播架构

上图是这次TFBOYS在线演唱会的直播媒体架构简图，能够看出一场大型活动直播涵盖的技术方案点很是庞杂，这里咱们先以推拉流链路、全局智能调度、流量精准调度以及单元化部署，对网易云信的大型直播方案作一个展开介绍。

推拉流链路

网易云信的大型直播技术架构，分为几大部分：

• 视频直播中心（LMS, Live Manage Service），负责直播流的逻辑管理和操做控制，包括存储和下发实时转码、加密等媒体处理的配置信息。
• 实时互动直播服务，由连麦互动和直播两部分组成，主播和连麦者的音视频数据在互动直播高性能服务器合成为一道流后推流到直播流媒体服务器。
• 直播源站服务（LSS, Live Source Service），网易云信自建的直播流媒体服务器节点，结合全局智能调度系统，提供第一千米的最佳链路选择，同时融合支持接入多家CDN厂商。
• 媒体处理服务（MPS, Media Processing Service），提供实时水印、实时转码、媒体数据加密等强大的流媒体处理能力。
• 融合CDN与全局智能调度(GSLB, Golabal Server Load Balancing)，提供敏捷智能的CDN调度策略和分配算法，结合全链路、端到端的流媒体控制，来达到最终端侧优良的用户体验。

• 客户端SDK，提供推流、拉流以及上下行的调度能力，便于用户快速接入使用网易云信平台一站式的音视频解决方案。

  融合CDN与智能调度

网易云信提供的是一个端到端的服务，经过平台的SDK执行一个相似HTTPDNS的调度，来作到真正根据用户IP作就近的接入。针对国内相对复杂的运营商网络环境，云信在直播上行方面经过BGP网络以及与相关运营商在网络接入方面的合做，可以更加精准地控制网络链路的选择。而对于下行，网易云信也提供了播放端的SDK接入，经过端到端的调度策略就近选择合适的下行链路。

调度的准确性以及最终效果，依赖及时准确的数据支撑。咱们有一个全链路、立体的数据监控体系，一方面利用CDN上的一些实时日志，另外一方面结合自建节点、客户端侧上报收集链路上探测的数据，而后整合作一个实时计算来支撑整个调度的策略。

融合CDN方案，经过调度、监控、高可用等技术和手段来解决CDN网络方面的问题，可是对于云信平台上的用户，就和在使用一个传统的CDN网络同样没有大的差别，这些技术细节对用户透明无感知，用户经过简单易用的接入sdk，就具有了高可用、全链路控制的流媒体分发服务。

流量精准调度

大型演唱会直播活动，尤为是正式开播时的进场阶段，突发流量峰值会很是高，这就须要实时精准的智能调度策略。云信融合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厂商的打分算法，影响因子包含当前带宽、保底带宽、最大带宽、带宽预测、带宽质量，算法遵循如下原则：

• 没超保底的带宽，比超过保底的带宽，得分更高
• 没超保底的时候，剩余保底和剩余总带宽越大，得分更高
• 超过保底的时候，剩余总带宽越大、质量越好，得分更高

各CDN的分数之比决定了调度比例，CDN打分算法是在持续地迭代更新计算，最大化分配使用各家CDN的带宽，而后再分配各家CDN厂商的保障以外的资源，同时优先选择质量较好的厂家，避免单价CDN厂商超分配。

单元化部署

上文所说，在大型直播活动中，短期大量涌入的用户请求，对以全局智能调度服务为主的相关非媒体流链路应用，也提出了更高的并发处理挑战。除了上行的推流链路咱们作了主备两个单元的部署，非媒体数据链路上的服务咱们也采用了单元化的部署方案。

在此部署方案下，可用性作到任意单元机房故障，不影响总体可用性，即异地多活。单元化部署遵循如下原则：

• 单元化的依赖也必须单元化（核心业务）
• 单元化粒度为应用，非api
• 单元化技术栈对应用尽可能避免产生侵入性

如上图所示，非单元化的业务部署在主机房，单元化的业务则部署在主机房和单元机房。

稳定性与安全性的保障

上行链路稳定

超大型直播方案最核心的诉求就是直播稳定性，下面咱们将以这次在线演唱会为案例，重点阐述一下网易云信大型直播的全链路稳定性架构。

上图是云信大型直播的媒体流链路示意简图，总体方案能够承受任何单节点、单线路、单机房网络出口的故障。如直播源站部分，采用了多线策略收流，包含机房专线和4G背包方案，一主一备两个线路。同时每一个单元的源站集群都有4层负载均衡，一台机器宕机不会影响总体可用性。LMS、LSS、MPS都是跨机房部署，全部服务模块均可配置专有资源池供使用，保证不会受其余租户影响。

整个推流链路采用双路热流，互为主备，且部署上是互相独立的两个单元，能作到支持Rack级别的故障灾备。双路热流实现了自动主备切换，端上无需专门添加应用层的线路切换逻辑。当任何一个链路出现问题的时候，观众的直播流不会受到影响，端上平均卡顿感知时间在1s之内。

除了推流链路的总体主备单元容灾，每一个单元的服务自己也会有容灾手段。好比UPS接入，能够接受30min的供电故障，好比当实时互动流出现问题时，导播台会推垫片流以保证链路数据不中断。

下行链路稳定

在这次活动中，全局智能调度服务会承受较大的峰值压力，在单元化部署的基础上，咱们通过了多轮压测和性能调优，模型上能够支撑千万级用户在半分钟内所有进入直播间。

除了上述关于推流链路的高可用，下行链路也有相关的容灾策略。当GSLB智能调度服务总体不可用，咱们在客户端SDK预埋了融合CDN的local DNS灾备逻辑与比例配置，将云端的全局智能调度fail-over到客户端的本地兜底调度，并保持大数据统计层面的各CDN厂商的流量分配均衡。

同时，客户端也会有播放体验方面的容灾策略，诸如清晰度降级、线路调整等。

直播内容安全

固然，除了直播全链路的稳定以外，直播安全也十分重要。这次活动中，网易云信为TFBOYS活动链路多环节都提供了安全保障机制，如防盗链鉴权、IP黑白名单、HTTPS等能力，以及地区、运营商等下行调度的动态限制，实现全链路安全保障。

在此基础上，这次活动采用了端到端的视频流数据加密，直播场景的加密有几点基本要求：压缩比不变、实时性和低计算复杂度。除此以外，在融合多cdn的方案背景下，视频流的加密必须考虑到CDN厂商的兼容性，好比须知足如下要求：不破坏流媒体协议格式、视频容器格式；metadata/video/audio tag的header部分不加密；对于avcSequenceHeader和aacSequenceHeader tag总体不加密。具体加密算法，能够采用一些流式加密算法，这里咱们再也不赘述。

**监控报警与预案
**

一场大型直播将会有大量的计算节点参与，除了媒体数据处理与分发的各个服务器节点，还有分布在国内外的海量客户端，咱们对网络链路、服务节点、设备端的健康与质量感知，都离不开数据监控系统。同时，咱们在现有系统没法自动fail-over的故障场景下，须要人工预案介入，然后者的决策判断，也强依赖于完善的全链路数据质量监控与报警系统。

全链路监控

整个直播链路的监控包含了上行推流链路的流质量、媒体流实时转码处理、端上播放质量、智能调度系统的可用性、业务量水位等相关监控数据。上行链路常见的QoS指标有帧率、码率、RTT等，其维度包含主备线路、出口运营商、CDN厂商节点等。端上的QoS指标则包含了拉流成功率、首帧时长、卡顿率、httpdns缓存命中率，维度则覆盖包含CDN厂商、国家、省份、运营商、直播流、清晰度档位、客户端等。

这次直播中，内容上支持了多种机位流以及多个清晰度的转码输出流，同时经过多个CDN厂商进行分发，咱们把上行链路中节点的码率、帧率，直观地经过N个指标卡集中展现在单个大盘页面上，而且经过增长预警值进行异常显示和弹窗消息告警。活动做战室现场，咱们采用了多个大屏展现，很是直观地展示当前主备双推流链路的实时帧率、码率等状况，为现场地指挥保障提供了强大的数据决策支撑。

如下图为例：蓝色表示上行帧率，绿色表示正常的上行码率，红色表示码率值太低，N/A表示当前没有上行推流数据。

而在下行播放链路中，比较经常使用的指标就是卡顿率。下面是咱们对卡顿相关的描述：

• 一次卡顿：播放器持续2s发生缓冲区空，即播放器2s没有拉到流
• 一分钟用户卡顿：1分钟窗口内，用户只要卡顿一次，则该用户计做卡顿用户
• 一分钟用户卡顿率：1分钟窗口内，卡顿用户数/总的用户数
• 一分钟用户零卡顿率：1分钟窗口内，(总的用户数 - 卡顿用户数)/总的用户数

为何会选择用户卡顿率这个指标呢，而不是使用总体的卡顿采样点/总采样数呢？是由于咱们更想看到有多少用户没有出现过卡顿现象，这更能直观体现优质网络的总体占比。经过对各省份用户零卡顿率、用户数排行，以及各省用户卡顿率的观察，咱们能够很是直观地找到卡顿严重的地区，以便重点关注，进行资源调度优化。

直播应急预案

Hardware faults，software bugs， and operator errors， such failures are a fact of life：not a problem that will someday be solved once and for all， but a reality that we must live with.

Armando Fox.2002.Torward Recovery-Oriented Computing. VLDB 2002.

任何一个系统，不管你号称它被设计得多么健壮，它仍然会有故障时间的存在。硬件故障、软件bug、人为操做失误等等，这些都无可避免地存在着，他们未必是一个必须多少时间内将其完全解决的问题，他们是咱们必须认清并接受共存的一个事实。

因此，预案管理是大型直播活动保障中不可缺乏的一环，咱们遵循如下的预案原则：

1. 预案信息明确：大盘自动监控不具有二义性，确保预案信息来源正确，触发执行预案的条件明确且有数值化约束。
2. 预案操做简洁：全部的预案操做都有有简洁明确(开关型)的操做输入。
3. 预案操做安全：全部预案要通过充分预演，同时预演操做自己须要有明确的确认机制，以确保在正常状况下不会被误触发。
4. 预案影响：明确理清预案操做的影响，QA在预演阶段须要对相关影响进行充分验证。

这次活动的前期筹备中，咱们总计进行了3次直播全链路的拟真演练，以及2次联合互动现场、导播台现场的活动全流程级别的彩排，另外进行了大大小小总计数十次的各种风险预案演练。全部演练过程当中发现的问题，都会进行专项解决。

风险预案这块，包含了各种资源故障、上下行链路质量、地区性网络故障、CDN异常流量水位等在内的场景应对，其中资源故障包含了机器宕机、机架总体断电、堆叠交换机宕机、机房外网出口不可用，咱们均进行了风险预案演练覆盖。下面列举几点网易云信大型直播解决方案中的部分预案机制：

• 若是由于误操做等致使非正常解密等，网易云信可在推流不中断的状况下，动态停止流加密，客户端无任何感知影响。
• 某家cdn在某地区运营商出现大面积故障瘫痪，该地区相应运营商线路的QoS指标会大幅度降低并触发报警，网易云信将故障cdn在该地区运营商进行黑名单处理，动态中止对其的调度，将流量调度至正常提供服务的cdn厂商。
• 在两路热流均正常的状况下，可是正在分发的一路出现质量问题，方案可支持手动触发主备切换，让监控数据质量更好的另外一路流参与分发，客户端感知时间在1s之内。
• 由于一些不可抗因素，某机房出现大面积故障总体不可用，触发链路报警，此时咱们会紧急将流切至另外一机房，故障感知与恢复的时间在一分钟内。

结    语

依靠网易云信的千万级大型直播方案，这次活动圆满完成，总体推流链路可靠稳定，下行流量分配合理，相关故障预案完整充分并真实发挥做用。干货万千，纸短情长，点击【阅读原文】便可咨询网易云信大型直播方案，了解更多技术细节。

做者介绍

费曼，网易智企服务端开发工程师。硕士毕业于华中科技大学电信系，2016年加入网易云信，热衷于大规模分布式系统和音视频相关技术，爱好文学、体育和电影。

*各渠道文章转载需注明来源及做者