【活动回顾】ZEGO实时音视频服务架构实践

  • 内容
  • 评论
  • 相关

 

10月24日,即构科技后台架构负责人&高级技术专家祝永坚(jack),受邀参加2020中国系统架构师大会,在音视频架构与算法专场进行了主题为《ZEGO实时音视频服务架构实践》的技术分享。

以下为演讲内容的节选:

作为一家专业的音视频云服务商,即构服务了泛娱乐、在线教育、金融、产业互联网、IoT等行业的多家头部公司,例如映客、花椒、微博、好未来等。今年上半年受疫情影响,即构所服务的多家教育、泛娱乐客户都出现了流量暴增的现象。而即构提供的稳定后台服务,保障了客户线上业务0故障运营,这离不开我们成熟稳定、可用性高、能自动扩容的流媒体服务架构。

下面我从ZEGO流媒体服务简介、流媒体服务架构、调度逻辑设计和运营监控四部分进行分享:

一、ZEGO流媒体服务介绍

以这张图为例,我们来看ZEGO流媒体服务的全貌:

 

假设图中有三位主播A,B,C和观众,主播A,B,C要进行连麦互动,他们分别通过浏览器、原生App和微信/QQ小程序来推流。由于主播使用了不同的终端形式来进行推流,那么底层使用的音视频协议也是不同的,分别对应着WebRTC,AVERTP(ZEGO的私有音视频协议),RTMP。主播之间连麦互动需要互相拉流,为了获得良好的互动效果,需要很低的端到端拉流延迟(<400ms)。因此,主播们可以到即构全球实时网络来进行拉流,支持Web终端,和原生App拉流,国内的实际环境端到端延迟可以做到150-400ms。

而观众,因为量比较大,需要考虑成本,同时他不需要互动,可以接受较高的延迟。因此可以考虑从即构全球实时网络转推一路RTMP协议的码流到第三方CDN,观众再从CDN去拉流。

当然,如果观众也要很低的延迟,那么也可以从我们的实时网络拉流。此外,一些原来使用rtmp的客户,还可以通过第三方应用通过OBS来推流,很轻易的迁移到即构全球实时网络,用户就可以实现在全球区域范围内进行低延迟的音视频互动。

介绍完主要流媒体服务的全流程后,我们来看流媒体服务包含的具体职责:

调度:在用户推拉流前,需要发起调度请求,获得一个资源后才能够发起实际的码流推拉。用户体验的好坏,跟调度策略有很大关系。

实际推拉流:我们适配了RTMP,WebRTC,AVERTP等多种协议的推拉流标准,提供了更优的流控等算法。

转推CDN:即构全球实时网络和第三方的CDN需要进行协作来满足客户的多样化场景需求。

转码:RTMP使用的AAC音频编码,WebRTC使用的Opus音频编码,这两种格式互通,需要对音频进行转码。

转协议:我们RTMP和WebRTC是以网关的形式存在的,中间的网络传输都是以我们的avertp协议来进行。

目前我们支持H264,H265,VP8 3种格式的视频编码转码;AAC, Opus,SILK 3种格式的音频转码;RTMP、WebRTC、avertp3种协议格式的转协议。

混流:当出现多个主播连麦互动时,观众如果分别去拉主播的流,对带宽成本和用户的设备都有很高的要求。我们会让服务器混合成一条流,观众只需要拉混合后的流即可。

流管理:推拉流鉴权,禁推管理,我们提供了业务运营必需的多种流管理功能。

即构实时音视频服务的优势体现在4个方面:

第一,多云商架构设计

我们设计之初就确定了支持多云商的架构设计。不同云商有着不同的优势,他的数据中心和网络资源天然的存在着差异性,a云商在印度南部覆盖质量好,b云商在印度北部覆盖质量好。那么我们就都用起来,让a云商覆盖印度南部,b云商覆盖印度北部,从而让整体获得更好的接入质量。

第二,高可用设计保障质量

我们架构设计上加进了许多高可用的方案,来保障稳定的服务质量,后面会展开。

第三,弱网下抗丢包能力强

我们自研的音视频引擎,在弱网下的表现更优异,能实现“上/下行70%丢包下,保持10-15帧视频流畅通话;上/下行80%丢包下,保持音频流畅通话”。

第四,低延迟大规模分发

利用ZEGO自研引擎,我们做了低延迟大规模分发的流媒体服务架构设计,能极大的提高后台并发能力。

 

(未完待续……)

 

鉴于分享内容较丰富,更多ZEGO实时音视频服务架构实践中的“流媒体服务架构设计、调度逻辑设计以及运营监控”等内容,可以扫描下方二维码获取演讲资料包,包含演讲文字稿、演讲PPT以及即构全球主要国家的端到端延迟实测数据。

评论

0条评论

发表评论

邮箱地址不会被公开。 必填项已用*标注