本文讨论将计算机游戏服务器迁移到 Google Cloud Platform (GCP) 的注意事项。当今，大多数在线游戏都具有在虚拟或物理机器上运行的专用游戏服务器进程。本指南适用于熟悉在本地或云端运行专用游戏服务器进程的游戏开发者和运营团队。虽然在将游戏服务器迁移到 GCP 时需要考虑很多因素，但由此提升的灵活性可以带来很多好处，包括有利的结算模式，业界领先的全球基础架构和最新的云技术。本指南旨在帮助您了解如何迁移。游戏行业没有标准术语，因此就本文而言：

机器是指运行游戏服务器进程的物理机器或虚拟机。
游戏服务器是指游戏服务器进程。多个游戏服务器进程可以在一台机器上同时运行。
实例是指单个游戏服务器进程。

在 GCP 上运行游戏服务器的原因

越来越多的游戏工作室正在将他们的专用游戏服务器转移到云端，试图填补自有硬件设施与游戏发布期间难以估计的玩家需求之间的差距。如果能够无缝处理激增的服务器负载以及按需付费，就可以消除因发布游戏而带来的巨大风险。迁移带来的一些好处包括：

Google Compute Engine 虚拟机按分钟而不是按小时计费。持续使用折扣会自动应用于您运行的虚拟机，因此您无需预留容量和承担相关的费用风险。
自定义虚拟机规模允许您仅支付专用游戏服务器实际使用的 CPU 和内存量。
Compute Engine 虚拟机启动非常快，时间仅为几秒钟 (Linux) 或几分钟 (Windows)。
广泛的区域可用性使您可以将游戏服务器部署在靠近客户的位置。默认的全局网络空间允许这些服务器与现有服务轻松通信，而无需额外的工作。
只需几分钟即可为开发、质量检查测试或事件预配一次性环境，并在不再需要时立即将其丢弃，无需承担任何长期成本且不会影响其他环境。
您可将托管在 Google Cloud Storage 中的构建轻松配置为 CDN 来源，也可直接从存储分区中分发构建。
通过单独磁盘上的构建工件的快照，可轻松实现操作系统升级，还可使用符号链接将构建提升到生产环境。

使用项目来分离环境

将开发、测试、预演环境和公共环境按照不同的项目分离是业界的常见做法。这是因为项目是轻量级的，可以轻松创建和销毁。另一种流行的模式是为测试环境创建项目，部署构建，在冒烟测试中进行质量检查，并在构建准备好被提升或拒绝时销毁项目。这也保证了资源和配额的分离。例如，测试中的错误构建不会因过度消耗资源而影响生产服务。此外，销毁项目时总是删除其中的所有资源，确保您不会忘记删除那些需付费的测试或开发环境。

将构建迁移到云

将构建上传到 Cloud Storage 仅按每 GB 计算存储费用。在云端，可将上传的此构建轻松用作 CDN 来源，或将构建分发给其他工作室或承包商。您可以通过对象生命周期管理为上传的对象设置生存时间，保证管理开销的可管理性和费用限制。

分布

通常，业界会使用 Cloud Storage 等对象存储或永久性磁盘等块存储来托管云端的资产和二进制文件。如果您具有任何使用 Amazon Web Service S3 的现有进程，则可轻松修改或扩展这些进程以使用 Cloud Storage，因为它与 API 兼容。虽然将资产存储在 Cloud Storage 是将构建分发给客户、CDN 甚至远程办公室的好方式，但从 Cloud Storage 复制到游戏服务器虚拟机可能会增加加载时间，因此不建议使用此方法。许多拥有大量专用游戏服务器的客户已熟悉“复制”磁盘映像的模式，因为这些映像已拥有启动新的专用游戏服务器虚拟机所必需的所有库、资产和二进制文件。此策略在 GCP 上与在本地或其他云端一样有效。但是，建议将快照与只读磁盘配对，如下一节所述，因为这具有明显的优势。

将快照与只读磁盘配对的策略

在大多数游戏中，操作系统和游戏服务器的构建可以独立更改。建议不要将游戏构建放在操作系统磁盘上，而是放在单独的永久性磁盘上，并将必要的构建工件通过软链接或符号链接的方式指向其预期的目录。此设置创建了一个干净的工作流，用于将多个构建分发到虚拟机。只需将每个构建放在其自己的磁盘上，将所有磁盘连接到虚拟机，并在准备好更改游戏服务器版本时更新符号链接即可。您可以保留不同磁盘上的旧构建以实现快速回滚，直到您确信新版本稳定后再断开连接。您可以将永久性磁盘连接到多个虚拟机，从而节省费用并且无需将资产分发给所有虚拟机。

在将此方法作为游戏开发流水线的一部分实现时，我们建议您为构建系统配置必要的步骤来创建包含相应目录结构中所有工件文件的磁盘。例如，您可以使用运行 gcloud 命令的简单脚本，也可使用为您选择的构建系统运行 GCP 特定的插件。我们还建议您为磁盘创建多个副本，并让虚拟机以平衡的方式连接到这些副本，以满足吞吐量要求和管理故障风险。请注意，您可以同时从单个快照创建多个永久性磁盘，这是快速生成同一游戏服务器构建的多个磁盘副本的有效方法。

网络

GCP 运行在 Google 定制的专用光纤网络上，在主要大城市接入点 (PoP) 和 GCP 数据中心之间提供极低的延迟。通过 GCP 的网络模型，您可以尽可能地在托管服务器的区域与最靠近客户 ISP 的 Google PoP 之间保持与 Google 网络上至关重要的游戏内容相关流量。与其他供应商提供的更常见的 hot-potato 路由策略（试图在离开虚拟机时立即将流量路由到公共互联网）相比，Google 的网络可以为您的玩家提供更高的可靠性和更可预测的延迟。

此外，GCP 默认是一个全局网络空间。它无需使用 VPN 或其他网络软件连接不同的区域或地区。如果您在 us-central1-b 地区中启动虚拟机而在 eu-central1-a 启动另一个虚拟机，并将它们配置为使用相同的网络，则它们可以相互连接而无需其他配置。地区之间的所有流量都保留在 Google 的专用网络上，不会因 BGP 在公共互联网上引起的额外跳跃而产生延迟。

项目之间的网络

默认情况下，您创建的每个 GCP 项目都代表其隔离的全局网络。如果虚拟机在单独的项目（不连接公共互联网）中，则它们将无法彼此通信。尽管有多种方法可以建立跨项目网络，但我们建议您使用单个项目来运行您希望在专用网络空间中进行相互通信的服务器和服务。

游戏服务器的 GCP 网络

GCP 上专用游戏服务器最常见的网络模式是使用 Google Cloud Platform Console 创建游戏网络。为此网络配置适用于互联网流量的游戏端口，以及用于运行状况检查、监控或平台服务通信的任何所需内部端口。然后，在创建托管专用游戏服务器的虚拟机时指定此网络。

最佳做法

将游戏服务器迁移到 GCP 后，您可能会发现进一步优化服务器构建以使用 GCP 基础架构的好处。

vCPU 优化

每个 vCPU 的时钟速度相当稳定，但 Google 提供了包含若干最新款 Intel CPU 架构的云区域。一些游戏客户在使用架构特定的标志进行编译并在提供来自这些系列的 CPU 的区域中运行服务器时，发现 Linux 上的速度提升了高达 20％。vCPU 速度的这种一致性也适用于横向扩缩而不是纵向扩缩到 CPU 密集型任务的方法。如果可能，使用工作器线程并并行化代码以允许它使用多个 CPU，而不是需要从几个 CPU 中获得更多的使用周期。

网络优化

虽然流量出口是收费的，但入口不收费。因此，您可以考虑非对称通信模式，在这种模式中，来自客户端的数据包的更新速率高于来自服务器的数据包的更新速率。很多时候，通过内插或外推可以减轻较低服务器更新速率带来的影响。此外，如果您的客户端和服务器的封送处理/序列化代码足够有效，请考虑使用数据包压缩来保持较小的数据包大小。

分析事件和日志记录优化

可以考虑为 Google BigQuery 或 Cloud Storage 建立一个高容量的分析事件和日志记录路径，并使每个游戏服务器进程可以打开和关闭此功能。通过此方法，您可以快速调查报告的漏洞、分析游戏内容以获得平衡或生成 ML 训练数据。任一服务中存储数据都很便宜（目前每月存储 5 TB 数据的费用为 102.40 美元，且过往历史记录表明价格会稳步下降），而且此数据还可设置为在给定日期后自动过期，使您可以轻松控制费用和数据量。

游戏状态的外部化

我们在云游戏基础架构概览中简要介绍了外部化状态的潜在优势。值得考虑的是，游戏状态的哪些部分可以外部化。当前可以实现一定数量的外部化状态，并且今后每天都会有更多的云技术可以提高这种能力。外部化状态可以启用许多有趣的功能，例如：

允许在玩家游玩期间在虚拟机之间迁移游戏服务器进程，同时将中断降至最低。这个功能可以在许多场景中使用，包括：
协同定位在同一区域甚至同一虚拟机上建立大量服务器内通信的游戏服务器或服务，而不需要提前预测用户的流量模式。
隔离资源使用率较高的进程。
无缝实时迁移进程，无需关闭虚拟机以进行更新，也无需在高峰需求过去后移除进程以减少使用率。
允许多个进程在模拟的不同部分工作，并且仅在更大的范围内以类似共享内存的方式在彼此之间共享更新。
允许将状态序列化保存到磁盘或共享给另一个游戏服务器，这可以为电子竞技开辟新的可能性，例如：
服务器捕获的权威重放与监管链。
镜像专用游戏服务器，可让大量观众通过游戏客户端实时观看赛事。

后续步骤

云游戏基础架构概览
架构：优化分析事件和日志的大规模提取
在多个实例之间共享一个永久性磁盘
从快照创建永久性磁盘
试用其他 Google Cloud 功能。查阅我们的教程。

创作场景

专用游戏服务器迁移指南