本文档介绍在 Google Cloud 上运行 API 驱动的移动游戏后端的最佳做法。本文档提供参考，游戏开发者可以此为起点来设计移动游戏的在线架构。本文档中的最佳做法适用于任何类型的移动游戏。不过，本文档重点介绍这样的游戏，它们将玩家进度和账号信息存储在数据库中，并通过游戏开发者编写的自定义接口 API 访问这些数据。
本文档面向开发移动视频游戏（例如 Niantic 的《Pokemon Go》、任天堂的《超级马里奥跑酷》或 King 的《糖果传奇》）的团队。本文档中的最佳做法不适用于博弈游戏（纸牌游戏和赌场游戏）或梦幻运动游戏应用（例如梦幻足球），这些游戏大部分通常像典型的 Web 应用或社交应用一样扩缩。
游戏具有以流行为主导的特性，这会在高峰时段促使需求激增。因为您的应用由应用商店提供，或者由流媒体社区支持，所以务必要考虑因成功而导致灾难的场景，确保在游戏变得流行时有明确的扩缩路径。在开发过程中做出明智的决策有助于最大限度地降低风险。
估算您的预期用户负载
在设计移动游戏的在线后端时，请务必尽量估算用户负载。如果您将架构设计为在预期负载下使用其大部分资源，那么在该架构获得更大玩家社区的关注，但无法扩缩来满足这一需求时，则可能会失败。如果无法扩缩，可能会导致失去收益机会并损害工作室的声誉。设计一个在预期负载下运行良好，但在您意外取得成功时有明确的路径来扩展到更大的规模，这可能是一个挑战。
用户负载估算始终基于众多数据，但需要包括两个基本类别：
- 玩家人数和玩游戏的频率：这通常是基于市场上玩类似游戏的玩家人数以及您通过营销支出获取用户的预算而得出的有根据的猜测。
- 每个玩家产生的 API 负载：可以通过全面的负载测试来衡量。
做出初步估算
进行初步估算时，请考虑您可获得的所有因素，例如：
- 市场上过往游戏或类似游戏取得的成功
- 所含知识产权 (IP) 的热门程度
- 推向市场的时间
- 您的应用组合的其余部分中预注册或交叉推介的数量
- 营销预算
在估算用户人数后，通常的做法是创建一个人数为预估数四倍 (4X) 的理想场景。不过，我们建议您考虑游戏走红或以其他方式意外成功而导致灾难的场景。一些工作室会将其用户估算人数增加 10 倍 (10X)，但过去在 Google Cloud 上发布的游戏将其估算人数增加了 20 倍 (20X)，在极端情况下甚至增加 40 倍 (40X)。即使达到这些数字的可能性很小，计算这些数字并验证您的架构能否扩缩到这些级别也很有价值。
运行负载测试
仅知道预期用户人数不足以了解您的移动游戏的扩缩需求。有必要在尽可能接近实际情况的条件下运行负载测试。应由非公开的 Beta 版测试人员使用接近最终版本的游戏运行负载测试。通过负载测试，您可以分析状态存储数据库和 API 层的性能，从而确保有足够的余量。真实用户经常会创建开发者无法预见的使用模式。因此，获取一些实时玩家使用情况分析作为更大规模负载测试的模型非常重要。我们建议您使用负载测试框架，根据您在上一部分计算的初步估算值确定的规模，从 Beta 版测试中复制用户模式。
运行大规模负载测试时，请与您的 Google Cloud 销售团队联系，并在您计划进行压力测试的时间段内提交适当的 Cloud Customer Care 工单。填写 Customer Care 工单使团队能够在必要时帮助您主动申请增加配额。此外，它还有助于确保 Customer Care 工程师能够解答您的问题，以防 Google Cloud 产品未按您预期的方式运行。
针对参考架构进行验证
下图提供了本文档中最佳做法的参考架构：
在上图中，您的游戏客户端通过负载均衡器连接到移动游戏后端。后端与玩家记录数据库直接连接，前面有一个可选的高速缓存层，用于存储和检索玩家进度、使用权和其他数据。后端将操作指标和日志发送到 Google Cloud Observability。指标和日志对于监控后端性能至关重要，它们也可供您的数据仓库访问。Analytics（分析）专家可以使用 BigQuery 直接访问数据仓库，并且可使用 AutoML 生成用于预测支出和流失情况的模型。这些预测随后可提供给您的游戏后端。本文档后面会详细介绍以下组件：
- 用于面向客户端的 API 的计算
- 用于状态存储的数据库
- Google Cloud Observability 可观测性和监控
- 分析
某些移动游戏使用专用游戏服务器或 TURN/STUN 服务器提供实时多人游戏。本文档中的最佳实践未明确包含此类服务器，但这些做法与游戏服务器兼容。
计算选项
Google Cloud 为您的移动游戏后端提供多种计算选项，从全代管式可扩缩选项（如 App Engine）到 Google Kubernetes Engine (GKE) 等完全可自定义的环境应有尽有。请务必仔细了解您的需求并做出相应的决定。以下部分中的所有选项均提供与 Cloud Load Balancing 的完全集成，以便您的 HTTP(S) 流量能够利用无缝扩缩。选项还包括 Google Cloud Armor，例如企业级 DDoS 防护。
使用 App Engine 提供经过验证的可扩缩无服务器服务
App Engine 是 Google Cloud 的全托管式无服务器平台，可让您专注于编写代码，而无需管理底层基础设施。您可以将 App Engine 配置为根据游戏的需求进行扩缩。此外，通过单个命令从源代码直接构建和部署，也可以缩短开发者的迭代时间。对于规模较小或仅具有扩缩基础架构运营经验的团队，App Engine 是理想的选择。它通过多次移动游戏发布进行了大规模验证，这包括从 Nintendo、Madfingerprint Games、Pocket Gems 和Backflip Studio 进行发布。
在评估 App Engine 是否适合您的游戏时，请务必了解可根据玩家的查询速率启动或停止该实例。因此，服务设计不得计划保存用户请求之间的状态。如果您需要维护请求之间的状态，那么您应在状态存储数据库中存储和检索该状态（详见下一部分），或者使用单独的缓存，例如 Memorystore（Memcached 或 Redis）。
App Engine 应用可能需要更多时间或资源来使它们在其他运行时环境中高效运行。如果您需要可部署在多云或混合云环境中的单个运行时目标，我们建议改用 Cloud Run 或 Google Kubernetes Engine。
将 Cloud Run 用于新的无服务器应用
借助 Cloud Run，您可以在游戏后端的容器中开发新应用，而无需管理 Kubernetes 集群。Cloud Run 可以自动扩缩您的 API 容器来满足玩家群的需求。它提供 App Engine 的众多优势，包括全代管式运行时环境；在这种环境中，基础架构被抽象化，并且根据您选择的配置自动处理扩缩。由于它基于开放式标准 Knative 构建而成，因此使用 Cloud Run 时可以更轻松地编写可移植服务。Cloud Run 应用在 Kubernetes 上的容器中运行，这样在您未来需要更多控制权时，就有清晰的路径来移动到自行管理的 Kubernetes。
使用 GKE 完全控制工作负载
Google Kubernetes Engine 是一个选项，适合需要更多控制或与经验丰富的运营团队合作的开发者。如果您的团队已在将 Kubernetes 用于其应用堆栈，则 GKE 可让他们使用相同的 Kubernetes 接口和命令行界面 (CLI) 与现有服务一起运行游戏后端。如果您的团队想要在多个云端或本地运行应用，GKE 为云端构建的应用（云原生应用）提供一个单目标平台。多款游戏已成功发布来在 GKE 上大规模扩缩，包括 Pokémon GO。
状态存储数据库
为移动游戏选择数据库时，您需要考虑如何扩缩和管理不断扩大的玩家群和不断增加的游戏复杂性。Spanner 和 Firestore 具有丰富的功能、提供托管式体验，并且拥有大量经过验证的移动游戏成功案例。Google Cloud 还提供了 Cloud SQL，这是一个代管式 MySQL 数据库。不过，Cloud SQL 可能难以扩缩，因为手动数据库分片或聚类可能会在状态加载层中引入极大的难度和复杂性，导致不必要的停机和客户影响。
使用 Spanner 处理全球游戏，实现用户之间的交易
Spanner 是一种全代管式关系型数据库，规模不受限制，具有强一致性，可用性高达 99.999%。它具有 SQL 语义，并为熟悉关系型数据库的开发者提供熟悉的界面。Spanner 可在全球部署，但按区域访问，因此您可以拥有单个数据库实例的简洁性，又获得分布式副本的性能。
Spanner 提供无限扩缩，因此它非常适合存储玩家个人资料和背包信息。此外，它还提供交易保障，让您能够为游戏用户提供可靠的玩家间交易或拍卖行功能。Spanner 提供了多种迁移、开发、可观测性和内省工具，让开发者能够快速上手并轻松管理数据库。Spanner 可逐步扩容为每秒数百万次查询 (QPS)。对于您的重大发布（例如发布第 1 天每秒查询次数预计超过 1000 次），我们建议您遵循预热和基准测试的最佳做法。
Spanner 可以扩容至数十亿用户用例，并可以灵活地管理规模来满足您所需的性能。Spanner 在移动游戏领域具有广泛的用途；如需了解如何在游戏中使用该平台，请参阅将 Spanner 用作游戏数据库的最佳实践。
使用 Firestore 提高开发速度和降低运营开销
Firestore 是一种可扩缩的全代管式 NoSQL 文档数据库。它提供简化的开发者体验，并且在存储新信息时不需要更新架构。它还提供强一致性、事务保证和高达 99.999% 的可用性。您也可以从使用 Firebase 客户端库的移动游戏直接访问 Firestore。
典型的方法是为每个玩家使用一个 Firestore 文档，并将其所有进度存储在一个与您的游戏设计完美配合的层次结构中的文档中。在设计游戏来使用 Firestore 时，请考虑 Firebase 限制和 Firestore 最佳做法。基于这些最佳做法，需要频繁更新同一文档的工作负载可能不太合适。规模极高的游戏（如 Pokémon GO）已使用 Firestore（以前称为 Datastore）成功发布。这些游戏能够进行扩缩，来满足超过预估玩家流量 50 倍的巨大需求。
Firestore 可以自动为您处理扩缩。但是，为了确保在使用量突然最佳（例如在主要营销支出后）时顺畅扩容，您应该就容量规划与 Google Cloud 客户经理对话。
将缓存重新评估为性能优化
为了优化性能，一种常见的移动游戏策略是将内存中缓存置于数据库的前面。内存中缓存保存经常读取的数据，或者会批处理低优先级更新。此策略会增加架构的设计复杂性，通常无需用于可伸缩的代管式数据库（如 Spanner 或 Firestore），这些数据库可处理读写负载。如果您对数据库访问模式进行负载测试，而且仍然需要缓存，请考虑使用适用于 Redis 或 Memcached 的 Memorystore 等托管方案来减少管理开销。
选择数据存放区域以满足合规性要求
许多游戏在全球范围内必须遵守 GDPR 等数据存放区域法律。如需帮助以支持您的 GDPR 需求，请参阅 Google Cloud 和 GDPR 白皮书，并选择正确的 Spanner 或 Firestore 区域配置。
可观测性
我们建议您尽早实现可观测性。若要快速发现和解决问题、加快开发周期，并减少出现问题时对客户的影响，实现应用和后端基础架构的可观测性非常重要。在开发初期，可采用一种非常适合 Google Cloud Observability 的格式来节省时间和资金。
使用开源标准将应用指标导入 Cloud Monitoring
您的所有 Google Cloud 资源都已将插桩集成到 Cloud Monitoring 中，并显示在 Google Cloud 控制台中。因此，我们建议您同时对移动游戏后端进行插桩，以与 Cloud Monitoring 集成。与 Cloud Monitoring 集成可让您为基础架构和应用使用统一界面（有时称为单一管理平台）。使用统一界面可并排查看界面和应用的关键指标，并可帮助您快速发现和隔离问题。
在应用中实现自定义指标和分布式跟踪时，我们建议您使用 OpenTelemetry，这是一个名为 OpenCensus 的免费开源项目。OpenTelemetry 提供与供应商无关的支持来帮助跨多种语言收集指标和跟踪记录，并且可将其导出到众多可观测性产品，包括 Cloud Monitoring 和 Cloud Trace。如需了解详情，请参阅使用 OpenCensus 的自定义指标。
使用结构化日志记录
当选择日志记录格式时，我们建议您使用结构化日志记录，并将日志的任何有趣功能排序到 JSON 字段中。这种实现可让您快速对 Cloud Logging 中的日志进行排序、搜索和过滤。许多编程语言都有热门的结构化日志记录库或模块，可以导出到 Cloud Logging。Google Cloud 还提供许多惯用的日志记录客户端库。
创建 BigQuery 日志接收器
如果您需要稍后分析日志，或者根据运营地区的数据保留法律保留日志，请提前为日志设置 BigQuery 接收器。只有在接收器创建后生成的新日志会写入 BigQuery。如果您要将大量日志写入 BigQuery，我们建议您选择使用分区表的选项。
Analytics（分析）
我们建议您设置分析的格式供将来使用。在决定游戏将哪些事件和指标写入分析后端时，请考虑哪种格式最便于您进行数据挖掘来获取洞见。虽然您可以使用提取、转换和加载 (ETL) 将应用写入的数据复制到适合分析查询的格式，但可能需要一些时间和成本。在分析输出格式的设计中进行投入可显著节省费用，而且可能实现实时分析洞见。我们建议您查看来自 Square Enix、King 和 LINE GAMES 的演示文稿和客户评价。这些演示文稿可让您实际了解如何使用 Google Cloud 的分析产品来改进移动游戏。
对现有格式使用批处理
如果想要分析的指标数据采用不受您控制的输出格式（例如来自第三方集成或服务的数据），我们建议您先将指标数据保存到 Cloud Storage。如果数据格式受到支持，则您可以使用 BigQuery 联合查询直接从 BigQuery 接口查询它。如果数据格式不受支持，您可以使用 ETL 通过 Dataflow 或其他工具从 Cloud Storage 复制数据，然后将生成的格式化数据与其他来源的数据一起存储在 BigQuery 中。我们建议您设置定期批量作业来节省费用，而不是进行流式传输，除非您有实时需要数据的紧急需求。
使用经过验证的模型预测流失率和支出
您可能已在为您的移动游戏使用 Firebase 来获取其众多其他功能之一，例如远程配置、应用内消息或 Firestore 客户端库。Firebase 还提供内置的流失和支出预测机器学习 (ML) 模型。您可以集成 Remote Config 个性化，将机器学习应用于您的分析数据，从而根据用户的预测行为创建动态用户细分。这些数据可用于触发其他 Firebase 功能，也可导出到 BigQuery 来增加灵活性。
用于 AutoML Tables 自定义模型训练的标准化数据
要生成有效的机器学习模型，通常需要广泛的机器学习专业知识来选择相关特征和调整超参数。不过，按照数据准备指南操作可提高最新自动化工具为您处理这些任务的能力，并代表您生成有用的模型。模型生成后，可以托管在 Google Cloud 上来进行在线预测或批量预测，例如预测玩家是否会在游戏中购买，或者是否会退出游戏。
虽然分析事件和玩家数据对于传统分析查询和商业智能指标很有用，但需要其他格式来训练机器学习模型。机器学习在移动游戏中的一个常见用例是创建自定义模型，来预测玩家在游戏中首次付费的时间。AutoML Tables 可以极大地简化训练过程。如需了解一般概览，请参阅 AutoML Tables 文档准备训练数据和有关创建训练数据的最佳做法。
多家游戏工作室和发布商以每日汇总格式为基础进行训练，取得了出色的成效。每日汇总是一种标准化的行格式，每个重要分析事件都有一个字段，其中包含玩家截至当天触发事件的累计计数。此行提供用户到目前为止触发的所有潜在重要事件的每日快照，还提供一个 true 或 false has made
a purchase 标志。
在以这种方式格式化的数据进行训练时，AutoML Tables 快速入门文档中所述的过程可生成高质量的模型。然后，您可以为模型提供每日汇总行，并预测玩家进行购买的可能性。类似的数据格式设置方法也可与其他标志一起使用，来训练模型作出不同的预测，包括流失或其他玩家行为。对构建标准化数据格式进行前期投资可帮助您快速尝试各种模型，以预测您能想象到的任何玩家操作。这种建模可能会帮助您通过游戏获利，或优先展示可带来理想玩家结果的功能。
对 Spanner 游戏数据库执行分析
此外，Spanner 还可让管理员和分析专家访问数据，而不会影响游戏的数据库流量。BigQuery Spanner 联合使 BigQuery 能够实时查询位于 Spanner 中的数据，而无需复制或移动数据。此外，Spanner 还支持使用 Dataflow 模板导出数据，您可以在 Looker 或 Google Cloud 控制台中分析这些数据，也可以将数据存储在您选择的其他分析平台中。
分发、通知和其他主题
移动游戏开发是一个庞大的多元化领域。一篇指南中没法面面俱到，以下部分介绍了其他重要注意事项。
使用 Cloud CDN 分发您的游戏资源
Cloud CDN 可以将游戏资源分发到移动客户端，并具有内置的 Cloud Monitoring 和 Cloud Logging 集成。如果您现已建立了供应商关系，则大多数主要 CDN 都可以使用 Cloud Storage 作为源服务器。
使用 reCAPTCHA 减少滥用行为
虽然从技术层面来讲，reCAPTCHA 并非后端基础架构的一部分，但它与客户端进行有价值的集成。它使用自适应挑战来减少应用中的滥用行为，对于移动游戏，它经常用于减少自动用户（机器人）的注册数量。如需了解详情，请参阅 reCAPTCHA 文档。
使用 Firebase Cloud Messaging 向客户端推送通知
如果您的移动游戏需要发送推送通知，或者让用户能够互发消息，请考虑使用 Firebase Cloud Messaging (FCM)。FCM 是一项跨平台通讯服务，可让您可靠地免费发送消息。它还可以用于发送数据消息，这可让您完全确定应用代码中会发生什么。您可以编写自己的消息传递后端应用或使用无服务器 Cloud Functions 函数来创建消息，然后使用 Firebase Admin SDK 或 FCM 服务器协议来发送它们。
简化游戏配置分发
在移动游戏中，实现游戏平衡的一种常见方法是在数据中定义大多数游戏参数。然后，当您需要修复丢失率或武器攻击统计信息等参数时，您就可以安全地将更新分发给客户端。Firebase Remote Config 旨在让您无需要求用户下载应用更新就能更改应用的行为和外观。通过它，您可在应用中定义默认值，您可使用 Firebase 控制台或者从 Remote Config 后端 API 以编程方式覆盖用户群的所有细分或特定细分的这些值。
评估机器学习以实现游戏平衡
关于使用机器学习进行游戏平衡的研究已得出许多在 GDC 上提供的成功案例和其他事件。其中许多案例来自数据科学家和机器学习工程师构建的自定义解决方案；如果没有经验丰富的团队，则很难复刻这些解决方案。如果您想评估机器学习来实现游戏平衡，或者作为 AI 对手进行评估，那么通过 AutoML Tables 等工具，您没有广泛的机器学习专业知识也能试用自定义模型。要预测玩家行为（例如玩家的物品选择或后续动作），请使用本文档前面的用于 AutoML Tables 自定义模型训练的标准化数据中所述方法的类似方法。
后续步骤
- 面向游戏行业的 Google Cloud
- 云游戏基础架构概览
- 如需查看更多参考架构、图表和最佳实践，请探索云架构中心。