随着实时音视频（RTC）技术在娱乐、教育、会议、游戏等领域的广泛应用，用户对音视频通话的核心功能需求不断提升，同时也衍生出许多扩展需求。这些扩展功能在业务场景扮演着越来越重要的作用，已经成为许多业务场景的核心路径。例如：
这些扩展能力不仅能够提升 RTC 的互动体验，延伸 RTC 的通信边界，还能够促进业务创新，为业务创造新的收入来源。
为了支持上述这些功能，我们设计并实现了 RTC 实时媒体处理平台，这套系统高效支撑了内外部业务的快速增长和功能迭代，但在系统落地和演进的过程中，我们也遇到了很多技术挑战，可以总结为三大类。
系统需要支持的业务场景多样，不同业务场景的复杂度和规模也有差异，依赖和交互的模块众多，因此「如何设计出高内聚低耦合的架构，保证系统的可维护性和可扩展性」，成为重点考虑的方向。其中系统设计的关键考量包括，如何对不同的业务场景施加统一的管理控制能力，如流量分发、业务配置、任务管理、资源调度、监控诊断等；如何支持业务混部，实现业务错峰复用，提升资源利用率并降低成本；如何提升并发性能，支持百万级任务的实时调度和稳定运行；如何建设系统的可观测性，提升问题感知和诊断效率等。
RTC 媒体处理类的任务对实时性和可靠性的要求非常高。例如，用户启用RTC通话录制，系统必须能够迅速响应并立即启动录制任务。鉴于音视频流的实时性，任何启动延迟或失败则导致不可逆的内容缺失，如果是审核任务还会导致内容漏审。同样，旁路转推任务的延迟可能导致直播切换时出现黑屏等体验问题。
另外，RTC媒体处理类任务都是有状态的服务，并且持续时间比较长，任务执行强依赖上下文信息的及时和准确。例如，合流任务必须实时感知房间内的音视频流状态，并可靠地接受用户指令以设置正确的视频布局。任何状态信息的丢失或指令的延迟都可能引起合流过程的异常。「只有确保系统的高可用性和低延时，任务才能快速且正确地执行，从而为产品功能和用户体验提供基本保障。」
无论是转推、录制还是音视频审核等功能，都采用到一些相同的技术，例如都需要对音视频数据进行处理，会涉及到编解码、格式转换、音视频编辑、音画质增强等操作，另外也都涉及到 RTC 系统跟其他系统之间的通信，如访问直播、CDN、云存储、第三方服务等，跟这些服务的通信也会使用到一些相同的传输协议，如 RTMP，HTTP，WebSocket等。「如何将这些技术和能力提炼和抽象成具备通用性的原子能力，并且通过统一的接口和框架可以被高效的编排和组合」，成为提高技术复用和研发效率的关键问题。
下面针对上述三方面的技术挑战，我们逐一进行深入探讨。
系统建模主要围绕 「“任务”」 这个核心概念，平台支持的功能都以任务的形式提供服务，任务可以被看作是一个独立的工作单元，它有明确的输入、输出和执行流程。所有的用户请求都会关联到具体的任务，系统按照任务粒度执行业务逻辑和资源分配，日志事件和监控诊断等也以任务维度做全链路关联。
系统整体架构如上图所示，主要分为三个部分。
在容器内部，业务逻辑的主要执行者是一个 worker 程序，worker 的实现采用了单体架构，它具备很强的通用性，支持平台上所有的任务类型，通过不同的控制参数运行不同类型的任务。worker 程序是基于 pipeline 的框架结构，其中与音视频处理相关的原子能力通过插件来实现，各任务类型通过创建 pipeline 和对插件进行合理编排实现各自的业务功能。worker 还集成了 RTC SDK，通过虚拟用户加入 RTC 房间，实现与 RTC 网络的互通，同时它也集成了其他的功能组件实现与其他服务之间的交互和协作。
RTC 业务的实时性属性要求系统具备高可用设计和容灾能力。当前系统从层级关系可以分为控制面和数据面，控制面负责任务管理和逻辑控制，数据面负责任务的具体执行，接下来我们讨论一下在高可用设计中遇到的典型问题和解决思路。
为了保证用户接入的稳定性和接入体验，控制面服务做了全球多区域（Region）部署，区域内做了多可用区（AZ）设计，同 AZ 内的服务单元化部署，做到 AZ 内部调用链闭环。各 AZ 之间也不是完全隔离的，任务元信息等数据仍然需要在 AZ 之间做实时同步来提供容灾能力。
具体实现路径为，用户请求通过公网动态加速网络连接到 AZ，AZ 在接入层做一致性哈希将任务转发到归属 AZ，确保同一个任务的请求在单一 AZ 完成。存储层通过实时同步机制获取其他 AZ 的任务信息，这样每个 AZ 就拥有了全局的任务信息。在单个 AZ 不可用时，能够保证其他 AZ 也能够处理针对故障 AZ 的存量任务请求。
单可用区内部的高可用主要关注任务元信息的管理和存储。由于存储层访问是请求处理的关键环节，其稳定性至关重要，我们采用「存储分层和存储互备」来增强存储的可靠性，这些措施也有助于实现高并发处理和降低响应延迟。任务元信息的存储会优先使用 Redis，Redis 不可用时降级到 ByteNDB（公司自研的分布式数据库，兼容MySQL，同时具有高并发高吞吐，独立扩缩容，存储容量不受单机限制等优点），都不可用时会采用本地内存做兜底。任务元信息会通过消息队列实时同步到其他 AZ，并达成在 DB 层的最终一致性和持久化。面对系统每天千万级的新增任务量，我们采用了分片存储技术以解决单一数据库实例的性能和存储容量方面的限制。
数据面主要指具体的任务执行逻辑。这部分的稳定性主要从以下几个方面考虑：
任务在容器内运行时主要有 2 个部分，executor 和 worker，executor 承担了本地代理的角色，负责接收控制面的任务指令，同时也会收集本地任务的运行状态和数据指标等并上报给控制面。worker 负责业务逻辑的执行，包括推拉流、编解码等计算。executor fork 出子进程运行 worker，在 worker 发生 crash 或者卡死等异常时会立即重启 worker 进程，同时在监控到 worker 资源消耗超出配额时，则判断是否是业务正常使用还是发生了异常，来决策是否要触发业务降级降低资源消耗，或者实时增加该任务的资源配额。
容器实例异常退出时，调度服务会创建一个新的实例来恢复和继续当前的任务，我们称这种场景为重新调度，新任务实例会避开之前的机器节点和集群，减少二次失败风险。在另外一些更严重的故障场景，如某个集群发生大面积故障时，我们支持对集群内的存量任务做主动迁移，通过将任务迁移到正常的集群来实现业务的更快速止损和恢复。
「提升故障感知和决策能力。」 高质量的决策依赖高质量的信息输入，故障恢复策略的执行依赖故障信息判断的可靠性和准确性。我们重点优化了两类问题。
「信息传输链路的可靠性」。控制面服务和计算集群独立部署，并不强绑定在同一机房。控制面部署在中心机房，而计算集群分布在中心机房、汇聚机房和边缘机房。控制面跟计算集群之间通过内网专线、公网直连和公网加速等多种传输手段实现了多路径传输，确保控制信令在专线故障和公网抖动等异常下仍然实时可达。
「故障信息的准确性」。最典型的问题就是任务失联，即控制面接受不到任务实例的保活信息。失联原因多种多样，包括任务实例的网络异常、任务机房的网络问题，或是控制面实例自身的问题。在保活失败时，我们不仅采用重连重试等基础措施，还会触发机房内和机房间对故障任务的主动问询，来进一步诊断失联的具体原因。如果是任务实例问题则会触发任务重调度，如果是集群故障可能会对整个集群做熔断等。在做主动问询时，需要特别关注请求风暴问题，尤其是集群网络故障可能会导致大量任务保活失败，瞬间触发大量的探测请求，对服务造成巨大冲击，我们采用频控和聚集性判断等策略来减少冗余请求。
「精细化的调度策略。」 系统中任务种类繁多，每种任务对时延、音画质量以及其承载的规模各不相同。因此，调度服务在为任务分配集群时，引入了评分机制，综合考虑负载、成本、位置、业务偏好和 QoS 指标等多种因素，这个评分旨在衡量任务与集群之间的匹配度，同时考虑了任务需求和集群能力，而不是单方面评价集群。例如某个地区的推流节点故障导致转推任务在某个集群异常，但这个集群的录制任务是正常的，这时候转推任务跟这个集群的匹配分低，但录制任务跟这个集群的匹配是正常的，录制任务还是可以继续往这个集群调度。通过此类精细化的策略可以减少粗粒度的调度对集群资源和负载的冲击，降低系统风险。
为了支持更多复杂的应用场景，提升系统的灵活性和可扩展性，媒体处理框架以模块化和插件化为核心原则，将处理流程做了通用的抽象，整体上可以分为输入、处理和输出三个部分。
当前这套框架已经实现了丰富的模块和插件能力，这些插件可以通过框架层进行组合和串联，构成一个媒体应用，目前支持了 RTC 近十种业务。同时支持一些基础功能进行二次组合，提供更高层的原子能力。如下图所示，转推直播与实时录制的主要区别仅在于媒体流的最终去向，将转推直播的输出模块替换为录制存储模块，系统便可快速实现录制功能。
用户向云端发起录制请求后，录制任务通过 RTC SDK 加入房间，拉取需要录制的音视频流，然后以单流或合流的方式对音视频流做编码封装，最后录制文件存储到用户指定的存储平台，用户在请求中可以指定订阅用户的媒体流类型、设置合图布局样式、设置录制结果通知，设置编码参数等。
针对用户非常关心的「录制文件的可靠性问题」，我们采取多种手段保障在断电断网等异常情况下文件不丢失。
在录制文件的音视频质量方面，我们利用公司在行业领先的编码器能力，能够做到同等画质下生成的录制文件的体积更小，节省了录制存储，为用户节省成本。
字幕任务启动后，会订阅房间里所有发布者的音频流，接下来会经过有效语音检测、语音识别、内容翻译、内容合规、字幕平滑等步骤，最终将语音识别的结果分发出去。系统支持火山引擎和第三方语音识别和内容翻译服务。同时，在字幕内容分发上，有多种方式选择：
前三种是基于 RTC 系统的分发方式，无论是端到端延时还是分发规模都能够满足主要场景的业务需求，也是我们更推荐的方式。
字幕功能已经被大规模应用在互娱社交、在线教学、视频会议等 RTC 业务场景，其在抖音语聊房上线后，各项业务指标都表明能够显著提升用户的互动沉浸感和在房间内的停留时长，业务收益显著。
在视频会议场景，基于 RTC 技术的云服务视频会议已经成为主流，但企业对已经购买的传统 SIP 终端利旧的需求也非常强烈，所以需要打通 RTC 终端和 SIP 会议硬件。与只有 RTC 终端参与通话的其他场景相比，SIP 会议网关在技术架构上引入了 2 个额外的模块：「SIP access」 用来接受 SIP 终端注册和 SIP 通话的呼入呼出，「SIP gateway」 负责 SIP 会话管理以及 SIP 和 RTC 之间的媒体协议转换。SIP 会议网关服务支持以下能力：
SIP 网关服务当前已经在应用在飞书视频会议，每天支撑数万台 SIP 设备的日常会议请求。
暂时无法在飞书文档外展示此内容
我们对 SIP 网关服务进行了扩展，增加了 PSTN 呼叫功能，打通了 RTC 终端和电话终端，为呼叫中心等业务场景提供了云端呼叫能力。
该功能已经在飞书视频会议和抖音客服等业务落地。抖音客服平台采用了该方案后，将传统的话机坐席替换成集成了 RTC 客户端的软件坐席，不仅提高了运营效率，还为用户带来了更好的通话体验，用户满意度也显著提升。
作为定位于支撑更多 RTC 业务场景的应用平台，我们希望能够针对 RTC 业务领域的特点，提供更多原子能力和场景化解决方案，支撑客户更加便捷的接入和搭建自己的业务，持续提升业务质量，降低客户使用成本。我们会在以下方面做更长期的投入。
本文链接：http://www.28at.com/showinfo-26-101701-0.html火山引擎 RTC 实时媒体处理平台的技术实践
声明：本网页内容旨在传播知识，若有侵权等问题请及时与本网联系，我们将在第一时间删除处理。邮件：2376512515@qq.com
上一篇： Python 十个高阶函数
Copyright © 2016-2023 天津谷骐科技有限公司 版权所有 sitemap.xml
违法及侵权请联系：2376512515@qq.com 津ICP备18001702号
津公网安备 12010102000574号
