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以及即构全球主要国家的端到端延迟实测数据。