网易云信：如何保障一场千万级大型直播

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

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

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

2.下行链路稳定

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

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

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

3.直播内容安全

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

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

三、监控报警与预案

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

1.全链路监控

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

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

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

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

·一次卡顿：播放器持续2s发生缓冲区空，即播放器2s没有拉到流

·一分钟用户卡顿：1分钟窗口内，用户只要卡顿一次，则该用户计作卡顿用户

·一分钟用户卡顿率：1分钟窗口内，卡顿用户数/总的用户数

·一分钟用户零卡顿率：1分钟窗口内，(总的用户数 - 卡顿用户数)/总的用户数

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

2.直播应急预案

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次联合互动现场、导播台现场的活动全流程级别的彩排，另外进行了大大小小总计数十次的各类风险预案演练。所有演练过程中发现的问题，都会进行专项解决。

（编辑：应用网_阳江站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!