云游戏基础架构概览

Last reviewed 2022-01-28 UTC

此解决方案概述了用于在 Cloud Platform 上托管游戏基础架构的常见组件和设计模式。

在过去的几十年中，视频游戏已经发展为一项繁荣的娱乐业务。随着宽带互联网的普及，游戏业发展的关键因素之一就是在线游戏。

在线游戏有多种形式，例如基于会话的多人游戏对抗、大型多人游戏虚拟世界以及相互交织的单人游戏体验。

过去，使用客户端 - 服务器模型的游戏需要购买和维护专用的本地或共址服务器来运行在线基础架构，而这些只有大型工作室和发布商能够承受。 此外，还需要进行广泛的预测和容量规划，以求在满足客户需求的同时避免过度的固定硬件投资。 利用当今基于云的计算资源，任何规模的游戏开发者和发布商都可以按需请求和接收任何资源，从而避免高额的前期货币支出以及过多或过少的硬件预配带来的风险。

概要组件

下图演示了游戏架构的在线部分。

Google Cloud 上的游戏基础架构示意图以及前端和后端组件。

游戏架构的前端组件包括：

  • 游戏平台服务，提供额外的游戏相关功能。
  • 托管游戏的专用游戏服务器。

游戏架构的后端组件包括：

  • 游戏状态，永久存储在系统记录中，通常存储在游戏数据库中。
  • 分析栈，用于存储和查询分析和游戏内容事件。

这些组件可以托管在各种环境中，包括本地、私有云或公共云，甚至是完全托管的解决方案。只要系统满足组件与最终用户之间通信的延迟要求，任何这些托管形式都可以采用。

前端

前端提供客户端可直接或通过负载均衡层间接进行交互的接口。

例如，在基于会话的第一人称射击游戏中，前端通常包括 Open Match 这样的配对服务。该服务将专用游戏服务器实例的连接信息分发给客户端。

  1. 客户端向配对服务发送请求。
  2. 配对服务根据匹配条件将玩家分配到专用游戏服务器实例。
  3. 配对服务向客户端发送连接信息。
  4. 然后，客户端可以使用用户数据报协议 (UDP) 直接连接到专用游戏服务器实例。

前端服务不一定仅由由外部客户端使用， 前端服务之间彼此通信以及与后端通信都很常见。

但是，由于前端服务可以通过互联网访问，因此它们更可能受到攻击。您应该考虑强化前端服务安全，以抵御拒绝服务攻击和格式错误的数据包，帮助解决这些安全性和可靠性问题。相比之下，后端服务通常只能通过受信任的代码访问，因此可能更难被攻击。

游戏平台服务

此组件的通用名称是平台服务或在线服务。平台服务为基本的元游戏功能提供接口，例如允许玩家加入相同的专用游戏服务器实例，或者为您的游戏保留好友列表社交图。 您的游戏运行平台（例如 Steam、Xbox Live 或 Google Play Games）通常会提供这些服务：

  • 排行榜和对抗历史
  • 配对
  • 在线大厅
  • 聊天
  • 库存管理
  • 授权
  • 群组/组
  • 个人资料
  • 公会
  • 跨平台解锁
  • Feeds
  • 社会身份映射
  • 分析
  • 状态

与网络服务相比，游戏平台服务也在以类似的模式发展：

  • 在 21 世纪初，一套典型的平台服务会作为单体式应用服务运行，通常作为单例实现。即使在联合时，也不建议将此模式用于云部署。

  • 随着该行业将各种服务改为可独立扩缩，现在熟知的面向服务的架构模式 (SOA) 在 2000 年代中期开始流行。此外，现在不仅可以通过游戏客户端和服务器访问这些服务，还可以通过网络服务以及最终通过智能手机应用访问这些服务。

  • 在过去的五年中，许多开发者采用了快速扩缩型网络公司所倡导的微服务方法。这是因为平台服务和网络应用的许多基本挑战是相同的，例如在全球范围内实现快速开发周期和运行高度分布式服务。微服务可以帮助解决这些问题，因此对于设计在 Cloud Platform 上运行的应用是一个很好的选择。

  • 此外，现在有许多托管的服务可以提供构建平台服务或完全托管的平台服务的方法。

后端平台服务

虽然大多数平台服务都是由外部客户端访问，但有时某个平台服务仅由在线基础架构的其他部分访问也合乎情理，例如一个不在互联网上公开的内部竞技玩家排名服务。虽然此类后端平台服务通常缺少外部网络路由和 IP 地址，但它们遵循与前端平台服务相同的设计实践。

Google Cloud 游戏平台服务资源

如需详细了解如何在 Google Cloud 上构建平台服务，可参阅以下资源。

专用游戏服务器

专用游戏服务器提供游戏逻辑。为了最大限度地减少用户感知的延迟时间，客户端游戏应用通常直接与专用游戏服务器通信。这使它们成为前端服务架构的一部分。

该行业没有标准术语，因此就本文而言：

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

专用游戏服务器的类型

对于当今的后端游戏服务器，专用这个术语可能会引起误解。 在其原始上下文中，专用是指游戏服务器与专用硬件的比例为 1:1。如今，大多数游戏发布商在一台机器上托管同时运行的多个游戏服务器进程。尽管这些进程现在很少有为之专用的整台机器，但游戏行业仍然经常使用专用游戏服务器这个术语。

专用游戏服务器与其运行的游戏类型一样是多种多样的。以下部分将讨论一些高级游戏服务器类别。

实时模拟

直到近期，几乎所有商用产品的专用游戏服务器都是实时模拟游戏的前端的一部分。从过往的记录来看，实时模拟游戏服务器是垂直扩缩的最大推动力。 但现在，要求最高的游戏已经转向手动水平扩缩策略，例如每台机器运行多个服务器进程，或者在地理上将世界分片。 具有自定义流控制、可靠性和拥塞避免的 UDP 通信已成为主流网络范例。

大多数实时模拟游戏服务器都是以无限循环的方式实现的，其目标是在给定的时间预算内完成循环。典型的时间预算为 16 或 33 毫秒，分别生成每秒 60 或 30 次的状态更新率。更新率也称为帧率或节拍率。虽然服务器正在以高频率更新其模拟，但服务器在多次更新之后才将状态更新传递给客户端的做法很常见。这使网络带宽需求保持在合理的范围。可以使用诸如延迟补偿、内插和外推之类的策略减轻更新频率较低的影响。

上述因素意味着在实时模拟游戏服务器上运行那些对延迟时间敏感、计算密集型和带宽密集型的工作负载时，需要仔细考虑游戏服务器设计及其运行的计算平台。 Google Cloud 创立了 Agones 开源项目，以帮助简化在 Google Kubernetes Engine (GKE) 等 Kubernetes 集群上运行专用游戏服务器的过程。

基于会话或对局的游戏

今天，将服务器设计用于运行离散会话的游戏极为流行。典型的例子是第一人称射击游戏 (FPS) 的多人游戏会话，例如 Call of Duty™、Fortnite™、Titanfall™ 或多人在线战斗竞技场 (MOBA) 游戏，例如 Dota 2™ 或 League of Legends™。这些游戏的服务器需要应对快速变化的游戏内容和详尽的游戏状态计算，通常需要专门用于人工智能或物理模拟的线程。

大型持久性多人游戏世界

将近二十年前，Ultima Online™ 为大型多人在线 (MMO) 游戏的爆炸性发展铺平了道路。今天最流行的大型多人在线游戏，如 World of Warcraft™ 和 Final Fantaxy XIV™，都具有复杂的服务器设计和不断发展的功能集的特点。

大型多人在线游戏服务器通常面临复杂的问题，例如在服务器实例之间传递游戏实体，分片或定相游戏世界，以及物理地共置实例以模拟相邻的游戏世界区域。为了满足计算包含数百或数千个玩家的持久游戏世界的状态更新的计算和内存要求，诸如 Eve Online™ 所采用的时间膨胀之类的解决方案应运而生。

基于请求/响应的服务器

从技术上讲，所有专用游戏服务器都基于一系列请求和响应。然而，实时通信并非其关键需求的移动游戏服务器采用了类似网络托管中使用的 HTTP 请求和响应语义。

基于请求/响应的游戏服务器面临的挑战与网络服务相同，包括：

  • 尽可能地缩短游戏服务器的响应时间。
  • 在全球范围内分布游戏服务器以减少延迟时间并增加冗余。
  • 验证游戏客户端在服务器上的操作，以防止攻击程序或欺骗。
  • 安全强化游戏服务器以抵御拒绝服务和其他攻击。
  • 在客户端侧实现通信重试的指数延迟。
  • 创建粘性会话或外化流程状态。

基于请求/响应的游戏服务器的优势在于紧凑的通信语义，以及在发生应用或网络故障后可轻松重试，很适合回合制和移动游戏。 我们建议此类型的服务器使用 App Engine 或 Cloud Run 等平台上的无服务器 API。

外化游戏世界状态

玩家对零游戏停机时间的呼声日益高涨。这意味着您需要保护他们的体验免受单个服务器实例问题的影响。为了做到这一点，一款游戏应该在单个游戏服务器进程之外保持玩家状态。这种方法有很多优点，例如针对崩溃的服务器进程的弹性以及有效负载均衡的能力。

遗憾的是，仅仅使用在网络服务中流行的外化状态模式可能会导致很多问题，原因包括：

  • 当您有许多每秒更新数十次的独特实体时，将更新写入外部状态的速度可能是一个挑战。即使您使用内存缓存的键值存储（如 Memcached 或 Redis）也依旧如此。
  • 针对外部状态缓存的查询的尾端延迟时间也是一个大问题。如果有 1% 甚至是 0.1% 的查询的延迟时间比更新截止时间大一个数量级，就很难满足状态更新截止时间的要求。
  • 确定哪些进程对外部状态缓存中的对象具有只读与读写权限会为服务器模型带来复杂性。

然而，解决这些问题可以带来一些额外的益处。 配备适当的访问管理，成功的外化状态可用于许多进程，可以大幅度地简化并行计算部分游戏状态更新的能力。 它同样有利于在实例之间迁移实体。

Google Cloud 专用游戏服务器资源

以下文章介绍了如何在 Google Cloud 上运行专用游戏服务器。

后端

后端服务仅向其他前端和后端服务提供接口。 外部客户端无法直接与后端服务通信。后端服务通常为您提供存储和访问数据的方式，例如数据库中的游戏状态数据，或数据仓库中的日志记录和分析事件。

游戏数据库

可能导致玩家退出您的游戏并且不再返回的情况，包括服务器无法正常运行和玩家进度丢失。遗憾的是，如果您的数据库层设计不佳，两者都可能发生。

保存游戏世界的状态和玩家进度数据的数据库，可以说是游戏基础架构中最关键的部分。

您对数据库能力的评估，应该是不仅能够处理预期的工作负载，而且能应对在游戏大获成功的情况下需要的工作负载。按照预期的玩家数量进行设计和测试的后端，如果突然收到超过一个数量级的更多负载，就不太可能为任何玩家提供可靠的服务。如果没有规划游戏意外成功所带来的负载，就可能会导致游戏失败，因为当玩家因数据库问题而无法继续参与时，他们就可能会抛弃您的游戏。

游戏特别容易受到这个问题的影响。虽然大多数拥有成功产品的企业都可以期望一种逐步的、有机的增长。但对于游戏业，更常见的模式是游戏刚推出时玩家有很大的兴趣，然后就迅速下降到一个低得多的使用水平。如果您的游戏大热，负担过重的数据库可能会在保存用户进度之前就出现大规模延迟，甚至完全无法保存进度。被迫决定放弃支持某些游戏功能的实时更新，是任何游戏开发者都不希望出现的情况，因此您应该仔细规划数据库资源。

在设计游戏数据库时，请牢记以下几点：

  • 做出明智的决定。 不要因为容易测试而在开发期间使用某个数据库，然后在没有评估所有的选项的情况下，使其成为您的生产数据库。重要的是，要了解在您预期的玩家数量基础上，来自您的游戏的数据库访问的类型和频率，以及比预期增大 10 倍的情况。 然后，您才可以就哪种后端可以最好地处理这些局面做出明智的选择。 切勿让自己陷入当数据库危机已经来临，才尝试了解如何应对的境地。
  • 切忌假设一个解决方案是正确的选择。 请记住，您可以同时运行多种类型的数据库。许多成功的游戏用关系型数据库存储账号信息并处理游戏中的购买操作，同时将游戏状态信息保存在单独的 NoSQL 数据库中。原因在于 NoSQL 数据库可以更好地处理大容量、低延迟的工作负载，而关系型数据库可以提供有保证的事务处理。
  • 备份数据。定期备份和按地理分布进行备份都是从数据库故障中恢复的重要手段。

关系型数据库

许多游戏开发团队在项目起步时会使用一个关系型数据库。当数据和流量增长到数据库性能无法再承受的程度时，他们通常会优先选择扩缩数据库。一旦扩缩不再可行，许多开发者就会实现自定义数据库服务层。 在此层中，您可以优先处理查询和缓存结果，因为这两者都会限制对数据库的访问。 通过添加扩缩和数据库服务层，您可以生成能够处理大量玩家操作的游戏后端，但这些方法可能会遇到一些常见问题：

  • 扩缩 — 传统关系型数据库专注于纵向扩容（纵向扩缩）的方法。但是，在规划云原生游戏后端时，强烈建议您使用横向扩缩（横向扩缩）方法，因为单个虚拟机中可以存在的核心数量总是有限的，但向您的云项目添加更多虚拟机却很容易。关系型数据库具有横向扩缩的模式，例如分片、集群和分层副本，但是如果没有停机时间，您很难将它们添加到正在运行的数据库中。如果您的流量或数据有任何超过单个数据库性能极限的可能性，您就应该从使用一个小型集群开始。这可避免在危机来临时才去学习如何扩缩数据库。在集群运行时向其添加节点并非简单的任务，但终归是可行的。
  • 架构更改 - 很少有成功的游戏从开始就使用一种数据库架构并在整个游戏生命周期内持续使用。玩家需要新的功能和内容，而添加这些功能和内容就需要将新类型的数据保存到数据库中。在开发过程的早期阶段，您就应该决定如何更新架构。游戏发布之后，尝试在没有固定流程的情况下更新架构可能会导致意外停机，甚至丢失玩家数据。
  • 管理 -扩缩正在运行的关系型数据库并更新其架构都是复杂的操作。虽然 Cloud Platform 提供了自动托管的关系型数据库等常用服务，但目前在游戏后端，自动托管数据库的采用率很低。这是因为游戏后端有写入密集型的工作负载。

Google 提供的 Spanner 是一种代管式关系型数据库，可帮助您缓解这些问题。Spanner 是一种专为云端打造、具备强一致性且可扩缩的全球分布式企业级数据库服务。它融合了关系型数据库结构与非关系型数据库横向扩缩能力的优势。许多游戏公司都发现，它非常适合代替生产规模系统中的游戏状态和身份验证数据库。您可以使用 Google Cloud 控制台添加节点来进行扩容，从而获得额外的性能或存储空间。Spanner 可以透明地处理全局复制，同时保持高度一致性，而无需管理区域副本。如需了解详情，请参阅将 Spanner 用作游戏数据库的最佳做法。

NoSQL 数据库

非关系型数据库可以提供大规模运行的解决方案，尤其适合处理写入密集型的工作负载。但是，它们要求您了解 NoSQL 数据模型、访问模式和事务保证。

当前有许多类型的 NoSQL 数据库，那些非常适合存储游戏世界状态的数据库具有以下特征：

  • 扩缩 - 它们的设计考虑了水平扩缩，并且通常默认使用这种模式。调整集群大小通常是一种无需停机即可完成的操作，但有时在完全集成其他节点之前会有一些性能损失。

  • 架构更改 - 架构是动态的，并由应用层强制执行。这是一个巨大的优势，意味着为新游戏功能添加新字段的影响变得微不足道。

  • 管理 — 大多数云提供商提供至少一个托管 NoSQL 数据存储引擎，但 Google Cloud 提供了多个选项。

Google Cloud 游戏数据库资源

分析

分析已成为现代游戏的重要组成部分。在线服务和游戏客户端都可以将分析和遥测事件发送到公共收集点，并在那里存储到数据库中。 然后，从游戏程序员和设计师到商业情报分析师和客户服务代表，每个人都可以查询这些事件。 随着正在收集的数据分析的复杂性增加，这些事件需要新的格式以提供更方便快捷的查询。

过去十年中，一个基于 Google 发布的成果的开源框架 Apache™ Hadoop® 迅速普及。Hadoop 生态系统的扩张增加了复杂批量提取、转换和加载 (ETL) 操作的使用，以便将分析事件格式化并插入数据仓库中。MapReduce 的使用又加快了可执行结果的交付速度，而这一加速又有助于实现新的、更加计算密集型的分析。

与此同时，云端可用的技术也在不断发展。 其中许多作为托管服务提供，可以快速学习并且不需要专门的操作人员。 Google 最新的流式 ETL 范例为批处理和流处理提供了统一的方法，既作为托管云服务提供，也通过开源项目 Apache Beam 提供。 云端数据存储价格的持续下降，使得在大规模的托管云数据库中保存大量日志和分析事件成为可能。这些数据库优化了数据的写入和读取方式， 其最新的查询引擎能够在几秒钟内聚合 TB 级别的数据。 有关这方面的示例，请参阅在 5 秒钟内分析 500 亿次维基百科网页浏览量。

我们建议您设置分析的格式供将来使用。在决定游戏将哪些事件和指标写入分析后端时，请考虑哪种格式最便于您进行数据挖掘以获取洞见。虽然您可以使用 ETL 将应用写入的数据复制到适合分析查询的格式，但可能需要一些时间和成本。在分析输出格式的设计中进行投入可显著节省费用，而且可能实现实时分析洞见。

对现有格式使用批处理

如果想要分析的指标数据采用不受您控制的输出格式（例如来自第三方集成或服务的数据），我们建议您先将指标数据保存到 Cloud Storage。如果数据格式受到支持，则您可以使用 BigQuery 联合查询直接从 BigQuery 接口查询它。如果数据格式不受支持，您可以使用 ETL 通过 Dataflow 或其他工具从 Cloud Storage 复制数据，然后将生成的格式化数据与其他来源的数据一起存储在 BigQuery 中。我们建议您设置定期批量作业来节省费用，而不是进行流式传输，除非您有实时需要数据的紧急需求。

使用经过验证的模型预测流失率和支出

您可能已在为您的移动游戏使用 Firebase 来获取其众多其他功能之一，例如远程配置、应用内消息或 Firestore 客户端库。Firebase 还提供内置的流失和支出预测机器学习 (ML) 模型。您可以集成 Remote Config 个性化，将机器学习应用于您的分析数据，从而根据用户的预测行为创建动态用户细分。这些数据可用于触发其他 Firebase 功能，也可导出到 BigQuery 来增加灵活性。 Firebase 还提供 Unity 和 C++ 客户端，并且其用途不限于移动游戏。

用于 AutoML Tables 自定义模型训练的标准化数据

要生成有效的机器学习模型，通常需要广泛的机器学习专业知识来选择相关特征和调整超参数。不过，按照数据准备指南操作可提高最新自动化工具为您执行这些任务的能力，并代表您生成有用的模型。模型生成后，可以托管在 Google Cloud 上来进行在线预测或批量预测，例如预测玩家是否会在游戏中购买、是否会退出游戏。

虽然分析事件和玩家数据对于传统分析查询和商业智能指标很有用，您还需要不同的格式来训练机器学习模型。机器学习在游戏中的一个常见用例是创建自定义模型，来预测玩家在游戏中首次付费的时间。AutoML Tables 有助于简化训练过程。如需详细了解 AutoML Tables，请参阅准备训练数据和创建训练数据的最佳做法。

多家游戏工作室和发布商以每日汇总格式为基础进行训练，并已取得出色的成效。每日汇总是一种标准化的行格式，每个重要分析事件都有一个字段。行格式包含玩家截至目前为止所触发事件的累计次数。此行提供用户到目前为止触发的所有潜在重要事件的每日快照，还提供一个 true 或 false has made a purchase 标志。

在以这种方式格式化的数据进行训练时，AutoML Tables 快速入门文档中所述的过程可生成高质量的模型。随后，您可以为该模型提供一个每日汇总行，并预测玩家进行购买的可能性。您还可以使用类似的方法设置数据的格式以及不同的标志，以训练模型做出不同的预测，包括玩家流失或其他玩家行为。对构建标准化数据格式进行前期投资可帮助您快速尝试各种模型，以预测所需的任何玩家操作。这种建模可能会帮助您通过游戏获利，或优先展示可带来理想玩家结果的功能。

Google Cloud 游戏分析解决方案

后续步骤

在线游戏解决方案遵循一种常见模式，即客户端与服务和游戏服务器的前端进行通信，后者与分析和状态存储的后端进行通信。您可以在本地、云端或两者的混合环境中运行前述的所有组件。如需更深入地了解这些模式，请参阅游戏解决方案。