如何保障一场千万级大型直播？( 二 ) _大型直播

| Don't put all your eggs in one basket.
永远不要将鸡蛋放在同一个篮子里，从风险管控的角度来说，大型活动保障的CDN资源需要做到非常充分的保障，除了活动前针对用户分布分析资源需求，确保各地区各运营商资源充足外，网易云信的融合CDN方案则是将多CDN厂商资源进行整合，实现智能调度。目标是通过质量、资源负载等多个维度动态调整CDN权重，最终确保用户体验。
4. 单元化部署
上文所说，在大型直播活动中，短时间大量涌入的用户请求，对以全局智能调度服务为主的相关非媒体流链路应用，也提出了更高的并发处理挑战。除了上行的推流链路我们做了主备两个单元的部署，非媒体数据链路上的服务我们也采用了单元化的部署方案。
在此部署方案下，可用性做到任意单元机房故障，不影响整体可用性，即异地多活。单元化部署遵循以下原则：
l 单元化的依赖也必须单元化（核心业务）
l 单元化粒度为应用，非api
l 单元化技术栈对应用尽量避免产生侵入性

文章插图
如上图所示，非单元化的业务部署在主机房，单元化的业务则部署在主机房和单元机房。
二、稳定性与安全性的保障
1. 上行链路稳定
超大型直播方案最核心的诉求就是直播稳定性，下面我们将以此次在线演唱会为案例，重点阐述一下网易云信大型直播的全链路稳定性架构。

文章插图
上图是云信大型直播的媒体流链路示意简图，整体方案可以承受任何单节点、单线路、单机房网络出口的故障。如直播源站部分，采用了多线策略收流，包含机房专线和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的故障场景下，需要人工预案介入，而后者的决策判断，也强依赖于完善的全链路数据质量监控与报警系统。