支持创纪录体验的基础架构

Roblox 之所以能够扩展平台规模，支持数千万用户同时参与数百万个独特体验，并不是依赖某项单一的技术突破， 而是得益于公司内部持续创新的文化，以及无数细节的精益求精。 这正是我们能够构建起如今支撑 Roblox 众多创纪录体验的基础架构的原因。 其中一个代表性体验是Grow a Garden，它最近以 2160 万名用户同时在线的成绩打破了吉尼斯世界纪录®，成为同时在线玩家最多的视频游戏。 与此同时，Roblox 平台自身也不断刷新着并发用户峰值的纪录（这是我们近二十年来不断实现的目标），最近已突破 3000 万名并发玩家。

为像Dress to Impress、Adopt Me 和 Dead Rails 这样由创作者构建的海量体验提供支持，Roblox 面临着独特的基础架构挑战。这要求我们采用富有创造力的工程方法，构建一套能够承受突发流量高峰的基础架构。 平台需要支持每小时数十次的更新，并处理在“雷暴式涌入”（thundering herd）情况下—— 例如 2100 万名玩家瞬间进入由独立创作者发布的单一体验时——的系统稳定性。 Roblox 工程师通过挑战传统做法，提出创新解决方案，这些解决方案也深受我们四大核心价值观的启发。

Roblox 的工程团队管理着全球 24 个边缘数据中心，这些数据中心负责运行游戏服务器。 当用户加入某个体验时，系统会将其匹配到**最近的数据中心**以及该中心内**最合适的实例**，以最大限度减少延迟。 此外，Roblox 还运营着两个规模更大的**核心数据中心**，用于运行一系列集中式服务，例如网站、推荐算法、安全过滤、虚拟经济系统以及内容发布平台等——这些服务是边缘数据中心正常运行的基础。 一个**全球私有网络**将所有边缘数据中心与核心数据中心连接起来，其中边缘数据中心还承担着**防火墙的作用**，用于保护核心数据中心中运行的关键服务。

在理想的情况下，创作者根本无需考虑容量问题——基础设施应当对他们而言是“隐形”的，在幕后默默运作。 每当创作者将一个体验发布到 Roblox，我们的任务就是无论有多少玩家涌入，都能提供所需的容量支持。 在早期，我们通常按年度进行容量规划，一次性为接下来一到两年制定计划。 但近年来，随着Dress to Impress、Fisch、Dead Rails 和 Grow a Garden 等成功体验的出现，我们对容量规划的框架进行了重新思考。

秉持“着眼长远”的价值观，我们现在会提前预测未来长达两年的容量需求，努力在用户需求与服务器利用效率之间取得平衡。 我们的规划周期涵盖数据中心选址、服务器硬件更新以及物理网络部署，例如位于巴西的新数据中心就是提前数年规划的。 与此同时，网络团队还会预留“暗容量”，以确保在网络光缆断裂等突发状况下也能持续运营。

Roblox 目前的容量，其实是基于两年前的预测制定的——而在当时，我们无法预见某些体验会在短短几周内从默默无闻变得极度火爆。 像《Grow a Garden》和《Dress to Impress》这样的热门游戏，在 2025 年 4 月的并发玩家数为 1390 万，而到了 6 月竟翻倍增长至 3060 万；而这些体验在做容量预测时根本还不存在。 例如，在 2025 年 3 月，《Dead Rails》的并发玩家数暴涨至 100 万，占用了所有可用的 CPU 资源。

从这些“爆红”经验中吸取教训后，我们转向了更敏捷的规划周期。 为了持续支撑 Roblox 不断刷新的并发记录，工程团队每周都会执行严密的计划、测试与容量调整周期： 周一进行故障回顾，周二展开容量规划； 整周持续进行“混沌测试”（chaos testing），以检验平台在极端条件下的稳定性。 周四则评估来自创作者的大型更新所需的容量准备； 到了周五，我们会准备好额外的云端资源，以应对周末的流量高峰。 即使在执行这些准备工作的同时，工程团队也会持续发布全新的功能，且不会冻结持续部署的流程——这确保了 Roblox 能持续迭代创新，同时稳定运行。

限流（Throttling）在计算机科学中是一个被广泛接受的概念， 但它也是最常被误用和误解的手段之一。 新加入 Roblox 的工程师常常提出这样的解决方案：“如果我们能让创作者调整一下配置，或者让他们的事件慢一点就好了……” 而经验丰富的 Roblox 工程师则会温和地解释我们的核心价值观之一——尊重社区（Respect the Community），我们不会去告诉创作者该怎么做。

举例来说，大多数游戏平台在面对数百万玩家同时点击“开始游戏”时，通常会采用简单的解决方案： 限制加入速度、让玩家排队，或跳过匹配逻辑把玩家随机分配到服务器。 而在 Roblox，我们选择了完全相反的做法—— 我们为这种“雷鸣般的玩家涌入”重新设计了整个匹配系统。 该系统在高峰时段每秒可评估多达 40 亿种可能的匹配组合。 几年前，我们设定了一个目标：10 秒内处理 1000 万次加入请求，我们至今仍在不断优化以实现这一目标。

为了避免因容量问题而限流，我们正在将云爆发（cloud bursting）机制引入即将转型为的“蜂窝式架构”（cellular infrastructure）中，实现动态、计算高效的扩展能力。. 这种架构支持将用户匹配到本地和云端边缘数据中心单元（cell），以应对峰值需求。 我们的目标是实现对云端边缘数据中心的完全自动化部署与释放，并让匹配算法对此过程完全无感知。

另一个例子是我们的文本过滤系统，在高峰期每秒可处理多达 25 万次请求。 这相当于一个大型语言模型以不断扩展的上下文窗口处理每秒 25 万个 token 的推理量。 而我们在生产环境中运行着超过 300 条 AI 推理管线，为了在 GPU 和 CPU 之间找到最佳的推理组合，Roblox 的服务负责人投入了大量精力。 即使在高负载的情况下，Roblox 工程师也始终秉持“尊重社区”的信念，优先保障创作者的创作自由和用户的使用安全。

通过我们的规划，我们为创作者最令人期待的更新提前构建了所需的容量和算法。 但我们也必须确保这些系统能在最大流量高峰或单个服务宕机的情况下依然稳健运行。 我们会收集超过 1600 个微服务在高峰期的使用数据，识别出需要进一步进行压力测试的服务。

秉持“把事情做成”（Get Stuff Done）的价值观，我们每天都会在生产环境中对其中一些服务进行容量限制， 观察其表现并在周末前修复潜在问题。 我们称这一做法为 “TACO 星期二”（Test Actual Capacity On）。 同时，我们的可靠性团队还持续运行“持续容量正确性”（Continuous Capacity Correctness, 简称 C3）测试。 每个工程团队都会使用 C3 仪表板来预测和管理其服务的 CPU 容量， 从而根据上一次高峰的经验调整下一次高峰所需的容量。 我们还上线了一套新系统，用于追踪 Roblox 核心引擎在新版本中的调用模式， 以确保我们在更新发布时做好了充足准备。

尽管我们做了大量准备，偶尔仍会遇到因不可预测的流量模式导致某个服务或产品流程拖垮整个平台的情况。 例如，分析每年 2 万亿个事件的分析管道，可能会因一次热门更新而瞬间激增 30% 的流量。 此时，我们的韧性机制会自动介入保护平台，包括：自适应并发控制（Adaptive Concurrency Control, ACC）、断路器（Circuit Breaker）和请求重试削减机制（Shedding Retries）。 此外，今年我们还搭建了一套混沌测试平台，专门用于增强基础设施的弹性与可扩展性。这套平台会在生产环境中随机注入故障、耗尽资源，或随机终止进程，以确保我们即使面对最极端的突发状况，也能保证系统的稳定性和可靠性。

我们整整一周都在测试和准备这些重磅的周末更新， 但到了周末，我们仍然有很多工作要做。 在周末更新之前，Roblox 工程师们会通力协作，监控即将上线的变更并预测剩余的容量，根据需要预配额外的云资源，以通过虚拟边缘数据中心容纳数百万新增玩家。

每到周五，我们会决定是否需要通过云资源增加额外的容量。 这个流程能为我们的混合云团队提供明确指示，以便他们扩展足够的额外容量，支持数百万新增玩家的加入。 在任何时间点，我们的 24 个物理边缘数据中心都会正常运行，但经过一整周的测试，我们可能判断还需要额外的边缘数据中心。 不可能在 12 小时内组装和部署实体服务器，所以我们会与云服务合作伙伴一起构建多个虚拟边缘数据中心。 我们会在周五进行测试，确保万无一失，然后准备迎接周末的高峰流量。

本着真正“承担责任”的精神，包括我们最高层的管理人员在内，所有人都会参与值班轮岗——即使是在周末。 每到周六，数百万用户的激增常常会触发数百个系统警报。 各团队会提前处理这些警报，使我们能够从容应对重大更新或全平台历史峰值带来的各种挑战。

正如达·芬奇常被引用的一句话：“学习永远不会使人疲惫。”每一次流量高峰都激励我们不断学习，发明新的技术，让我们的基础设施变得更加可靠和无感知。 我们的创作者发布或更新内容，而在这套“隐形基础设施”的加持下，数千万用户几乎可以立刻畅玩全新的体验。 我们由衷地感谢创作者和用户，是你们不断挑战我们，推动我们突破计算机科学的极限。