从 Kubernetes 和 Agones 迁移到 Amazon GameLift 服务器

Kubernetes 搭配 Agones 是一种流行的开源专用游戏服务器托管方案。对于单集群、单 AWS 区域的部署，这为专用游戏服务器托管提供了良好的基础。但在全球生产规模下，Agones 的管理可能变得复杂，需要你在每个地点构建和运维多个支撑系统。这些包括安全的跨区域通信、私有网络对等连接、游戏会话分配器、匹配系统、监控系统以及 Agones 本身。而这还只是在你部署第一个游戏服务器之前。

运维复杂性及相关成本正是许多开发者选择 Amazon GameLift Servers 作为全托管全球游戏服务器托管服务的原因。除了管理全球游戏服务器编排之外，Amazon GameLift Servers 还免费提供内置的实时分布式拒绝服务（DDoS）防护和匹配功能。为显著降低总拥有成本，第六代及更新实例的价格中已包含数据出站流量费用。

Amazon GameLift Servers 还为整个全球游戏服务器编排提供 99.95% 的可用性 SLA。在基于 Agones 的方案中，底层 Amazon Elastic Kubernetes Service (Amazon EKS) SLA 之外的一切均由您自行负责。

在本篇文章中，我们将讨论这两种托管选项之间的一些差异，并介绍如何从基于 Agones 的实现迁移到 Amazon GameLift Servers。

关键运营与成本差异

在生产环境中，两种选项的主要差异集中在成本和运营复杂度方面。表 1 比较了这两个方面的运营特性。

特性	Amazon EKS 上的 Agones	Amazon GameLift Servers
容器控制平面	由您管理的 EKS 部署、版本升级和插件	内置
会话生命周期管理	由您在每个区域中运行的 Agones 控制器	内置
会话分配	由您运营的 Agones 分配器	内置
全局游戏服务器计算	您在每个区域中管理的 Amazon EKS 集群	内置
匹配	由您自行管理和运营（Open Match 或其他方案）	内置
监控	Amazon CloudWatch 上的容器洞察以及 Prometheus 和 Grafana 等解决方案	内置（您也可以添加 Prometheus 和 Grafana，具有内置集成支持）
集群自动扩缩	驱逐信号与 Karpenter	内置
远程位置集群与中心后端之间的通信	您构建的集群之间基于证书的安全通信	内置
跨区域复制容器镜像	由您管理	内置
蓝绿部署	由您构建的自定义持续集成和持续交付（CI/CD）解决方案	简单：透明地在游戏版本之间切换
游戏会话的 DDoS 防护	在每个区域中由您管理的自定义全球中继方案（Quilkin 或类似方案）	内置
Ping 端点	作为 Agones 基础设施的一部分部署，由您管理	内置
游戏服务器容器镜像	由您管理	由您管理

表 1 – 运维功能对比

基于 Agones 的生产就绪部署组件包括主区域中的 30–40 个 Pod，以及在部署第一个游戏服务器之前附加位置中的 20–25 个 Pod。这些是您负责监控、运维、打补丁、安全防护和付费的服务和工具。

在基于 Amazon GameLift Servers 的部署中，您只需上传一次构建，并定义全局车队及其配置。您无需负责支持工具，因为它们由该服务为您管理。

图 1 展示了全球生产就绪的基于 Agones 的部署与 Amazon GameLift Servers 部署之间的高层架构差异。

图 1 – 架构对比

在选择托管提供商时，成本同样重要。表 2 对比了各项成本组成部分。

成本组成部分	Amazon EKS 上的 Agones	Amazon GameLift Servers
容器控制平面	Amazon EKS 控制平面费用	已包含
游戏服务器计算	Amazon Elastic Compute Cloud（Amazon EC2）费用	GameLift Servers 计算费用（在 EC2 基础上约 20% 的溢价）
游戏服务器实例数据量	Amazon EBS 费用	包含
游戏服务器到玩家的数据出站流量	每 GB 数据出站传输费用	包含
支持服务（编排、分配、跨区域通信、ping 端点）	所有 AWS 区域中所有系统的 Amazon EC2 计算成本（每个区域超过 20 个 Pod）	已包含
DDoS 防护	每个区域中每个可用区的自定义中继层的计算成本	已包含
匹配	计算成本（Open Match 或类似服务）	已包含
监控	Container Insights 和自定义指标的成本（Prometheus 或 Grafana）	已包含（可通过 Prometheus 或 Grafana 进行额外监控，需额外付费）

表 2 – 成本对比

如表所示，成本由众多组成部分构成。两个关键成本组成部分是计算和数据出口流量。在 Amazon GameLift Servers 上，数据出口流量已包含在内，但在自定义 Agones 方案中，需按每 GB 流量付费。数据传输成本可占游戏服务器托管总成本的 40–50%。在计算方面，使用 Amazon GameLift Servers 需支付约 20% 的溢价，但无需为支持工具支付额外费用。在基于 Agones 的方案中，这些费用可能跨多个区域累积。Amazon GameLift Servers 内置了匹配和 DDoS 防护功能。这些功能若自行实现，可能产生显著成本。

包含数据出站流量及配套工具、匹配服务、数据量和高级 DDoS 防护功能，使 Amazon GameLift Servers 在几乎所有场景下都成为最具成本效益的解决方案。此外，这些功能由托管方式管理，降低了运维复杂度，使您能够专注于游戏服务器的实现与优化。

虽然我们已介绍了 Amazon GameLift Servers 在运维简便性、成本和功能方面的优势，但仍可能存在需要更自定义部署的场景。某些用例——例如需要游戏服务器节点之间紧密协调的大型分区 MMO 游戏——在 Amazon GameLift Servers 上可能难以实现。在单个进程中托管多达数百个游戏会话的基础中继服务器是另一个可能不适合该服务的用例。这是因为 Amazon GameLift Servers 围绕游戏会话与游戏服务器进程之间 1:1 映射进行设计。

从 Agones 迁移到 Amazon GameLift Servers

在从现有的基于 Agones 的解决方案迁移到 Amazon GameLift Servers 时，步骤相对简单：

将 Agones SDK 调用替换为 GameLift Server SDK，或使用 SDK 封装层
在所有游戏服务器上使用同一个私有端口
构建并将容器镜像推送到 Amazon Elastic Container Registry（Amazon ECR）
创建容器组定义
创建容器车队
将分配器替换为游戏会话队列（可选使用 FlexMatch）
将您的后端更新为调用 GameLift API 获取连接信息，以替代 Agones 分配器 API
停用 Agones 基础设施

让我们更详细地回顾这些步骤。

步骤 1：用 GameLift Server SDK 替换 Agones SDK，或使用 SDK 封装层

将您的 Agones SDK 集成（SDK.Ready()、SDK.Shutdown()、SDK.Health()）替换为 Amazon GameLift Servers SDK 的对应实现。关键的概念转变在于：Agones 采用拉取模式（您的服务器或外部分配器调用 Allocate()），而 Amazon GameLift Servers 采用推送模式（服务在放置会话时调用所选游戏服务器上的 OnStartGameSession 回调）。您需要实现 InitSDK() 以建立 WebSocket 连接，实现 ProcessReady() 并包含 OnStartGameSession 和 OnProcessTerminate 的回调处理器，然后实现 ProcessEnding() 以指示会话完成。Amazon GameLift Server SDK 提供 C++、C# 和 Go 版本，并可为 Unreal 和 Unity 提供插件。关于在 Amazon GameLift Servers 上成功发布游戏的开发阶段步骤的博客文章详细介绍了 SDK 集成和游戏会话生命周期管理的工作方式。

如果你不想进行完整的 SDK 集成，Containers Starter Kit 提供了一种 sidecar 方案。它会自动实现与服务所需的连接，而无需修改你的服务器构建。

步骤 2：在游戏服务器之间使用单个私有端口

Agones 不进行公网到私网的端口映射。它在每个 Kubernetes 节点上从一个配置的端口范围（例如 7000–7029）中直接分配主机端口。你的游戏服务器绑定到该端口，玩家则通过节点 IP 加上相同的端口号进行连接。在 Amazon GameLift Servers 上，你的容器定义一个内部端口，而该服务负责管理到 EC2 实例上外部端口的映射。这意味着你的游戏服务器代码无需知道或关心对外暴露的端口。你不需要使用 Agones SDK 来发现分配给你的主机端口并将其注册，而是绑定到内部端口，让 Amazon GameLift Servers 处理外部映射。当会话被放置时，该服务会向客户端返回正确的连接信息。以一款 Unreal 游戏为例，这可能意味着每个服务器都注册默认的 7777 端口。

步骤 3：构建容器镜像并将其推送到 Amazon ECR

Amazon GameLift Servers 容器集群从 Amazon ECR 拉取镜像。在您计划创建集群的同一 AWS 区域中创建一个私有 ECR 仓库，然后为游戏服务器镜像打标签并推送。您现有的 Dockerfile 通常可以按原样使用，或只需少量修改。在两种系统中，容器的入口点都是游戏服务器进程。前面分享的 Containers Starter Kit 可以自动化整个流程。

步骤 4：创建容器组定义

通过创建容器组定义来定义您的容器架构。这将替代您的 Agones Fleet 规范和 Pod 模板。指定容器组的 ECR 镜像 URI 以及 vCPU 和内存限制。您可以添加支持容器（边车容器）用于日志记录或监控。Amazon GameLift Servers 会根据您的资源限制和实例类型，自动计算每个 EC2 实例可以容纳多少个容器组副本。这与 Agones 根据资源请求将 Pod 打包到节点上的方式类似。同样，Containers Starter Kit 包含此步骤所需要求的自动化功能。

步骤 5：创建容器车队

创建一个托管容器舰队，指定容器组定义、EC2 实例类型和地理位置。这一单一资源可替代您的 EKS 集群、节点池、Agones 安装、Helm charts、cert-manager 以及多集群分配配置。Amazon GameLift Servers 负责实例配置、底层操作系统、容器部署、健康检查和自动扩缩。向单个舰队添加多个位置以实现多区域存在。无需 VPC 对等连接或跨集群 TLS 交换。从您的主区域到远程位置的通信完全由该服务管理。

步骤 6：用游戏会话队列（以及可选的 FlexMatch）替代您的分配器

创建一个指向您的机群的游戏会话队列。这将替代您的自定义 Director、多集群 Agones 分配器以及区域之间的 TLS/VPC 对等连接。该队列通过基于延迟或位置优先级的路由来处理跨位置的资源放置。如果您需要内置匹配功能，请配置 FlexMatch，使用规则集来定义队伍规模、技能范围和延迟容差。否则，直接从您的后端调用 StartGameSessionPlacement()，传入玩家延迟数据，让队列找到最佳位置。

步骤 7：更新您的后端，改为调用 GameLift API 获取连接信息，而非 Agones 分配器 API

您的后端服务目前通过查询 Agones allocator API 获取游戏服务器连接信息（来自 GameServer.Status 的 IP 和端口）。请将其替换为处理队列事件：当放置完成时，您会收到一条 Amazon Simple Notification Service（Amazon SNS）通知。如果您使用 FlexMatch 进行匹配，也可以使用 FlexMatch 事件。这些事件包含游戏会话 IP 地址、端口以及客户端用于向服务器验证连接的玩家会话 ID。Amazon GameLift Servers 提供可选的玩家会话管理功能：您可以采用该功能，也可以继续使用现有方案。基于事件的会话放置指南包含有效使用队列的架构和示例代码。

步骤 8：停用 Agones 基础设施

在流量完全迁移至 Amazon GameLift Servers 并验证通过后，停用 Agones 技术栈。这包括 EKS 集群（所有区域）、VPC 对等连接、Open Match 部署、cert-manager、Amazon ECR 复制规则以及相关的节点组。这将消除主区域中仅用于维持平台运行的 30-40 个系统 Pod，以及每个远程区域中的 20–25 个系统 Pod。

结论

我们从运维和成本两个角度讨论了基于 Agones 的方案与 Amazon GameLift Servers 之间的关键差异。我们发现，在运维方面，使用 Agones 需要承担的责任远多于使用 Amazon GameLift Servers。在成本方面，免费的数据出站流量、内置的辅助工具以及附加功能使得 Amazon GameLift Servers 在大多数情况下是更具成本优势的选择。

我们还展示了从 Agones 迁移到 Amazon GameLift Servers 的步骤。对于大多数游戏而言，这应该是一个简单且无痛的过程，游戏服务器和游戏后端逻辑只需进行最少的改动。

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