申请一个域名可以建设一个网站吗,腾讯云网站备案,中学生网站作品,网站开发背景图模板1、架构方面
1.1 基本 该图是某大型在线演唱会的直播媒体架构简图。 可以看出一场大型活动直播涵盖的技术方案点非常庞杂#xff0c;本节接下来的内容我们将以推拉流链路、全局智能调度、流量精准调度以及单元化部署#xff0c;对这套直播方案做一个展开介绍。
1.2 推拉流链…1、架构方面
1.1 基本 该图是某大型在线演唱会的直播媒体架构简图。 可以看出一场大型活动直播涵盖的技术方案点非常庞杂本节接下来的内容我们将以推拉流链路、全局智能调度、流量精准调度以及单元化部署对这套直播方案做一个展开介绍。
1.2 推拉流链路 如上图所示直播技术架构分为几大部分
1视频直播中心LMS——Live Manage Service负责直播流的逻辑管理和操作控制包括存储和下发实时转码、加密等媒体处理的配置信息2实时互动直播服由连麦互动和直播两部分组成主播和连麦者的音视频数据在互动直播高性能服务器合成为一道流后推流到直播流媒体服务器3直播源站服务LSS——Live Source Service直播流媒体服务器节点结合全局智能调度系统提供第一公里的最佳链路选择4媒体处理服务MPS——Media Processing Service提供实时水印、实时转码、媒体数据加密等强大的流媒体处理能力5融合CDN与全局智能调度GSLB——Golabal Server Load Balancing提供敏捷智能的CDN调度策略和分配算法结合全链路、端到端的流媒体控制来达到最终端侧优良的用户体验6客户端SDK提供推流、拉流以及上下行的调度能力便于用户快速接入使用平台一站式的音视频解决方案。
1.3 融合CDN与智能调度 这是一个端到端的服务通过平台的SDK执行一个类似HTTPDNS的调度来做到真正根据用户IP做就近的接入。
针对国内相对复杂的运营商网络环境在直播上行方面通过BGP网络以及与相关运营商在网络接入方面的合作能够更加精准地控制网络链路的选择。
而对于下行也提供了播放端的SDK接入通过端到端的调度策略就近选择合适的下行链路。 调度的准确性以及最终效果依赖及时准确的数据支撑。
我们有一个全链路、立体的数据监控体系一方面利用CDN上的一些实时日志另一方面结合自建节点、客户端侧上报收集链路上探测的数据然后整合做一个实时计算来支撑整个调度的策略。 融合CDN方案通过调度、监控、高可用等技术和手段来解决CDN网络方面的问题。但是对于技术人员来说就和在使用一个传统的CDN网络一样没有大的差异这些技术细节对技术人员透明无感知。
1.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厂商超分配。
1.5 单元化部署
上面所说在大型直播活动中短时间大量涌入的用户请求对以全局智能调度服务为主的相关非媒体流链路应用也提出了更高的并发处理挑战。
除了上行的推流链路我们做了主备两个单元的部署非媒体数据链路上的服务也采用了单元化的部署方案。
在此部署方案下可用性做到任意单元机房故障不影响整体可用性即异地多活。
单元化部署遵循以下原则
1单元化的依赖也必须单元化核心业务2单元化粒度为应用非api3单元化技术栈对应用尽量避免产生侵入性。 如上图所示非单元化的业务部署在主机房单元化的业务则部署在主机房和单元机房。 2、稳定性保障
2.1 上行链路稳定
超大型直播方案最核心的诉求就是直播稳定性下面我们将以该次在线演唱会为案例重点阐述一下直播的全链路稳定性架构。 上图是我们直播的媒体流链路示意简图整体方案可以承受任何单节点、单线路、单机房网络出口的故障。
如直播源站部分采用了多线策略收流包含机房专线和4G背包方案一主一备两个线路。同时每个单元的源站集群都有4层负载均衡一台机器宕机不会影响整体可用性。LMS、LSS、MPS都是跨机房部署所有服务模块都可配置专有资源池供使用保证不会受其他租户影响。
整个推流链路采用双路热流、互为主备且部署上是互相独立的两个单元能做到支持Rack级别的故障灾备。双路热流实现了自动主备切换端上无需专门添加应用层的线路切换逻辑。当任何一个链路出现问题的时候观众的直播流不会受到影响端上平均卡顿感知时间在1s以内。
除了推流链路的整体主备单元容灾每个单元的服务本身也会有容灾手段。比如UPS接入可以接受30min的供电故障比如当实时互动流出现问题时导播台会推垫片流以保证链路数据不中断。
2.2 下行链路稳定
在访次直播活动中全局智能调度服务会承受较大的峰值压力在单元化部署的基础上我们经过多轮压测和性能调优模型上可支撑千万级用户在半分钟内全部进入直播间。
除了上述关于推流链路的高可用下行链路也有相关的容灾策略。当GSLB智能调度服务整体不可用在客户端SDK预埋了融合CDN的local DNS灾备逻辑与比例配置将云端的全局智能调度fail-over到客户端的本地兜底调度并保持大数据统计层面的各CDN厂商的流量分配均衡。
同时客户端也会有播放体验方面的容灾策略诸如清晰度降级、线路调整等。 3、安全性保障
除了直播全链路的稳定之外直播安全也很重要。
该次直播活动中为在线直播活动链路多环节都提供了安全保障机制如防盗链鉴权、IP黑白名单、HTTPS等能力以及地区、运营商等下行调度的动态限制实现全链路安全保障。
在此基础上此次活动采用了端到端的视频流数据加密。
直播场景的加密有几点基本要求压缩比不变、实时性和低计算复杂度。
除此之外在融合多cdn的方案背景下视频流的加密必须考虑到CDN厂商的兼容性。
比如须满足以下要求
1不破坏流媒体协议格式、视频容器格式2metadata/video/audio tag的header部分不加密3对于avcSequenceHeader和aacSequenceHeader tag整体不加密。
具体加密算法可以采用一些流式加密算法这里我们不再赘述。 4、监控与报警
4.1 概述
一场大型直播将会有大量的计算节点参与除了媒体数据处理与分发的各个服务器节点还有分布在国内外的海量客户端。
我们对网络链路、服务节点、设备端的健康与质量感知都离不开数据监控系统。
同时我们在现有系统无法自动fail-over的故障场景下需要人工预案介入而后者的决策判断也强依赖于完善的全链路数据质量监控与报警系统。
4.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分钟窗口内(总的用户数 – 卡顿用户数)/总的用户数。
为什么会选择用户卡顿率这个指标而不是使用整体的卡顿采样点/总采样数呢
是因为我们更想看到有多少用户没有出现过卡顿现象这更能直观体现优质网络的整体占比。通过对各省份用户零卡顿率、用户数排行以及各省用户卡顿率的观察我们可以非常直观地找到卡顿严重的地区以便重点关注进行资源调度优化。 5、应急预案
任何一个系统无论你号称它被设计得多么健壮它仍然会有故障时间的存在。
硬件故障、软件bug、人为操作失误等等这些都无可避免地存在着。他们未必是一个必须多少时间内将其彻底解决的问题他们是我们必须认清并接受共存的一个事实。
所以预案管理是大型直播活动保障中不可缺少的一环。
我们遵循以下的预案原则
1预案信息明确大盘自动监控不具备二义性确保预案信息来源正确触发执行预案的条件明确且有数值化约束2预案操作简洁所有的预案操作都有有简洁明确(开关型)的操作输入3预案操作安全所有预案要经过充分预演同时预演操作本身需要有明确的确认机制以确保在正常情况下不会被误触发4预案影响验证明确理清预案操作的影响QA在预演阶段需要对相关影响进行充分验证。
此次活动的前期筹备中我们总计进行了3次直播全链路的拟真演练以及2次联合互动现场、导播台现场的活动全流程级别的彩排另外进行了大大小小总计数十次的各类风险预案演练。所有演练过程中发现的问题都会进行专项解决。
风险预案这块包含了各类资源故障、上下行链路质量、地区性网络故障、CDN异常流量水位等在内的场景应对。其中资源故障包含了机器宕机、机架整体断电、堆叠交换机宕机、机房外网出口不可用我们均进行了风险预案演练覆盖。
下面列举几点直播解决方案中的部分预案机制
1如果因为误操作等导致非正常解密等可在推流不中断的情况下动态中止流加密客户端无任何感知影响2某家cdn在某地区运营商出现大面积故障瘫痪该地区相应运营商线路的QoS指标会大幅度下降并触发报警将故障cdn在该地区运营商进行黑名单处理动态停止对其的调度将流量调度至正常提供服务的cdn厂商3在两路热流均正常的情况下但是正在分发的一路出现质量问题方案可支持手动触发主备切换让监控数据质量更好的另一路流参与分发客户端感知时间在1s以内4因为一些不可抗因素某机房出现大面积故障整体不可用触发链路报警此时我们会紧急将流切至另一机房故障感知与恢复的时间在一分钟内。
