云游戏基础架构概览

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

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

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

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

高级别组件

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

图片

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

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

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

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

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

前端

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

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

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

游戏平台服务

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

平台服务示例:

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

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

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

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

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

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

后端平台服务

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

Google Cloud Platform 平台服务解决方案

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

专用游戏服务器

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

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

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

专用游戏服务器的类型

专用这个术语可能会误导当今对后端游戏服务器的理解。在其原始上下文中,专用是指游戏服务器与专用硬件的比例为 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 上运行专用游戏服务器。

后端

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

游戏数据库

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

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

您应评估数据库能够处理预期工作负载以及当游戏大获成功而吸引更多玩家所催生的工作负载的能力。如果后端按照预期玩家数量进行设计和测试,则若它突然需要接收一定数量级的负载,则不太可能可靠地提供服务。如果没有规划游戏意外成功所带来的负载,就可能会导致游戏失败,因为当玩家因数据库停机而无法继续游玩时,他们可能会放弃游戏。

游戏特别容易受到这个问题的影响。虽然大多数拥有成功产品的企业都会希望玩家实现逐步的、有机的增长。但对于游戏来说,更常见的模式是游戏初推出时玩家兴趣大增,然后迅速下降。如果您的游戏取得了成功,数据库可能会因海量的数据操作,而导致在保存用户进度之前就出现大规模延迟,甚至无法完全保存进度。在这种情况下,您不得不决定放弃支持某些游戏功能的实时更新,这是任何游戏开发者都不希望出现的情况,因此请仔细规划您的数据库资源。

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

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

关系型数据库

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

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

NoSQL 数据库

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

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

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

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

  • 管理 - 大多数云提供商提供至少一个托管 NoSQL 数据存储引擎,但 Cloud Platform 提供多个。

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

分析

分析已成为现代游戏的重要组成部分。在线服务和游戏客户端都可以将分析和遥测事件发送到公共收集点,在这里,事件会被存储在数据库中。然后,从游戏程序员和设计师到商业智能分析师和客户服务代表,每个人都可以查询这些事件。随着正在收集的分析数据的复杂性增加,这些事件需要采用可支持便捷查询的格式。

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

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

Google Cloud Platform 游戏分析解决方案

后续事项

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

  • 根据您自己的情况试用其他 Google Cloud Platform 功能。查阅我们的教程
此页内容是否有用?请给出您的反馈和评价:

发送以下问题的反馈:

此网页
Solutions