应对突发流量激增：Edgegap 的 Orchestrator 如何为您的游戏进行弹性伸缩
您已将 Edgegap 游戏服务器和编排功能添加到您的游戏中（恭喜！），现在您已准备好迈出下一步——在现实世界中启动您的多人游戏服务器托管。
这可能会让人感到畏缩。如果它不能像之前的许多重大项目那样进行扩展该怎么办？
本指南旨在通过强调 Edgegap 如何处理流量激增来帮助您为游戏发布做好准备，从而使您的游戏能够与玩家需求同步扩展。
本文应与我们的“多人游戏发布前检查清单”结合使用。
Edgegap 如何管理其平台上未计划的突发尖峰负载？
首先也是最重要的一点，我们将每次部署都作为我们平台上的一个独特实体来处理。每次部署都是我们基础设施中的一个 pod。请求源自各种渠道，包括游戏客户端本身、匹配器或用户与我们的 API 交互的任何其他方式。
一旦请求到达我们的系统，我们就会立即启动对玩家的遥测和地理定位，并为我们的工作节点分配任务，以便在我们的基础设施上预配服务器。在一两秒钟内，容器就会启动并运行，准备好迎接涌入的玩家。
我们如何确保所有必要的基础设施都准备就绪，以便及时为这些部署提供服务？
我们开发了一个抽象层，负责监管 17 个不同的提供商，涵盖云、裸金属、边缘和容器即服务 (Container-as-a-Service) 提供商。它们共同为我们在全球范围内提供了 600 多个数据中心。
我们的提供商列表将亚马逊 (Amazon)、谷歌 (Google) 和微软 (Azure) 等提供全球服务的提供商，与针对特定国家或地区的本地化服务提供商融合在一起。这种互补的方法可确保您获得最佳的覆盖范围，从而让您的游戏可以利用世界上最大分布式边缘网络。
在我们的平台内，这些实体被称为接入点 (Access Points)，每个接入点都包含关键信息，例如容量、当前工作负载、可用资源以及其他用于决策的相关指标。得益于此抽象层，您无需担心玩家来自哪里，或者您需要与哪个提供商合作。
这使您可以专注于游戏，而 Edgegap 则专注于编排和管理底层基础设施。
Edgegap 的平台优先级是什么，其顺序如何？
Edgegap 平台的优先级将按以下顺序排列：
根据您在应用配置中指定的请求，为您提供一个运行良好的游戏服务器。
根据各种遥测测量数据，使游戏服务器尽可能靠近玩家，并采用最短的网络路径，以提供最佳的玩家体验。
尽快为您提供一个可以运行的游戏服务器。目标是 1-2 秒。
当我们遇到流量激增时（我们指的是在极短的时间内产生极大的流量；例如，每秒 40 次以上的部署，这意味着在一个 32 人的游戏中，每秒有 1300 名玩家试图进入比赛，即 60 分钟内有 460 万名玩家），在激增的前几分钟内，上述列表将变得更难提供。在那些极少数情况下，第 2 项（临近度）是第一个被放宽的：当系统向外扩展时，某些服务器可能会被放置在离玩家稍远的地方，以便仍然满足每个部署请求。
在出现计划外的流量激增时，平台通常需要多长时间才能稳定下来？
Edgegap 的平台经常在其托管的所有游戏中处理每秒远超 40 次的部署，因此日常的尖峰流量绝不会达到这个攀升速度。10-15 分钟的窗口期仅适用于极端情况：单款游戏突然增加每秒 40 次以上的未计划流量部署（一小时内约 460 万名玩家）。即便如此，服务器仍会继续部署。在新容量稳定下来之前，此款游戏的部署时间可能会超过 1-2 秒的目标，这可能需要长达 10-15 分钟。这是极端情况下的舰队容量攀升时间，并非典型的服务器启动时间。在正常情况下，服务器从冷启动到启动的中位数时间为 2 秒（2026年，平台数据）。
面对突发、计划外的流量激增，Edgegap 的应对方案是什么？
我们的容量管理器（绰号 “Capman”）已准备好应对涌入的流量，并与请求资源的 worker 进行对接。
当它检测到需求增加时，它会通过部署更大的机器来自动扩容需要资源的特定区域。如果它检测到某个地理区域需要额外的支持，它会在那里预配更多机器，以优化延迟和玩家体验。所有这些都是自动完成的。
对于需要大量 CPU 的较大尖峰（即每个实例需要 2 个 CPU 的游戏服务器），首次扩容需要 2 到 5 分钟。之后，由于系统会请求更大的服务器，因此扩容速度会快得多。它会根据流入的流量来调整向每个提供商请求的服务器大小，并随着流入流量的加速或减速请求较小或较大的服务器。
简而言之：对于 CPU 密集型激增，首次扩容需要 2 到 5 分钟。在极端的计划外激增（单款游戏每秒 40 次以上的部署）期间，完全稳定可能需要长达 10-15 分钟，并且在此期间服务器会持续部署。标准的日常流量不会受到影响。
补充说明：当我们提前知晓某项活动（发布、补丁等）时，或者在正常扩缩容（典型的 24 小时流量）期间，这种情况不会发生。它仅适用于计划外的突发流量，例如，某位主播开始玩您的游戏，大量新玩家加入其中。
为什么这种情况在 24 小时内的标准扩容流量中不会发生，而只在计划外的突发流量中发生？
为了管理每日流量，我们的平台设计为随着每日高峰向西穿过时区而移动，提前扩容下一个活跃区域。
通过利用预测分析和监控流量模式，我们能够预测流量高峰可能在何时何地发生。我们的基础设施会在这些高峰期到来之前主动调整其容量。
这种主动扩容确保了在需要的时间和地点提供必要的资源，即使在高需求期间也能保持流畅的游戏体验。
当 Edgegap 的接入点不足，并且新分配的接入点位于远离玩家的区域时，会表现出什么行为？
当请求部署时，平台会根据可用资源做出最佳决策。如果平台收到针对特定区域的计划外的大量请求，则在系统扩容期间，该区域的资源可能会变得匮乏。
在这种情况下，并且仅在系统扩容期间，服务器可能被放置在比最初最佳位置稍远的地方。
我们的目标是无论在什么情况下都始终拥有容量。这些最坏的情况极少发生，并且是暂时的，因为系统会进行扩容并学习新的流量行为。
我该怎么做才能从 Edgegap 平台获得最佳性能？
在计划中的流量激增之前，您可以采取以下措施来充分利用我们的平台。
以下是检查清单：
进行沟通！
如果您知道您的游戏将发生某些活动，例如发布、补丁、锦标赛、主播活动，请让团队知晓。
提前与 Edgegap 分享的计划内活动（发布、补丁、锦标赛）不受此容量爬坡的影响，因为容量已被预热。
这仅推荐用于大型计划内活动，因为平台会随着时间的推移学习您的流量模式（即 24 小时内的流量低谷和高峰）并相应地进行扩缩容。
为了避免超时错误，您可以通过仪表板或我们的 API 增加 AppVersion 的 "max_time_to_deploy" 值。
超时是指我们的系统在将游戏服务器（部署）标记为错误之前将等待的时间。在极端激增期间，导致激增的游戏的单个部署可能需要比平时更长的时间才能准备就绪。平台上的其他游戏不受影响。
将此超时值设置得稍高一些，可以防止在流量激增期间耗时稍长的部署被我们的平台标记为错误。
我们建议将您的系统（即大厅、匹配器）设置为在这种情况下进行重试。
平台将始终尽一切可能通过简单的 API 调用为您提供游戏服务器。即便如此，在极短的时间内产生极高（我们指的是极其高！）的流量可能会迫使我们的系统返回错误消息。在您的匹配器中构建带有指数退避（每次尝试之间等待更长时间，绝不要每秒重新轮询）的重试逻辑。对于任何处于突发负载下的编排器，这都是标准的弹性实践。
虽然在关于性能的文档中谈论灾难恢复计划可能看起来有些反直觉，但我们认为覆盖每个场景的每一个方面是我们工作和运营的核心。
我们的系统基于微服务架构，具有高度弹性的组件。
这些组件与供应商无关：它们可以在任何提供商上运行，并且可以轻松部署或重新部署以增加容量，或者在发生灾难性故障时重新安装新平台。
最重要的是，主服务不需要非关键组件，因此编排和托管游戏服务器始终是重中之重。
通过压力测试进行准备！
没有比通过压力测试更好的方法来评估您的游戏基础设施（从 Edgegap 到游戏服务）的表现了。
我们强烈建议在您发布之前运行一次，因为这是我们发布前检查清单的一部分。查看文章以了解更多详情。
我们如何维持具有竞争力的定价？
随着流量趋于稳定，我们的自动化系统会缩减基础设施规模，同时保留服务玩家所需的容量。系统会持续监控流量模式和使用趋势，并通过预测分析预测需求，从而提前调整容量。
成本优化不仅仅是缩减规模。我们会不断评估对每个提供商的使用方式，包括保留实例等选项。保持精简的基础设施使我们能够将这些节省的资金回馈给客户，而不会牺牲性能或可靠性。
结论
Edgegap 做了很多工作来确保无论您的游戏获得多大的流量，它都能迅速扩展以满足玩家的需求。
尽管如此，您仍然可以做很多事情来提前规划并防止错误。我们希望本指南能帮助您改进您的后端，并最终让您高枕无忧：您的多人游戏在构建时就考虑到了随玩家需求而扩展，并且您的玩家能够获得有趣、流畅的体验。
书写者
菲利普·科特 (首席技术官)
与来源和/或内容协作
由 Gabriel Parent（总监）进行格式化。
