1. 为什么 RTC 要做全球化
RTC（Real Time Communication）是音视频基础设施，它已经融入了咱们生活的方方面面：工作中，咱们组织视频会议，即便团队成员身处异国，也能确保项目推动；歇息时，咱们翻开抖音，看主播直播连麦；来一局游戏时，咱们翻开小队语音，大杀四方；学习时，咱们团聚线上互动讲堂，常识传达不再受间隔的枷锁。RTC 拉近了咱们的间隔，丰富了咱们的生活。
在这些场景里，咱们最不能忍耐的是什么？是推迟！想象一下，开会或者主播连麦时，一个人讲完话，其他人隔 10 秒才干做出反响，这几乎是完全不能承受的体会。
那么什么样的推迟才是好的体会呢？依据 ITU-T G.114 的主张：延时低于 400ms 的通话体会是可承受的，低于 200ms 是令人愉悦的。
ITU-T G.114
在没有全球化的状况下，RTC 需求在公共互联网上进行长间隔、跨国的网络传输，有许多因素会影响到通话质量：
- 间隔越长，中间经过的路由节点越多，全体毛病概率越大（软硬件问题，带宽问题，DDoS 等）
- 跨运营商网络问题
- 跨国网络问题
- ……
以纽约到深圳的数据为例：单向推迟最差的时分超越 1s，日常有 20% 左右的丢包。经过在纽约和深圳的设备进行实验，能看到通话树立成功的概率只要 30%，音视频推迟、卡顿十分严峻。
RTC 做全球化的目的便是：下降延时，供给愉悦的 RTC 体会 。
2. 全球化架构分化
在对 RTC 进行全球化架构规划之前，咱们需求先了解下 RTC 的事务逻辑。RTC 的一切应用场景都可以简化成一次通话。我将通话的流程做了简化，它包含下面的步骤：
- 给信令服务器发送参加房间请求（同一个房间内的用户才干相互通话）
- 给信令服务器发送发布、订阅请求
- 信令服务器回来媒体服务器地址（信令服务器和媒体服务器对资源的要求不同，一般来说是两种不同的服务器）
- 用户和媒体服务器建连，开端发布、订阅音视频数据
这样一次通话就完成了。咱们可以看到，通话进程被分为了两部分，信令交互和媒体交互，因而：RTC 全球化 = 信令全球化 + 媒体全球化。下面咱们就分别介绍一下火山引擎 RTC 在媒体全球化上的实践和在信令全球化上的架构演进。
3. 媒体全球化
3.1 机房建造
火山引擎 RTC 在全球建造了许多边际机房，掩盖 200+ 国家和区域。除自建机房外，全球还有 20+ 边际云供货商。
3.2 就近接入
建造如此多的边际机房，目的便是为了让用户能接入到离自己最近、最优质的边际节点。
这儿介绍一下就近接入的逻辑：
- 用户请求分配边际节点。
- 中心机房的调度服务从请求中获取用户的真实 IP（脱敏）。
- 带着 IP，经过查询 IPIP 数据库，可以拿到用户的地理位置、ISP 等信息。
- 在存储边际节点的数据库中，经过计算间隔、是否同运营商等战略，挑选最优的一系列节点回来给用户。
- 用户接入边际节点。
就近接入的流程大致如上，得益于边际节点的广泛掩盖，全球用户到火山引擎 RTC 边际节点的单向均匀延时仅为 70ms。
这儿需求留意的是中心将会回来一系列节点，原因会在安稳性部分化释。就近接入优化了用户第一公里的质量，但在实际场景中，仅有就近接入一个战略是不行的。这儿要先介绍一个概念：级联，假定两个用户通话，用户分别衔接到 A、B 两台媒体服务器上，那么 A、B 服务器之间要相互拉流，服务器间拉流的操作就被称作级联。
假定这样一个场景，一个 4 人会议，User1 和 User2 发言，User3 和 User4 是听众，一切人都衔接在不同的媒体服务器上，咱们可以数一下，总共将产生 6 路级联流（假定每人只发 1 路音频，不开摄像头）。
级联流过多，会造成许多的带宽糟蹋，下降体系容量。为了处理这个问题，咱们完成了一套边际聚合的战略。
3.3 边际聚合
顾名思义，要害在聚合。一个房间内的用户，在质量答应的范围内，会尽量分配同一个边际节点，仍是上面的场景，假定 User1 和 User2 在一个工区，User3 和 User4 在一个工区，那么最终会形成这样的推拉流结构：
级联流的数量从 6 个下降到了 2 个，极大下降了体系的压力。
就近接入与边际聚合是两个互斥的战略，想要用好他们，要害就在于对不同场景下质量的把控，在两个战略傍边找到平衡点，这是一个十分值得深入研究的论题，但限于篇幅，这儿不再赘述。
3.4 实时传输网
如上面所举的比方，即便有边际聚合，级联流量也是不可能完全从体系中消失的。两个人假如间隔很远，在确保用户的接入网络质量的前提下，他们之间的通话必然会产生级联。
咱们的边际节点都是运行在公共互联网之上，而公共互联网是一个尽力而为（ Best Effort） 的网络，特别是在长间隔、跨国传输的场景下，质量是无法得到确保的。该怎么确保级联的网络质量呢？
咱们在尽力而为的公共互联网上，经过广泛掩盖的边际节点进行转发，构建了一张 Overlay 网络，供给有 QoS 保障的全球网络传输服务。
实时传输网的首要职责有两个：
- 为两点之间供给最优质（延时、丢包，安稳性）的链路进行传输
- 在链路毛病时，主动切换到可用链路
公网
实时传输网
上面是公网和实时传输网同一时刻的质量比照，可以很明显地看出，实时传输网的传输质量远高于公网（图片右上角有色彩的阐明，绿色最优，黑色最差）。
3.5 安稳性
前面讲到，咱们的边际节点数量许多，掩盖很广，这也意味着，节点出问题的状况会许多，安稳性是咱们不得不面对的一个问题。这儿简略介绍咱们的一些安稳性战略：
- 同一区域引入多家供货商，减少单点。
- 之前说到过，咱们会给用户一起下发多个边际节点地址，边际可以择优衔接，一旦通话进程中节点毛病，可以快速切换。
- 针对毛病节点的负反馈机制，如上图，当 SDK 发现 110.119.120.1 连不通，会进行负反馈上报，中心服务会将此节点拉黑。
4. 信令全球化
信令的全球化规划经过了 5 个版别的迭代，有的规划活到了现在，有的规划被更好的规划掩盖，接下来将介绍整个演进进程。
在信令全球化的规划中，要一直留意两点：
- 房间中的用户能相互感知（有必要满意），一旦无法感知，相当于房间脑裂，无法感知对方，是失利的规划。
- 信令能被尽快处理（极致寻求）。
4.1 V1.0: 单中心
初代版别咱们在全球只要一个中心机房，一切的信令都经过动态加快回源到这个中心。国内的用户质量还能承受，海外的质量就比较糟糕，连不通也是常有的事情。单中心还有一个更大的问题，假如这个中心机房有毛病，RTC 将无法容灾。
这一阶段信令的均匀延时是：
- 国内 250ms。
- 海外 1s+。
由于体会和安稳性的原因，咱们在这一阶段只停留了很短的时刻，就马上进行了多中心的建造。
4.2 V2.0: 多中心+中心化房间
为了处理 V1.0 版别的容灾问题，咱们在全球建造了多个中心机房，并在机房内进行了单元化部署。
多个机房意味着同一房间内的用户可以连到不同的机房，信令全球化最初说到了两个留意点，其中之一是要确保房间内的用户可以相互感知，这一版别咱们采用了中心化房间的规划。
中心化房间便是：一个房间（包含房间、用户、流等）的信息只归于一个中心机房，为此咱们引入了一个新的服务：region，由它来负责对房间归于哪个中心机房进行决议计划，region 要确保全球数据的一致性，不然房间会脑裂。
简略描述下中心化房间的信令处理流程：
- 用户将信令投递给离他最近的中心机房。
- 机房内的 Gateway 从信令音讯中提取 AppID，RoomID 等信息，并请求 region 服务。
- region 进行房间归属决议计划（确保一致性），回来给 Gateway。
- Gateway 将信令投递给对应机房的信令服务，假如房间不归于本机房，就进行跨机房调用。
留意，只要第一条音讯需求请求 region，后面的信令音讯依据缓存的房间归属进行投递即可。此计划使就近处理信令成为了可能，比方一个事务用户首要在东南亚，用户衔接在新加坡机房，那么咱们可以在 region 中针对此事务进行一些装备，让房间决议计划尽量落在新加坡机房，用户的信令就能直接在本机房处理。
但是假如事务的用户全球都有散布，仍是会有许多信令需求进行跨机房投递，推迟仍然会比较高，本阶段的均匀延时大概为：
- 房间归于本机房：300~500ms。
- 房间归于其他机房：400ms+（假如跨机房网络颤动，会很差）。
中心化房间还有一些其他问题：
- region 需求确保全球一致性，对服务的要求极高，简单成为安稳性和功能的瓶颈。
- 由于信令只归于一个机房，当这个机房毛病，用户切换到其他机房时，会发现并没有相关的数据，用户需求重新进房、发布、订阅，这关于用户体会也是不行友爱的。
4.3 V3.0: 散布式房间
散布式房间的架构可以很好地处理中心化房间的问题。散布式房间一直是咱们规划中的架构，但是由于杂乱度的问题，并没有立刻投入开发。它的改造要比中心化房间杂乱许多，因而先完成了的中心化房间来提升体会。现在，是时分去攀爬这座山峰了。
散布式房间是指：一个房间内的信息在多个中心机房内都有完整的数据。因而，咱们需求对数据进行全球化同步，此外，中心化房间中的 Gateway 和 region 服务都不再需求了。
整个改造关于事务逻辑调整很大，延时上也取得了很大的前进，这一阶段的信令均匀延时在 300ms 左右。受限于篇幅，这儿只介绍散布式房间架构中两个比较要害的技能完成。
4.3.1 同步形式
在进行数据同步时会发现，咱们的数据量太大了，同步占用的带宽、CPU、存储占用都许多。但是关于一些接入方来说，这些数据同步并没有意义，不会被运用到。
为此咱们规划了两种同步形式：全同步与半同步
同步形式自适应切换
全同步与半同步在 RTC 中会自适应切换，咱们的离线分析工具会定时分析各个事务方房间的磕碰状况，假如一段时刻内磕碰的次数较多，就切到全同步，提升用户体会；假如磕碰次数减少到一定阈值，就降级到半同步。
4.3.2 牢靠传输通道
为了确保跨机房同步质量，咱们在这几个中心机房之间架设了专线，但是从实际运用看，专线的安稳性并不高，海缆、陆缆都有经常性的毛病，并且这种毛病修复十分困难，导致毛病时刻很长。
咱们为此开发了一个牢靠传输通道，它有如下特点：
- 增加公网 relay 节点，脱节对专线的强依靠。
- 多径传输，单条线路毛病对传输无影响。
- 音讯保序（RTC 对信令音讯的次序有极高要求）。
均匀一年咱们会遇到几十次专线毛病，火山引擎 RTC 基本每次都能平安度过。
4.4 V4.0: 一致接入
在V1.0 版别的架构规划中，当时咱们运用了动态加快这样一个服务，动态加快的原理是用户的请求直接发送到动态加快供货商的边际节点，这些边际节点进行内部转发，最终回源到事务的服务器。既然 RTC 有了掩盖这么广泛的边际节点，为什么不能用来加快信令音讯呢？
当然可以！咱们目前已经有了一个和边际节点通讯的媒体通道，让信令通道和媒体通道一致即可，也便是咱们现在说的一致接入，信令音讯经由边际节点转发给中心机房，均匀推迟优化到了 230ms（优化了 70ms 左右）。
4.5 V5.0: 边际下沉
“百尺竿头，更进一步”
咱们仿照了一套动态加快的完成，作用还不错。但是让咱们静下心来想一想，曾经“我”是运用动态加快的服务，现在“我”便是动态加快本身呀，这些边际都是我自己的边际，只用来做转发是不是太糟蹋了，为什么不能直接处理信令呢？假如能完成，那么许多请求将在边际直接回来，推迟将大大优化。
逻辑下沉
这一阶段咱们将进房、发布、订阅等逻辑下沉到了到了边际，加强了 RTC 的边际计算能力，信令的均匀推迟优化到了 100ms。
需求留意的是，尽管逻辑下沉到了边际，这并不代表中心机房就没有用了，在处理完请求后，会将音讯异步发送给中心机房，中心机房具有全局视野，会对信令进行进一步的处理，比方通知房间内的其他用户等。
4.6 安稳性
最终仍是讲一下安稳性的论题，上面说到，咱们现在在全球是多中心机房的架构，中心机房尽管比边际机房安稳一些，但也会有毛病的困扰，中心机房的毛病分为两类：接入毛病和服务毛病。
4.6.1 接入毛病
接入毛病分为两类：
- 接入网络毛病，为了提升体会，一般中心机房都是多线 BGP 接入，单线毛病时有发生。
- 处理思路也是多径传输，脱节对单条线路的依靠。
- 接入网关毛病，比方 nginx 毛病，此刻一切途径都会失利。
- 上面提过咱们的多机房建造，边际机房会对多机房进行实时探测，毛病时主动切换。
4.6.2 服务毛病
服务毛病时更常见的一种毛病，比方代码的 bug 被触发，强依靠的下游毛病，依靠的基础设施（mysql/redis/mq/…）毛病等。
咱们开发了一套主动运维体系：AIOps，它会实时监控机房的健康度，在健康度下降时主动切换到灾备机房。
4.7 回忆
信令的全球化从初版的“单中心”演进到了当时的“多中心+散布式房间+一致接入+边际下沉”的架构，在信令的处理延时上取得了显著的前进。
5. 总结
火山引擎 RTC 的全球化架构极大下降了信令和流媒体延时，端到端延时 200ms、400ms 达标率都达到了 99.0% 以上，可以说，在绝大多数的状况下，火山引擎 RTC 都能供给愉悦的实时音视频体会。
别的，得益于咱们在安稳性上的大力投入，即便面对边际节点毛病、机房毛病、专线毛病等突发事件时，火山引擎 RTC 也可以一直供给高质量、高可用的服务。
