我们如何让 Roblox 的基础设施更高效、更具韧性

随着 Roblox 在过去 16 多年中的发展，支撑数百万次沉浸式 3D 协作体验的技术基础设施的规模和复杂性也随之增长。我们支持的机器数量在过去两年中增长了三倍多，从 2021 年 6 月 30 日的约 36,000 台增加到如今的近 145,000 台。 为了支持全球用户随时随地的沉浸式体验，我们需要运行超过 1,000 个内部服务。为了有效控制成本并降低网络延迟，我们通过一套主要部署在本地、定制化的混合私有云基础设施来部署和管理这些服务器。  

我们的基础设施目前支持全球超过 7000 万日活跃用户，其中包括那些依赖 Roblox 经济体系开展业务的创作者。这数以百万计的用户都期待极高的可靠性。鉴于我们体验的沉浸式特性，对卡顿或延迟的容忍度极低，更不用说服务中断了。 Roblox 是一个沟通与连接的平台，人们在此通过沉浸式 3D 体验汇聚一堂。当人们以虚拟形象在沉浸式空间中交流时，哪怕是微小的延迟或故障，其影响也比在文字聊天或电话会议中更为明显。

2021年10月，我们遭遇了一次全系统范围的故障。起初只是某个数据中心的一个组件出现问题，规模很小。但在我们进行排查的过程中，故障迅速蔓延，最终导致系统停机长达73小时。当时，我们不仅详细披露了事件经过，还分享了从此次事件中获得的一些初步经验教训。 此后，我们持续研究这些经验教训，致力于增强基础设施的韧性，以应对所有大型系统中可能出现的各类故障——无论是因流量激增、天气因素、硬件故障、软件漏洞，还是单纯的人为失误所致。当这些故障发生时，我们如何确保单个组件或组件群组的问题不会蔓延至整个系统？ 过去两年，我们始终将这一问题作为核心关注点。虽然相关工作仍在持续推进，但迄今为止的成果已初见成效。例如，与2022年上半年相比，2023年上半年我们每月节省了1.25亿小时的用户使用时间。今天，我们将分享已取得的成果，以及关于构建更具韧性基础设施系统的长期愿景。

构建后备系统

在大型基础设施系统中，小规模故障每天都会发生多次。如果某台机器出现问题而必须停机，这尚可应对，因为大多数公司都会维护多个后端服务实例。因此，当单个实例发生故障时，其他实例会接管其工作负载。为应对这些频繁的故障，通常会设置请求在遇到错误时自动重试。

但当系统或用户重试过于激进时，情况就会变得棘手——这可能导致这些小规模故障在基础设施中向其他服务和系统蔓延。如果网络或用户持续不断地重试，最终将导致该服务的所有实例，甚至可能波及全球范围内的其他系统，陷入过载状态。 我们2021年的服务中断源于大型系统中相当常见的情况：故障起初规模很小，随后在系统中蔓延，并迅速扩大，以至于在整个系统崩溃前难以解决。 

故障发生时，我们仅有一个活跃的数据中心（其内部组件兼具备份功能）。当现有数据中心因故障瘫痪时，我们需要具备手动切换至新数据中心的能力。 我们的首要任务是确保拥有 Roblox 的备用部署，因此我们在位于不同地理区域的新数据中心构建了该备份。这为最坏情况提供了额外保障：即故障蔓延至数据中心内足够多的组件，导致其完全无法运行。目前，我们有一个数据中心处理工作负载（活动），另一个处于待机状态，作为备份（被动）。 我们的长期目标是将这种主-备架构升级为主-主架构，即两个数据中心同时处理工作负载，由负载均衡器根据延迟、容量和健康状况在两者之间分配请求。一旦该架构就位，我们预计整个 Roblox 的可靠性将进一步提升，且故障转移时间将从数小时缩短至近乎即时。

向单元化架构转型

我们的下一个重点是在每个数据中心内部构建坚固的防护墙，以降低整个数据中心瘫痪的风险。单元（某些公司称之为集群）本质上是一组机器，正是通过它们我们构建了这些防护墙。我们在单元内部及跨单元之间复制服务，以增加冗余。最终，我们希望 Roblox 上的所有服务都在单元中运行，从而同时受益于坚固的防护墙和冗余机制。 如果某个单元无法正常运行，可以安全地将其停用。跨单元复制确保了在单元修复期间服务仍能持续运行。在某些情况下，单元修复可能意味着对该单元进行彻底的重新配置。在整个行业中，擦除并重新配置单台机器或少量机器相当常见，但对包含约 1,400 台机器的整个单元进行此操作则并不常见。 

要实现这一点，这些单元必须保持高度统一，以便我们能够快速高效地将工作负载从一个单元迁移到另一个单元。我们设定了服务在单元中运行前必须满足的特定要求。例如，服务必须容器化，这使其具有更强的可移植性，并防止任何人进行操作系统级别的配置更改。 我们为单元采用了“基础设施即代码”的理念：在源代码仓库中，我们包含单元内所有组件的定义，以便通过自动化工具从零快速重建单元。 

目前并非所有服务都符合这些要求，因此我们致力于协助服务所有者在可行的情况下满足这些要求，并开发了新工具，以便在服务准备就绪时能轻松将其迁移到单元中。 例如，我们的新部署工具会自动将服务部署“条带化”分布到各个单元中，因此服务所有者无需考虑复制策略。这种严格的要求使得迁移过程更加困难且耗时，但长期收益将体现在： 

• 更易于控制故障，防止其蔓延至其他单元； 
• 我们的基础设施工程师能够更高效地工作并加快响应速度；以及 
• 负责构建最终部署在各单元中的产品级服务的工程师，无需了解或担心其服务正在哪个单元中运行。

应对更大挑战

正如防火门用于阻隔火焰一样，在我们的基础设施中，单元（cells）充当坚固的防爆墙，有助于将单个单元内引发故障的任何问题限制在该单元内。 最终，构成 Roblox 的所有服务都将在单个单元内部及跨单元之间进行冗余部署。这项工作完成后，问题仍可能扩散到足以使整个单元无法运行的程度，但问题要扩散到该单元之外将极其困难。而且，如果我们成功实现了单元互换，恢复速度将显著加快，因为我们可以切换到另一个单元，从而防止问题影响最终用户。 

棘手之处在于：如何在保持系统性能和功能的同时，将这些单元充分隔离以减少错误传播的机会。在复杂的基础设施系统中，服务需要相互通信以共享查询、信息、工作负载等。当我们将这些服务复制到各个单元时，必须深思熟虑地管理跨单元通信。在理想情况下，我们会将来自某个不健康单元的流量重定向到其他健康的单元。 但如何处理导致单元状态异常的“致命查询”？若将该查询重定向至其他单元，可能会导致目标单元也陷入我们试图避免的异常状态。我们需要找到机制，既能将“正常”流量从异常单元中转移，又能检测并拦截导致单元异常的流量。 

短期内，我们已在每个计算单元中部署了计算服务的副本，以便数据中心的大部分请求都能由单个单元处理。我们还在各单元之间进行流量负载均衡。放眼长远，我们已开始构建下一代服务发现流程，该流程将由服务网格所采用，我们希望在2024年完成这项工作。 这将使我们能够实施复杂的策略，仅在不会对故障转移单元产生负面影响的情况下允许跨单元通信。同样在2024年，我们将推出一种方法，用于将依赖性请求定向至同一单元内的服务版本，这将最大限度地减少跨单元流量，从而降低故障跨单元传播的风险。

在峰值时段，我们超过70%的后端服务流量来自跨单元处理，我们在单元构建方面积累了丰富经验，但随着2024年及以后服务迁移工作的持续推进，我们预计还将进行更多研究和测试。随着工作的深入，这些防护墙将变得越来越坚固。

迁移全天候运行的基础设施

Roblox 是一个面向全球用户的平台，因此我们无法在非高峰期或“停机时间”迁移服务，这使得将所有机器迁移到集群中，并让服务在这些集群中运行的过程变得更加复杂。 我们拥有数百万个需要持续运行的体验，即使在迁移其运行的机器及支持服务的同时，这些体验也必须保持正常运行。在启动这一流程时，我们并没有数万台闲置且可用于迁移这些工作负载的机器。 

不过，我们确实预先采购了一小批机器，以应对未来的增长需求。起初，我们利用这些机器构建了新的单元，随后将工作负载迁移至其中。 我们既重视效率也重视可靠性，因此当“备用”机器用尽时，我们并未外出采购更多机器，而是通过擦除并重新配置已迁移出的机器来构建更多单元。随后，我们将工作负载迁移到这些重新配置的机器上，并重新开始整个流程。 这一过程相当复杂——随着机器被替换并腾出空间用于构建单元，它们的释放并非以理想且有序的方式进行。这些机器在数据中心机房中物理上分散，迫使我们不得不零散地进行配置，这需要一个硬件级别的碎片整理过程，以确保硬件位置与大规模物理故障域保持一致。 

我们基础设施工程团队的一部分成员专注于将现有工作负载从旧系统（即“单元化前”环境）迁移至单元中。这项工作将持续进行，直至我们将数千种不同的基础设施服务和数千个后端服务迁移到新建的单元中。鉴于一些复杂因素，预计这将耗费明年全年，甚至可能延续至2025年。首先，这项工作需要构建强大的工具链。 例如，当部署新单元时，我们需要工具能自动对大量服务进行负载均衡——且不影响用户。此外，我们发现部分服务在构建时对基础设施存在预设假设。我们需要修改这些服务，确保它们不依赖于未来迁移至单元架构时可能发生变化的要素。 此外，我们既实现了用于筛查与单元架构不兼容的已知设计模式的机制，也针对每个迁移的服务建立了系统化的测试流程。这些流程有助于我们防范因服务与单元架构不兼容而引发的任何用户端问题。

目前，已有近 30,000 台机器由单元管理。虽然这仅占我们总机群的一小部分，但到目前为止，过渡非常顺利，未对玩家造成任何负面影响。 我们的最终目标是让系统每月实现99.99%的用户在线率，这意味着服务中断时间不会超过总参与时长的0.01%。虽然整个行业都无法完全消除停机时间，但我们的目标是将Roblox的停机时间降至几乎无法察觉的程度。

在扩展过程中确保未来适应性

尽管初期工作成效显著，但我们在“单元”技术上的探索远未结束。随着 Roblox 的持续扩展，我们将通过这项及其他技术，不断致力于提升系统的效率与韧性。随着工作的推进，平台将具备更强的抗故障能力，而任何可能出现的问题，对平台用户的可见度和干扰程度都将逐渐降低。

总而言之，迄今为止，我们已： 

• 建成了第二个数据中心，并成功实现了主动/被动模式。 
• 在主用和备用数据中心内创建了单元，并已将超过70%的后端服务流量成功迁移至这些单元。
• 制定了在继续迁移其余基础设施时，为保持所有单元一致性所需遵循的要求和最佳实践。 
• 启动了在各单元之间构建更坚固“隔离墙”的持续进程。 

随着这些单元之间的互换性增强，单元间的串扰将减少。这为我们在监控、故障排除乃至自动迁移工作负载方面的自动化提升，开辟了极具潜力的机遇。 

9 月，我们还在各数据中心启动了主动/主动（active/active）架构的实验。这是我们正在测试的另一种机制，旨在提高可靠性并最大限度地缩短故障转移时间。这些实验帮助我们识别出若干系统设计模式（主要围绕数据访问），在向完全主动/主动架构过渡的过程中，我们需要对这些模式进行重构。总体而言，实验非常成功，因此我们决定让其继续运行，以处理部分用户的流量。