火山引擎 RTC 全球化架构设计

动手点关注

干货不迷路

1. 为什么 RTC 要做全球化

RTC（Real Time Communication）是音视频基础设施，它已经融入了大家生活的方方面面：工作中，我们组织视频会议，即使团队成员身处异国，也能保证项目推进；休息时，我们打开抖音，看主播直播连麦；来一局游戏时，我们打开小队语音，大杀四方；学习时，我们相聚线上互动课堂，知识传播不再受距离的桎梏。RTC 拉近了大家的距离，丰富了大家的生活。

在这些场景里，我们最不能忍受的是什么？是延迟！想象一下，开会或者主播连麦时，一个人讲完话，其他人隔 10 秒才能做出反应，这几乎是完全不能接受的体验。

那么什么样的延迟才是好的体验呢？根据 ITU-T G.114 的建议：延时低于 400ms 的通话体验是可接受的，低于 200ms 是令人愉悦的。

ITU-T G.114

在没有全球化的情况下，RTC 需要在公共互联网上进行长距离、跨国的网络传输，有大量因素会影响到通话质量：

1. 距离越长，中间经过的路由节点越多，整体故障概率越大（软硬件问题，带宽问题，DDoS 等）

1. 跨运营商网络问题

1. 跨国网络问题

1. ......

以纽约到深圳的数据为例：单向延迟最差的时候超过 1s，日常有 20% 左右的丢包。通过在纽约和深圳的设备进行实验，能看到通话建立成功的概率只有 30%，音视频延迟、卡顿非常严重。

RTC 做全球化的目的就是：降低延时，提供愉悦的 RTC 体验 。

2. 全球化架构分解

在对 RTC 进行全球化架构设计之前，我们需要先了解下 RTC 的业务逻辑。RTC 的所有应用场景都可以简化成一次通话。我将通话的流程做了简化，它包含下面的步骤：

1. 给信令服务器发送加入房间请求（同一个房间内的用户才能互相通话）

1. 给信令服务器发送发布、订阅请求

1. 信令服务器返回媒体服务器地址（信令服务器和媒体服务器对资源的要求不同，一般来说是两种不同的服务器）

1. 用户和媒体服务器建连，开始发布、订阅音视频数据

这样一次通话就完成了。大家可以看到，通话过程被分为了两部分，信令交互和媒体交互，因此：RTC 全球化 = 信令全球化 + 媒体全球化。下面我们就分别介绍一下火山引擎 RTC 在媒体全球化上的实践和在信令全球化上的架构演进。

3. 媒体全球化

3.1 机房建设

火山引擎 RTC 在全球建设了大量边缘机房，覆盖 200+ 国家和地区。除自建机房外，全球还有 20+ 边缘云供应商。

3