在 Amazon GameLift 服务器上成功发布的开发阶段步骤

作者： Juho Jantunen, Sushil Ranganathan |

你正在开发一款多人游戏，但不确定如何在全球范围内高效托管、扩展和监控游戏服务器机群。你也在考虑如何高效地在世界各地进行会话，以获得优秀的玩家体验。从头开始构建所需的基础设施可能会让人不知所措。

我们推荐 Amazon GameLift 服务器，这是一项用于全球游戏服务器托管的完全托管服务。它可以帮助您减少多人游戏发布的运营工作和压力，因为该服务负责编排、全球会话放置和游戏会话生命周期管理。

在本博客系列中，我们将介绍为成功发布游戏做准备的关键注意事项。第一篇博客重点介绍在前期制作中应采取的行动，第二部分重点介绍发布前的准备工作（发布前 2-3 个月）。这些建议基于从初始集成到游戏发布为数百家游戏工作室提供支持的经验。

我们假设你有：

  • 熟悉 Amazon GameLift 服务器的基础知识
  • 游戏引擎和游戏开发知识
  • 对多人网络概念的理解

我们将介绍游戏发布早期规划的四个关键领域：

  1. 测试您的游戏服务器并选择实例类型
  2. 设置游戏会话生命周期管理
  3. 利用队列和队列事件进行会话放置
  4. 设置监控、记录和警报

测试您的游戏服务器并选择实例类型

您的游戏服务器测试通常从在本地测试游戏服务器开始。一旦本地服务器可以运行，下一步就是将其部署到 Amazon GameLift Servers 队列并测试该服务的性能。

以下是可衡量的关键指标，可帮助您确定正确的实例类型和大小：

  1. 资源消耗（内存密集型与 CPU 密集型对比）
  2. 你可以在每个实例上运行的游戏服务器容器或进程的数量
  3. 游戏服务器在具有最大玩家负载的实例上的性能

这个阶段可以通过小型舰队来完成，即使在一个区域中只有一个实例。建议此时创建单独的亚马逊云科技开发账户以进行资源隔离。您可以稍后添加其他环境，例如测试和生产。舰队的横向扩展非常线性，因此使用现实生活中的测试人员或机器人客户端将单个实例置于最大玩家负载下可以很好地了解游戏服务器的性能。

推荐的船队类型是集装箱舰队。容器队列允许定义每个游戏服务器的 vCPU 和内存要求。Amazon GameLift 服务器会自动在选定的实例类型上放置尽可能多的会话。

内置的 Amazon CloudWatch 指标可帮助您识别游戏服务器内存和 CPU 限制。您可以根据此测试使用数据进行调整，在 C 系列实例（需要更多 CPU 时）、M 系列实例（在内存和 CPU 之间取得平衡）和 R 系列实例（需要更多内存时）之间进行选择。大多数游戏将使用 C 系列或 M 系列实例，因为物理仿真会消耗大量 CPU 资源。

最新一代的实例由 Amazon GameLift 服务器支持，可提供优秀的性价比。使用基于 ARM 的亚马逊云科技 Graviton 实例可以进一步提高性能。

要选择所选实例类型可以容纳多少容器（在容器队列上）或游戏服务器进程（在 Amazon Elastic Compute Cloud (Amazon EC2) 队列上），您需要使用实际负载进行测试并监控性能。这可以通过测试组在玩游戏来完成，也可以使用游戏的无头机器人客户端来完成，这些客户端连接到服务器并使用预定义的脚本自动玩游戏。

该测试应使用客户端和服务器之间的实际数据流量来完成，因为仅在服务器上使用本地机器人测试仿真并不能全面了解性能。让机器人客户端或实际测试人员跨越多个区域也有助于更真实地了解地理网络流量延迟如何影响性能。

图 1 显示了通过 Amazon CloudWatch 指标和日志监控性能的用于生成游戏会话流量的机器人客户端。容器队列会自动将游戏服务器日志推送到亚马逊云观察，在亚马逊 EC2 队列上，你可以使用 CloudWatch 代理将日志推送到 CloudWatch。

美国东部-1地区的亚马逊GameLift服务器队列的架构显示了一个带有两个游戏会话的单个EC2实例。游戏会话连接到亚马逊云手表，以获取

图 1：测试游戏服务器的性能。

设置游戏会话生命周期管理

游戏服务器进程的生命周期中有几个关键要素，确保你已经考虑了所有要素对于保持舰队的健康至关重要。现在，让我们深入研究一下游戏服务器队列中的会话管理顺序。

启动时，游戏服务器进程与 Amazon GameLift Servers 建立通信，并将其状态报告为准备托管游戏会话。

游戏服务器进程按顺序调用以下服务器 SDK 操作：

  1. 初始化游戏服务器
  2. 宣布服务器准备就绪
  3. 评估游戏服务器运行状况
  4. 处理游戏会话事件
  5. 终止游戏会话

  1. 初始化游戏服务器

服务器以 InitSDK call 方法启动。此函数对您的服务器进程进行身份验证，并为 Amazon GameLift 服务器的编排做好准备。

注意事项：

    • InitSDK 在服务器进程启动期间拨打第一个电话，立即与 Amazon GameLift 服务器建立通信。
    • 记录和处理 SDK 初始化错误，以防止静默失败并协助进行队列监控。

  1. 宣布服务器准备就绪

加载资源和游戏逻辑后，调用 ProcessReady 以通知 Amazon GameLift 服务器该进程已准备好托管游戏会话。此调用还报告进程的连接信息，游戏客户端使用这些信息来连接游戏会话。Amazon GameLift 服务器将游戏服务器进程的状态更新为 ACTIVE，可以托管新的游戏会话。

注意事项：

    • 仅 ProcessReady 在所有初始化完成后才调用，避免重复调用。
    • 提供所有必需的回调，例如 OnStartGameSession 和 OnHealthCheck，并实现正确的错误处理和重试。
    • 在 EC2 队列上提供准确的日志路径，以确认从 Amazon GameLift 服务器控制台或通过 API 访问会话日志。

  1. 评估游戏服务器运行状况

服务器进程设置为 ACTIVE 后，Amazon GameLift Servers 开始定期调用 OnHealthCheck 回调，向游戏服务器进程请求运行状况。如果该流程报告运行状况不佳或未响应运行状况检查，则该服务会更改该进程的活动状态并将其替换为新进程。

注意事项：

    • 使用服务器 SDK 实现强大的 OnHealthCheck 回调，在响应真实之前，它会正确验证您的服务器运行状况良好。

  1. 处理游戏会话事件

当玩家请求加入游戏时，游戏客户端会将请求发送到后端服务，后端服务可能会调用 StartGameSessionPlacement 或 CreateGameSession 启动新的会话。该服务在队列中搜索可用的服务器进程。找到后，它会创建一个游戏会话并调用回调。OnStartGameSession 然后，服务器在准备就绪 ActivateGameSession 后调用，而 Amazon GameLift 会将会话从 "待处理" 更新为 "活动" 并完成投放。

注意事项：

    • 确保只有在您收到 OnStartGameSession Amazon GameLift Servers 希望您的服务器进程开始托管新游戏会话时调用此回调后，才有玩家连接。这将减少在实际游戏加载之前与服务器进行任何探测连接的问题。
    • 只有 ActivateGameSession 在正确设置了游戏地图、任何其他配置并完全准备好主持会话后，才会调用 OnStartGameSession 回调。调用 ActivateGameSession 会通知 Amazon GameLift 服务，服务器已完成托管新游戏会话的初始化，现在已准备好接收传入流量以建立玩家连接。
    • 当流程等待会话放置长达几天时，请确保在运行状况检查中所有系统仍能正常运行。这适用于您提前设置舰队的情况，但您只能在以后收到该队列的生产流量，以及当玩家流量根据一天中的时间发生变化时才会收到该舰队的生产流量。某些地点有时可能无法获得会话展示位置。

  1. 终止游戏会话

在游戏会话结束时，服务器进程将游戏会话状态通知 Amazon GameLift 服务器。游戏服务器进程通过调用服务器 SDK 操作 ProcessEnding 启动关机。作为游戏会话终止的一部分，Amazon GameLift 服务器将游戏会话和服务器进程状态更改为 "已终止"。

注意事项：

    • 当游戏会话被放置在服务器上（OnStartGameSession 被调用），但玩家从不连接或断开连接时，实现备份进程终止机制。你要确保在这些情况下该过程正确结束，取而代之的是新的游戏服务器。
    • 不要将服务器进程重复用于多个会话。会话结束后，呼叫 ProcessEnding 并退出。这将立即触发新进程的创建和注册。
    • 在服务器可能退出的所有路径 ProcessEnding 上调用 Amazon GameLift Servers 软件开发工具包。这将确保它已被正确清理并立即替换为新的会话。

图 2 显示了游戏服务器进程的生命周期以及每个游戏服务器实现都应考虑的关键步骤。

游戏服务器进程生命周期示意图。它显示的箭头围成一圈地穿过多个步骤，从

图 2：游戏服务器生命周期。

利用队列和队列事件进行会话放置

与直接在队列上创建会话相比，Amazon GameLift 服务器队列具有多种好处。

队列：

  1. 如果第一个选项不可用，则可以故障转移到辅助队列位置
  2. 可以在多个舰队之间进行会话
  3. 提供您的后端可以处理的会话放置事件
  4. 根据延迟和成本对目的地进行优先级排序

当你使用队列时，StartGameSessionPlacement 调用是你唯一需要使用的 API，其余的则通过队列事件进行管理。

使用队列时的优秀做法：

  1. 为队列设置超时时间，该超时定义如果找不到合适的容量，则何时认为放置失败。
  2. 如果您要为队列提供玩家延迟，请设置玩家延迟政策。确保你在此处设置的限制是现实的，这样你就不必等待很长时间才设定延迟值，而在大多数比赛中，游戏中的某些玩家都无法使用延迟值。即使没有玩家延迟策略，每当你向队列提供延迟数据时，会话都是根据这些信息进行的。默认行为以平均值为准，玩家延迟策略确保没有玩家超过最大延迟限制。
  3. 定义游戏会话放置优先级。对于大多数需求，我们建议采用默认行为，即优先考虑延迟，然后对所有注册队列进行成本排序。但是，如果您想首先使用 Amazon GameLift Anywhere 队列资源，无论延迟质量如何，都应将目标设置为第一优先级。

使用队列事件的优秀做法：

  1. 注册亚马逊简单通知服务（Amazon SNS）主题或使用亚马逊 EventBridge 接收游戏会话投放事件通知。
  2. 您可以为活动注册一个 Amazon Lambda 函数，并将事件数据存储到诸如亚马逊动态数据库之类的数据库，或者直接通过 WebSockets 向您的玩家发送更新。与使用描述 API 相比，使用事件具有极大的可扩展性。

图 3 显示了利用 Amazon GameLift 服务器队列通过订阅亚马逊 SNS 主题来放置游戏会话和处理事件的标准高级架构。

架构中，玩家使用箭头

图 3：使用 Amazon GameLift 服务器队列的标准架构。

如果您没有使用延迟策略，并且需要使用确切的位置偏好设置进行会话，则可以在 StartGameSessionPlacement 请求中定义优先级配置替代。如果你的游戏设计让玩家能够选择特定位置或从优先位置列表中，这很有用。如果您的媒人提供优先级列表，而不是单独提供每个位置的延迟，这也很有用。

如果你使用 Amazon GameLift Servers FlexMatch 作为媒人，它将原生集成到你定义的队列中。然后，您可以使用 FlexMatch 事件代替队列事件来跟踪会话放置过程。

设置指标、日志记录和警报

可观测性是了解环境中正在发生的事情的关键。Amazon GameLift 服务器有多种原生功能可以帮助解决这个问题。我们将介绍三个关键方面：日志、监控和警报。

日志

在容器队列上，您可以将游戏服务器的输出配置为无需任何其他工具或服务即可发送到亚马逊云手表或亚马逊简单存储服务（Amazon S3）。确保将游戏会话 ID 写入游戏服务器的输出中，以便在调试时搜索正确的日志文件。在 EC2 队列上，您可以在游戏会话终止后的 14 天内下载日志文件。如果你还想将日志推送到 EC2 队列上的 Amazon CloudWatch，亚马逊云科技游戏后端框架中的 Amazon GameLift Servers 集成指南可以帮助你设置 Amazon CloudWatch 代理来做到这一点。

从游戏服务器进程生成日志输出时，最好能够定义日志记录在日志系统中的详细程度。您可以在开发中使用更详细的登录信息，减少生产中收集的数据量。结构化日志输出（例如 JSON 格式）可以帮助利用 CloudWatch 查询功能。

此外，您可以运行 sidecar 容器，或者在 EC2 队列的实例上运行后台代理，将日志输出发送到任何第三方日志管理工具。

指标

Amazon GameLift 服务器提供广泛的 CloudWatch 指标。这包括有关队列中的实例和游戏会话、队列放置时间、资源利用率指标等的信息。这些指标可直接在 Amazon GameLift 服务器控制台和 CloudWatch 中获取。

需要监控的一些关键指标：

  1. 资源利用率：CPUutilization、MemoryUtilization（适用于集装箱船队）和。NetworkIn/NetworkOut这些指标概述了您的游戏服务器进程的性能以及它们使用了多少资源。
  2. 会话可用性:PercentAvailableGameSessions,AvailableGameSessions.这些指标将显示您的舰队的运行状况以及您进行新会话的能力。
  3. 潜在问题:UnhealthyInstancesReplaced和ServerProcessAbnormalTerminations.这些指标表明实例的资源不足，无法继续运行，以及进程无法正确退出的问题。
  4. 队列指标：AverageWaitTimePlacementsFailed、和PlacementsTimedOut。这些指标将为你提供队列生命值的指标：玩家进入比赛的速度以及他们的排名失败的频率。

与日志一样，您可以使用边车容器或 EC2 队列上的代理来收集有关任何其他系统的客户指标。这可能包括工具和服务，例如 OpenTelemetry 代理，用于收集 Prometheus 实例的指标，您可以使用 Grafana 对其进行可视化。

警报

警报是一种通知运营团队游戏后端出现问题的机制。您应该为表明可能问题的指标创建相应的警报。这些指标包括 PercentAvailableGameSessions（低或零）ServerProcessAbnormalTerminationsUnhealthyInstancesReplaced、PlacementsFailed 以及与您的需求相关的任何其他指标。此外，您还可以从 CloudWatch 日志中提取指标，并根据这些提取的指标创建警报。建议使用 JSON 格式从日志中快速提取指标。

图 4 显示了如何利用 CloudWatch 中的指标和日志来生成警报并通知待命团队有关挑战的示例。如果你使用 Prometheus 收集指标并使用 Grafana 对其进行可视化，也可以使用类似的方法。

使用亚马逊 GameLift Servers 全球队列向亚马逊 CloudWatch 发送指标和日志的架构。CloudWatch 正在根据指标生成警报，还从日志中提取指标以生成警报。建议使用 JSON 格式从日志中快速提取指标。

图 4：根据日志和指标向待命团队发出警报。

结论

我们介绍了使用 Amazon GameLift Servers 托管游戏服务器为成功发布游戏做好运营准备的基准。我们讨论了如何选择正确的实例类型和服务器流程或容器打包来确保您的配置性能良好、成本优化。我们还考虑了所有架构应如何利用队列来实现控制良好且基于事件的会话放置。最后，我们讨论了设置日志、监控和警报如何帮助您识别问题并收集有关游戏服务器性能的信息。

在该系列的第二篇博客《在 Amazon GameLift Servers 上成功发布的启动阶段步骤》中，我们将深入探讨如何做好发布游戏的准备。

立即开始使用用于多人游戏服务器托管的 Amazon GameLift 服务器。联系亚马逊云科技代表，了解我们如何帮助加速您的业务。

进一步阅读

  • 为游戏的发布做准备
  • Amazon GameLift 每款游戏实现了 1 亿并发连接用户
  • 为亚马逊云科技 Graviton EC2 实例编译虚幻引擎 5 专用服务器

Juho Jantunen

Juho Jantunen

Juho Jantunen 是亚马逊云科技游戏团队的全球首席解决方案架构师，专注于游戏后端和游戏服务器托管解决方案。他拥有游戏行业和云技术背景，曾在亚马逊云科技上为拥有数百万玩家的多款游戏构建和运营游戏后端。

Sushil Ranganathan

Sushil Ranganathan

苏希尔·兰加纳森是亚马逊云科技的高级技术客户经理。他拥有超过 12 年的行业经验，热衷于帮助战略行业的客户在亚马逊云科技云中构建和运营企业级解决方案。

*前述特定亚马逊云科技生成式人工智能相关的服务仅在亚马逊云科技海外区域可用，亚马逊云科技中国仅为帮助您发展海外业务和/或了解行业前沿技术选择推荐该服务。