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

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

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

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

概要组件

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

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

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

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

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

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

前端

前端提供互联网客户直接或通过负载平衡器间接进行交互的界面。

例如，在基于会话的第一人称射击游戏中，前端服务通常包括配对服务。该服务将专用游戏服务器实例的连接信息分发给游戏客户端。游戏客户端通过互联网向配对服务发送请求。当它们从包含连接信息的配对服务接收到响应时，就可以使用用户数据报协议 (UDP) 直接连接到专用游戏服务器实例。

前端服务不必由外部客户端独占使用，前端服务之间彼此通信以及与后端通信都很常见。但是，由于前端服务可以通过互联网访问，因此它们更可能受到攻击。您应该考虑强化前端服务安全，以抵御拒绝服务攻击和格式错误的数据包，帮助解决这些安全性和可靠性问题。相比之下，后端服务通常只能使用您或受信任的第三方合作伙伴编写的代码进行访问，因此可能更难被攻击。

游戏平台服务

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

平台服务示例：

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

游戏平台服务的软件设计策略类似于网络服务提供的功能和 API，两者都以类似的模式发展：

在 21 世纪初，一套典型的平台服务会作为单体式应用服务运行，通常作为单例实现。即使在联合时，也不建议将此模式用于云部署。
随着该行业将各种服务改为可独立扩缩，现在熟知的面向服务的架构模式 (SOA) 在 2000 年代中期开始流行。此外，现在不仅可以通过游戏客户端和服务器访问这些服务，还可以通过网络服务以及最终通过智能手机应用访问这些服务。
在过去的五年中，许多开发者采用了快速扩缩型网络公司所倡导的微服务方法。这是因为平台服务和网络应用的许多基本挑战是相同的，例如在全球范围内实现快速开发周期和运行高度分布式服务。微服务可以帮助解决这些问题，因此对于设计在 Cloud Platform 上运行的应用是一个很好的选择。
此外，现在有许多托管的服务可以提供构建平台服务的方法，也可以提供完全托管的平台服务。

后端平台服务

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

Google Cloud Platform 平台服务解决方案

以下解决方案提供了有关如何在 Cloud Platform 上构建后端服务的更多信息。

基于 Google App Engine 和 Firebase 的移动平台服务
设计 API 以在 App Engine 上的微服务之间进行通信

专用游戏服务器

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

注意：作为前端服务，游戏服务器可能成为很多种类的利用与攻击的目标。检测不良操作者和作弊玩家值得重视，但这个主题不在本文的讨论范围内。

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

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

专用游戏服务器的类型

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

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

实时模拟

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

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

上述因素意味着在实时模拟游戏服务器上运行那些对延迟时间敏感、计算密集型和带宽密集型的工作负载时，需要仔细考虑游戏服务器设计及其运行的计算平台。

基于会话或对局的游戏

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

大型持久性多人游戏世界

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

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

基于请求/响应的服务器

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

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

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

基于请求/响应的游戏服务器的优势在于紧凑的通信语义，以及在发生应用或网络故障后可轻松重试，很适合回合制和移动游戏。

外化游戏世界状态

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

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

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

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

Cloud Platform 专用游戏服务器解决方案

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

使用 App Engine 和 Google Compute Engine 的游戏服务器参考架构
专用游戏服务器迁移指南
在 Compute Engine 上设置 Minecraft 服务器
在 Kubernetes Engine 中运行专用游戏服务器

后端

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

游戏数据库

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

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

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

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

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

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

关系型数据库

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

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

NoSQL 数据库

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

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

扩缩 - 它们的设计考虑了水平扩缩，并且通常默认使用这种模式。调整集群大小通常是一种无需停机即可完成的操作，但有时在完全集成其他节点之前会有一些性能损失。
架构更改 - 架构是动态的，并由应用层强制执行。这是一个巨大的优势，意味着为新游戏功能添加新字段的影响变得微不足道。
管理 - 大多数云提供商提供至少一个托管 NoSQL 数据存储引擎，但 Cloud Platform 提供多个。

Google Cloud Platform 游戏数据库解决方案

使用 Cloud SQL Second Generation 作为移动游戏后端数据库
在 Cloud Engine 上部署 MongoDB
如何使用热备份设置 PostgreSQL 以实现高可用性和复制

分析

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

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

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

Google Cloud Platform 游戏分析解决方案

构建移动游戏分析平台 - 参考架构
将 Firebase Analytics 数据导入 BigQuery

后续事项

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

亲自试用其他 Google Cloud Platform 功能。查阅我们的教程。

创作场景

云游戏基础架构概览