随着实时音视频（RTC）技术在娱乐、教育、会议、游戏等领域的广泛应用，用户对音视频通话的核心功能需求不断提升，同时也衍生出许多扩展需求。这些扩展功能在业务场景扮演着越来越重要的作用，已经成为许多业务场景的核心路径。例如：
转推直播 - 将直播间主播连麦的视频合流转推到 CDN 可以供更多人观看；
实时录制 - 将在线课堂中老师的教学和互动内容录制下来供学生课后回看；
实时字幕 - 在跨国视频会议中可以帮助参会者打破语言的界限，使信息传递更加准确顺畅；
输入在线媒体流 - 将体育赛事直播视频输入到 RTC 房间，实现边看边聊；
电话呼叫 - 将固话和手机用户加入到 RTC 通话；
SIP互通 - 将传统视频会议设备加入 RTC 视频会议；
这些扩展能力不仅能够提升 RTC 的互动体验，延伸 RTC 的通信边界，还能够促进业务创新，为业务创造新的收入来源。
为了支持上述这些功能，我们设计并实现了 RTC 实时媒体处理平台，这套系统高效支撑了内外部业务的快速增长和功能迭代，但在系统落地和演进的过程中，我们也遇到了很多技术挑战，可以总结为三大类。
系统需要支持的业务场景多样，不同业务场景的复杂度和规模也有差异，依赖和交互的模块众多，因此**「如何设计出高内聚低耦合的架构，保证系统的可维护性和可扩展性」**，成为重点考虑的方向。其中系统设计的关键考量包括，如何对不同的业务场景施加统一的管理控制能力，如流量分发、业务配置、任务管理、资源调度、监控诊断等；如何支持业务混部，实现业务错峰复用，提升资源利用率并降低成本；如何提升并发性能，支持百万级任务的实时调度和稳定运行；如何建设系统的可观测性，提升问题感知和诊断效率等。
RTC 媒体处理类的任务对实时性和可靠性的要求非常高。例如，用户启用RTC通话录制，系统必须能够迅速响应并立即启动录制任务。鉴于音视频流的实时性，任何启动延迟或失败则导致不可逆的内容缺失，如果是审核任务还会导致内容漏审。同样，旁路转推任务的延迟可能导致直播切换时出现黑屏等体验问题。
另外，RTC媒体处理类任务都是有状态的服务，并且持续时间比较长，任务执行强依赖上下文信息的及时和准确。例如，合流任务必须实时感知房间内的音视频流状态，并可靠地接受用户指令以设置正确的视频布局。任何状态信息的丢失或指令的延迟都可能引起合流过程的异常。「只有确保系统的高可用性和低延时，任务才能快速且正确地执行，从而为产品功能和用户体验提供基本保障。」
无论是转推、录制还是音视频审核等功能，都采用到一些相同的技术，例如都需要对音视频数据进行处理，会涉及到编解码、格式转换、音视频编辑、音画质增强等操作，另外也都涉及到 RTC 系统跟其他系统之间的通信，如访问直播、CDN、云存储、第三方服务等，跟这些服务的通信也会使用到一些相同的传输协议，如 RTMP，HTTP，WebSocket等。「如何将这些技术和能力提炼和抽象成具备通用性的原子能力，并且通过统一的接口和框架可以被高效的编排和组合」，成为提高技术复用和研发效率的关键问题。
下面针对上述三方面的技术挑战，我们逐一进行深入探讨。
系统建模主要围绕 「“任务”」 这个核心概念，平台支持的功能都以任务的形式提供服务，任务可以被看作是一个独立的工作单元，它有明确的输入、输出和执行流程。所有的用户请求都会关联到具体的任务，系统按照任务粒度执行业务逻辑和资源分配，日志事件和监控诊断等也以任务维度做全链路关联。
系统整体架构如上图所示，主要分为三个部分。
「接入层」 API 网关接受用户请求，对请求进行身份验证和授权，支持对请求的并发控制，避免因恶意请求或突发的高流量导致系统异常。作为所有请求的统一入口，接入层承担着关键的流量调度功能，可以根据系统的实际运行情况和业务需求，智能分配流量，确保资源的合理利用和业务的亲和性。在下游故障时，可以自动熔断，及时切断问题链路，防止故障的进一步扩散。同时也支持人工切量，满足日常运维和压测管控等要求。
**「任务管理和调度」**基于微服务架构，作为控制面的主体，主要包括请求处理和资源调度。请求处理部分负责任务的启停控制，管理任务的生命周期，同时监控任务的执行进度和状态，及时处理任务执行过程中出现的异常，支持任务重启、热迁移、重新调度等异常处理策略。资源调度会综合考虑任务属性、业务配置以及资源负载等多方面因素，将任务精准地分配给最合适的执行器。调度模块通过一系列的基础调度算法，努力实现任务和资源的最优匹配，这种匹配不仅仅是为了让业务体验达到最佳，同时也是为了实现资源效率的最大化。
**「任务执行」**分布式部署的计算集群为任务执行提供资源和环境。当任务被成功分配到执行器资源后，会启动新的容器实例来执行业务逻辑，每个任务的容器实例是相互隔离的，任务结束后容器资源会被销毁和回收。
在容器内部，业务逻辑的主要执行者是一个 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个基础依赖：磁盘和网络。
随着机器长时间运行，磁盘老化引起的性能下降或者 IO 卡死等问题不可避免，解决方法主要采用两个手段，一是周期性做 IO 健康度检测，提前暴露风险，及时做替换和修复。二是代码实现时降低对磁盘 IO 的依赖，例如录制任务运行过程需要写文件，在磁盘访问遇到问题时，会切换到网络存储；程序运行中日志的打印也不能因为磁盘 IO 性能而影响主逻辑运行。
网络问题主要考虑公网访问的稳定性。公网访问时我们部署了正向代理和 NAT 作为互备方案。每个服务的机房出口连接了多家运营商的线路，确保即使单一运营商线路出现故障，也不会影响业务的正常运行。此外我们也观测到，在访问特定的公有云存储区域时，通过选择特定的代理线路可以显著提升数据传输的质量，我们也为这些场景配置了相应的访问策略，以确保传输过程的高效和稳定。
「任务运行遇到故障时能够快速恢复。」 这里的恢复手段分两个维度：容器内部和容器间。
任务在容器内运行时主要有 2 个部分，executor 和 worker，executor 承担了本地代理的角色，负责接收控制面的任务指令，同时也会收集本地任务的运行状态和数据指标等并上报给控制面。worker 负责业务逻辑的执行，包括推拉流、编解码等计算。executor fork 出子进程运行 worker，在 worker 发生 crash 或者卡死等异常时会立即重启 worker 进程，同时在监控到 worker 资源消耗超出配额时，则判断是否是业务正常使用还是发生了异常，来决策是否要触发业务降级降低资源消耗，或者实时增加该任务的资源配额。
容器实例异常退出时，调度服务会创建一个新的实例来恢复和继续当前的任务，我们称这种场景为重新调度，新任务实例会避开之前的机器节点和集群，减少二次失败风险。在另外一些更严重的故障场景，如某个集群发生大面积故障时，我们支持对集群内的存量任务做主动迁移，通过将任务迁移到正常的集群来实现业务的更快速止损和恢复。
「提升故障感知和决策能力。」 高质量的决策依赖高质量的信息输入，故障恢复策略的执行依赖故障信息判断的可靠性和准确性。我们重点优化了两类问题。
「信息传输链路的可靠性」。控制面服务和计算集群独立部署，并不强绑定在同一机房。控制面部署在中心机房，而计算集群分布在中心机房、汇聚机房和边缘机房。控制面跟计算集群之间通过内网专线、公网直连和公网加速等多种传输手段实现了多路径传输，确保控制信令在专线故障和公网抖动等异常下仍然实时可达。
「故障信息的准确性」。最典型的问题就是任务失联，即控制面接受不到任务实例的保活信息。失联原因多种多样，包括任务实例的网络异常、任务机房的网络问题，或是控制面实例自身的问题。在保活失败时，我们不仅采用重连重试等基础措施，还会触发机房内和机房间对故障任务的主动问询，来进一步诊断失联的具体原因。如果是任务实例问题则会触发任务重调度，如果是集群故障可能会对整个集群做熔断等。在做主动问询时，需要特别关注请求风暴问题，尤其是集群网络故障可能会导致大量任务保活失败，瞬间触发大量的探测请求，对服务造成巨大冲击，我们采用频控和聚集性判断等策略来减少冗余请求。
「精细化的调度策略。」 系统中任务种类繁多，每种任务对时延、音画质量以及其承载的规模各不相同。因此，调度服务在为任务分配集群时，引入了评分机制，综合考虑负载、成本、位置、业务偏好和 QoS 指标等多种因素，这个评分旨在衡量任务与集群之间的匹配度，同时考虑了任务需求和集群能力，而不是单方面评价集群。例如某个地区的推流节点故障导致转推任务在某个集群异常，但这个集群的录制任务是正常的，这时候转推任务跟这个集群的匹配分低，但录制任务跟这个集群的匹配是正常的，录制任务还是可以继续往这个集群调度。通过此类精细化的策略可以减少粗粒度的调度对集群资源和负载的冲击，降低系统风险。
为了支持更多复杂的应用场景，提升系统的灵活性和可扩展性，媒体处理框架以模块化和插件化为核心原则，将处理流程做了通用的抽象，整体上可以分为输入、处理和输出三个部分。
「输入模块」 负责媒体流的获取。因为大多数功能都需要从 RTC 系统拉流，我们对 RTC 流的订阅管理和数据回调进行了抽象和封装，并适配多家主流 RTC 厂商接口，能够非常方便的支持融合类的业务。同时，我们还实现了云端播放器功能，支持直播流和点播文件的输入，并封装文件读取、时间戳同步、错误处理等复杂工作，进而对下游输出可供直接渲染和播放的帧数据。
「处理模块」 通过将原子能力抽象成独立的插件，屏蔽内部实现细节，以实现媒体处理能力的可组合、可复用、可替换。这里面的模块既包括音视频处理相关的，如编解码，视频编辑，画质增强等，也包括一些应用能力的模块化，如 ASR，TTS，GPT等，有的能力是本地计算完成的，有的是通过调用其他远程服务实现的，各插件通过灵活组合和搭配，构建适应不同场景需求的媒体处理 pipeline。
「输出模块」 完成处理结果的最终流向。涉及到的技术点主要是媒体封装和传输，支持多种输出形式。RTC 流的输出仍然是通过 RTC SDK 发布到 RTC 系统，直播流会基于客户指定的协议和参数推流到发布点，点播支持多种存储协议和厂商，还有的场景需要将处理结果回调给客户的业务服务器，如媒体流的审核结果、AI 识别结果等。
当前这套框架已经实现了丰富的模块和插件能力，这些插件可以通过框架层进行组合和串联，构成一个媒体应用，目前支持了 RTC 近十种业务。同时支持一些基础功能进行二次组合，提供更高层的原子能力。如下图所示，转推直播与实时录制的主要区别仅在于媒体流的最终去向，将转推直播的输出模块替换为录制存储模块，系统便可快速实现录制功能。
用户向云端发起录制请求后，录制任务通过 RTC SDK 加入房间，拉取需要录制的音视频流，然后以单流或合流的方式对音视频流做编码封装，最后录制文件存储到用户指定的存储平台，用户在请求中可以指定订阅用户的媒体流类型、设置合图布局样式、设置录制结果通知，设置编码参数等。
针对用户非常关心的**「录制文件的可靠性问题」**，我们采取多种手段保障在断电断网等异常情况下文件不丢失。
首先，录制过程中会实时分片，每隔数秒生成一个分片文件，并实时上传到内部的暂存空间，保证在任务实例主机异常时最多丢失一个分片时长的视频片段。
对于对数据丢失零容忍的用户，我们支持实时双录，用户发起一次请求，系统内部会启动两个完全独立的任务，并且通过调度策略保证运行在不同的机房，当其中一个任务异常时，另外一个任务作为热备。
如果访问用户指定的第三方存储失败或第三方存储自身发生故障时，我们也会将录制文件暂存到内部的存储系统，保证文件不会丢失。
在录制文件的音视频质量方面，我们利用公司在行业领先的编码器能力，能够做到同等画质下生成的录制文件的体积更小，节省了录制存储，为用户节省成本。
字幕任务启动后，会订阅房间里所有发布者的音频流，接下来会经过有效语音检测、语音识别、内容翻译、内容合规、字幕平滑等步骤，最终将语音识别的结果分发出去。系统支持火山引擎和第三方语音识别和内容翻译服务。同时，在字幕内容分发上，有多种方式选择：
「RTS 点对点发送」 通过 RTC 支持的实时消息功能（RTS）将语音识别的结果发送给房间内需要的用户；
「RTS 广播」 通过 RTS 广播方式将说话者的结果发送给房间内的所有用户；
「视频 SEI 发送」 语音识别结果通过 RTS 发送给说话者，说话者发布的视频 SEI 中携带字幕内容；
「业务服务器分发」 字幕任务将语音识别结果回调给业务服务器，业务通过自己的业务逻辑做字幕分发；
前三种是基于 RTC 系统的分发方式，无论是端到端延时还是分发规模都能够满足主要场景的业务需求，也是我们更推荐的方式。
字幕功能已经被大规模应用在互娱社交、在线教学、视频会议等 RTC 业务场景，其在抖音语聊房上线后，各项业务指标都表明能够显著提升用户的互动沉浸感和在房间内的停留时长，业务收益显著。
在视频会议场景，基于 RTC 技术的云服务视频会议已经成为主流，但企业对已经购买的传统 SIP 终端利旧的需求也非常强烈，所以需要打通 RTC 终端和 SIP 会议硬件。与只有 RTC 终端参与通话的其他场景相比，SIP 会议网关在技术架构上引入了 2 个额外的模块：「SIP access」 用来接受 SIP 终端注册和 SIP 通话的呼入呼出，「SIP gateway」 负责 SIP 会话管理以及 SIP 和 RTC 之间的媒体协议转换。SIP 会议网关服务支持以下能力：
「容灾能力」：接入服务器和转码服务器都具有热备功能，在服务器宕机时，系统能在 10 秒内自动切换，用户无需手动操作，视频会议可以继续进行；
「布局样式」：支持参会者姓名、头像、静音状态等元素的绘制，支持演讲者视图、画廊视图、缩略视图等多种布局，用户可以在 SIP 终端通过 DTMF 按键实时切换布局；
「弱网对抗」：支持带宽自适应，在弱网环境下能动态调整视频和辅流的分辨率和帧率，针对 Cisco、Polycom、华为等厂商的 SIP 设备在 QoS 策略上的私有实现，我们也进行了适配，能够提供更加流畅的会议体验；
SIP 网关服务当前已经在应用在飞书视频会议，每天支撑数万台 SIP 设备的日常会议请求。
暂时无法在飞书文档外展示此内容
我们对 SIP 网关服务进行了扩展，增加了 PSTN 呼叫功能，打通了 RTC 终端和电话终端，为呼叫中心等业务场景提供了云端呼叫能力。
通过 SIP trunking 方式对接运营商的 PSTN 网关，实现了跟 PSTN 电话网络的信令互通，能够向 PSTN 网络发起电话外呼，也能够从 PSTN 网络接受呼入请求；
IVR 引擎，业务可以选择基于按键的传统 IVR 和基于语音识别的智能 IVR，IVR 流支持放音收号、菜单交互、条件判断等功能节点，可以基于不同的业务流程对 IVR 流灵活定义和编辑；
音频降噪，针对呼叫中心坐席人员工位密集，说话互相有干扰，背景声嘈杂等特点，我们对音频 AI 降噪算法做了专门的模型训练和优化适配，提升了通话音质；
该功能已经在飞书视频会议和抖音客服等业务落地。抖音客服平台采用了该方案后，将传统的话机坐席替换成集成了 RTC 客户端的软件坐席，不仅提高了运营效率，还为用户带来了更好的通话体验，用户满意度也显著提升。
作为定位于支撑更多 RTC 业务场景的应用平台，我们希望能够针对 RTC 业务领域的特点，提供更多原子能力和场景化解决方案，支撑客户更加便捷的接入和搭建自己的业务，持续提升业务质量，降低客户使用成本。我们会在以下方面做更长期的投入。
「原子能力更加丰富，框架更加灵活」：将基础能力和组件按照单一职责做更合理的拆解，并且创建和引入更多的原子能力，这些能力可以来自公司内部，也可以来自公司外第三方，可以是工程能力，也可以是算法能力。原子能力与业务逻辑的实现和迭代解耦，平台提供框架底座，业务通过对原子能力做灵活组装和调度，在平台上以插件化的形式进行开发。
「更好的业务性能，更低的资源成本：」 在并发性能、处理延迟和视频画质等方向提升产品能力上限。优化视频编辑、视频分析、视频编码、高清音质等场景下的算法性能。引入更多异构资源，包括不同类型的 CPU，GPU，FPGA，ARM等，根据不同任务的特点和需求最优化资源分配。探索算网融合，将计算和网络紧密结合，降低数据传输成本，减少数据传输延迟，提升业务体验。
「泛化平台能力，推动业务创新和多元化」：将平台构建起的一整套应用能力和解决方案泛化到其他相近的业务场景中，扩大业务的规模和多样性。随着生成式人工智能技术的突飞猛进，大模型已经能够与用户直接进行音视频互动，端到端的实时多模态交互已经成为趋势，RTC 的实时互动技术跟大模型的结合必将为各行各业带来更多的可能性和创新机会，我们也希望抓住这个机遇为客户带来更多的业务价值。
点击阅读原文，了解火山引擎 RTC 更多信息。
