支撑破纪录体验的基础设施

Roblox 能够扩展规模并支持数千万用户在数百万种独特体验中共同游玩，并非源于某一项单一创新。这是公司整体创新文化以及全公司范围内无数细节精益求精的综合结果。正是通过这种方式，我们构建了当前支撑 Roblox 上众多体验创下流量纪录的基础设施。 其中一款体验《Grow a Garden》近期以 2160 万同时在线玩家的成绩，打破了吉尼斯世界纪录®中“最多人同时游玩视频游戏”的纪录。在此过程中，Roblox 平台也持续刷新同时在线峰值纪录（这一趋势已持续近二十年），最近一次更突破了 3000 万同时在线玩家。

在构建和维护数百万款创作者自建体验（包括《Dress to Impress》、《Adopt Me》和《Dead Rails》）的基础设施时，Roblox面临着独特的挑战，这需要创新的工程方法。 该平台的基础设施不仅支持每小时数十次更新和超过3000万名同时在线用户，还能在突发流量高峰时实现弹性扩展。这种基础设施必须能够应对“雷霆之群”的极端场景——即超过2100万用户同时加入单一体验（且更新代码源自独立创作者）。Roblox工程师通过挑战传统思维来创新解决方案，这些方案正是源于我们的四大核心价值观。

在理想情况下，创作者根本无需考虑容量问题——基础设施应当对他们隐形，在幕后默默运行。当创作者将体验发布到 Roblox 时，无论有多少玩家参与，我们的工作就是确保提供所需的容量支持。 在早期，我们每年仅针对未来一到两年的需求进行一次容量规划。但近年来，随着《Dress to Impress》、《Fisch》、《Dead Rails》和《Grow a Garden》等热门体验的出现，我们开始重新审视容量规划的框架。

秉承“着眼长远”的核心价值观，我们现在会提前两年预测容量需求，在用户需求与服务器高效利用之间寻求平衡。我们的规划周期涵盖数据中心选址、服务器硬件升级以及物理网络建设，例如巴西数据中心等新项目往往需要提前数年规划。网络团队还会预留“备用”容量，以确保即使发生网络线缆断裂等问题，系统也能持续运行。

Roblox 当前的容量是基于两年前的预测确定的，当时我们无法预料到某些体验会在数周内从默默无闻一跃成为爆款。 像《Dress to Impress》和《Grow a Garden》这样的热门游戏，曾助力 Roblox 的峰值同时在线玩家数从 2025 年 4 月的 1390 万激增至 6 月的 3060 万，而这些游戏在当初进行容量预测时根本还不存在。例如，2025 年 3 月，《Dead Rails》的峰值同时在线用户数一度飙升至 100 万，耗尽了所有可用的 CPU 资源。 

鉴于此类流量激增的情况，我们已转为采用更敏捷的规划周期。为了持续支持Roblox创纪录的玩家数量，工程团队实施了严格的每周规划、测试和容量调整循环。周一专门用于事件复盘，周二进行容量规划。整个星期都会进行持续的压力测试。周四则专注于审查创作者预告的重大更新所需的容量。 周五会预先配置额外的云资源，确保平台能应对周末的峰值使用量。整个星期，我们持续发布全新功能，且不会限制所有工程师的持续部署。 

限流是计算机科学中一个广为接受的概念。但这也是计算机科学中最常被误用和误解的手段。当新工程师加入 Roblox 时，他们的首个解决方案往往是：“如果我们能告诉创作者调整这个配置，或者放慢他们的事件处理速度就好了……”。此时，Roblox 的资深工程师会温和地解释我们尊重社区的价值观，并说明我们不会告诉创作者该怎么做。 

例如，当数百万玩家同时点击“开始游戏”时，大多数游戏系统会采用简单的匹配方案：限制加入速度、让玩家等待，或者跳过匹配算法直接将玩家分配到随机服务器。而在Roblox，我们采取了截然不同的做法。我们重新设计了整个匹配系统，以应对如潮水般涌入的玩家。在高峰期，该系统每秒可评估多达40亿种可能的加入组合。 多年前，我们便确立了“10秒内处理1000万次加入请求”的目标，并持续迭代以实现这一目标。

为避免因容量限制而进行限流，我们在向蜂窝式基础设施转型的过程中，正尝试采用“云爆发”技术，以实现动态且计算高效的扩展。该架构通过将用户匹配至本地和云端边缘数据中心单元，从而应对峰值需求。 我们正致力于实现基于云的边缘数据中心的全自动化部署与撤销，这些数据中心对匹配算法而言已完全抽象化。

另一个例子是我们的文本过滤系统，其在峰值时每秒处理 250,000 次请求。这相当于一个大型模型推理任务，处理 250,000 个令牌，且上下文窗口在不断扩展。随着超过 300 个 AI 推理管道在生产环境中运行，Roblox 的服务负责人投入了大量时间，致力于在 GPU 和 CPU 之间寻找理想的推理配置组合。 即使在峰值负载下，Roblox 工程师仍始终尊重社区，将创作者的自由和用户的安全置于首位。

通过精心规划，我们构建了强大的处理能力和算法，以支持创作者发布最精彩的更新。但我们需要确保这些系统即使在面临最大流量峰值或单个服务中断时也能稳定运行。基于对1,600多个微服务在高峰时段的使用数据分析，我们能够确定哪些服务需要进行进一步的压力测试。

秉承“说到做到”的核心价值观，我们每天都会选取其中几项服务，在生产环境中对其容量进行限制。我们观察各项指标，并在周末前完成修复。我们将这一流程称为“实际容量测试”（TACO）星期二。 我们的可靠性团队还运行着持续容量正确性（C3）机制。每个工程团队都使用 C3 仪表盘来预测和管理其服务的 CPU 容量。这使服务负责人能够从上一次峰值中持续学习，从而为下一次峰值调整容量。我们还推出了一套系统，用于追踪 Roblox 核心引擎在新版本发布时的调用模式。这有助于确保我们在更新期间做好更充分的准备。 

即便做了所有这些准备，我们仍会偶尔遇到因流量模式不可预测性，导致单个服务或产品流程引发平台崩溃的情况。例如，由于某次热门更新，处理 2 万亿条事件的分析管道流量可能会增加 30%。此时，我们的弹性机制（如自适应并发控制 (ACC)、断路器和重试剔除）便会启动，以保护平台。 今年，我们还构建了一个混沌测试平台，通过在生产环境中随机注入故障、耗尽资源以及随机终止进程，来增强基础设施的弹性与可扩展性。

我们整周都在测试并为周末的大型更新做准备。但周末来临时，我们仍有工作要做。在周末更新前，Roblox工程师们通力协作，监控即将到来的变更并预测剩余容量，必要时通过虚拟边缘数据中心调配额外的云资源，以容纳数百万新增玩家。 

周五，我们会决定是否需要通过云资源增加额外容量。这一流程为我们的混合云团队提供了明确的指导方向，使其能够调配足够的额外容量，以容纳数百万新增玩家。 我们的 24 个物理边缘数据中心始终处于运行状态，但在完成所有测试后，我们可能会决定需要额外的边缘数据中心。由于无法在 12 小时内完成服务器的机架安装和堆叠，因此我们会与云合作伙伴合作，构建多个虚拟边缘数据中心。我们在周五对它们进行测试，然后就为周末做好了准备。 

秉承真正的责任担当精神，包括最高层管理人员在内的每位员工都参与轮值值班——即使在周末也不例外。周六数百万用户的涌入往往会触发数百条警报。各团队会预先解决这些警报，使我们能够应对重大更新或全平台历史最高流量带来的挑战。 

正如常被归因于莱昂纳多·达·芬奇的那句名言：“学习永不耗尽心智。”每次流量高峰都激励着我们学习并创新技术，使我们的基础设施更加可靠且无形。创作者发布或更新内容后，借助无形基础设施的魔力，数千万用户几乎能立即享受全新的体验。我们永远感激创作者和用户，正是他们的挑战推动我们不断突破计算机科学的边界。