亚马逊云科技：游戏战斗服应用现代化的关键挑战和解决方案

关键字: [出海日城市巡展, GameLift, 游戏战斗服应用现代化, 弹性扩容, 集中管理, 可靠运营, 云移植, 容器托管, 云原生部署]

本文字数: 3300, 阅读完需: 16 分钟

导读

在这场演讲中,演讲者介绍了游戏战斗服务的现代化部署方案。他首先回顾了游戏服务器计算平台的演进历程,从传统的物理服务器部署到云上虚拟机部署,再到容器化部署和无服务器部署。接着,他分别介绍了三种部署方式的优缺点和适用场景:实例托管、容器托管和云原生无服务器部署。最后,他以漫威SNAP游戏为例,详细阐述了无服务器部署的架构和亚马逊云科技服务的应用,如Lambda、API Gateway、GameLift等,并介绍了亚马逊云科技自研的SnapStart技术,可以显著提高无服务器函数的冷启动性能。整个演讲内容丰富、实用,为游戏开发者提供了现代化部署的思路和方案。

演讲精华

以下是小编为您整理的本次演讲的精华，共3000字，阅读时间大约是15分钟。

在这场精彩的分享中,讲师首先介绍了亚马逊云科技(AWS)在全球范围内的覆盖情况。亚马逊云科技目前已在全球部署了33个区域,105个可用区,覆盖范围包括了一些新兴的经济体市场,比如最近备受关注的南美巴西市场和中东阿联酋市场等重点区域。在这些地区,亚马逊云科技都已经建立了庞大的基础设施,可以为用户提供就近接入的服务,让游戏玩家获得优质的网络体验。除了数据中心之外,亚马逊云科技在全球还有400多个边缘节点,确保用户可以就近接入亚马逊云科技的主官网,提升网络访问质量。

据统计,目前已有超过90%的大型游戏开发商在使用亚马逊云科技的基础设施服务。这些知名游戏公司的Logo在分享中一并展示,可见亚马逊云科技在游戏行业的影响力。

接下来,讲师指出了游戏战斗服务在现代化过程中所面临的三大主要挑战。第一个挑战是弹性扩容。游戏访问量存在明显的波峰波谷,在晚上的6点到10点这个时间段,玩家上线频繁,会造成高并发访问量的增长。而在早上或凌晨时段,访问量则会急剧下降。因此,我们希望战斗服务能够做到弹性扩容,在闲时将基础设施负载降至最低,以节省成本,这成为现代化过程中需要解决的第一个挑战。

第二个挑战是集中管理。在游戏服务的搭建过程中,我们需要去管理来自全球各地的游戏玩家会话,并进行玩家与玩家之间的匹配,将他们分配到不同的游戏服务器中。我们希望有一个集中管控的平台,对整个架构进行统一的管理。

第三个挑战是可靠运营,也就是高可用性。由于基础设施无法避免会出现故障,因此我们需要能够及时探测到故障,并及时恢复,尽量降低故障给游戏带来的影响。这也是游戏客户主要关注的问题之一。

为了解决上述挑战,讲师回顾了游戏服务器架构的演进历程。在最开始的九几年或2000年初,很多游戏公司还在采用物理服务器的模式,将所有服务器部署在线下的IDC机房。这种模式下,整个流程会变得非常复杂和冗长。首先,游戏公司需要预估即将上线游戏所需的资源情况,但这种预估往往无法完全匹配游戏上线后的实际资源需求。如果游戏发行效果不佳,就会造成数据中心资源的浪费;反之,如果游戏发行引起大量用户涌入,也会导致资源吃紧,对游戏体验造成影响。因此,对于游戏类场景,很难提前准确预估所需服务器资源。

其次,游戏公司需要在游戏开发或上线之前就进行大量投资,提前几周或几个月购买服务器,运送到当地IDC机房,并进行网络、服务器、交换机等配置,这些都是在取得收益之前就需要付出的固定成本。如果游戏效果不佳,这些前期投资都将打水漂,造成成本浪费。

最后,IDC部署模式的周期非常漫长。需要在国内或游戏当地购买服务器,经过物流运输到当地IDC机房,然后上架开通、网络配置、服务器配置等一系列过程,基本需要几个月的时间才能完成搭建。

为了解决物理服务器模式的这些问题,在2000年之后的将近10年时间里,越来越多的客户开始将线下IDC资源迁移上云。上云能带来更快的配置速度,讲师以网络配置为例,在线下IDC搭建一个网络环境需要配置交换机、防火墙、路由器等,需要专门的网络运维团队操作,耗时几周。但在云上,一位工程师只需几个小时,在控制台上就可以轻松拉起一个VPC,规划子网拓扑结构,搭建一个完全隔离、安全稳定的网络环境,效率得到极大提升。

此外,上云后游戏公司不需要在游戏上线前就将所有资源预置好,可以根据上线后的实际资源需求情况动态调整,将前期的固定支出转变为可变支出,实现资源的弹性扩缩容。如果游戏情况良好,可以分钟级扩容以满足需求;如果效果不佳,也可以方便地关闭多余资源,降低运营成本。

虽然上云解决了大部分问题,但对于更精细化的开发或运维,仍存在一些问题。最常见的就是开发测试环境与生产环境的运行时不一致,导致开发人员和测试人员之间相互指责的情况时有发生,归根结底是因为两者的运行时环境不一致所致。

为了解决这个问题,越来越多的客户开始拥抱容器化技术。容器化可以将整个运行环境打包到一个容器中,部署在容器化平台上,从而确保各个角色的人员使用的是完全一致的运行时环境,避免了扯皮问题。同时,容器化部署还可以提高资源利用率,并且容器更加轻量级,启动速度也更快。因此,越来越多的客户开始尝试将战斗服务部署到容器化环境中。

进一步地,也有越来越多的客户开始采用无服务器的形式。即使在容器化场景下,客户也不得不去维护容器化平台,比如常见的Kubernetes集群。维护一个Kubernetes集群其实说起来也是蛮复杂的,以Kubernetes的权威指南为例,最新版本就已经达到了600页,需要有一定的专业知识和能力的运维人员才能将容器平台维护好。因此,为了减轻运维负担,越来越多的客户开始转向无服务器化的部署模式。

所谓无服务器化,顾名思义就是在应用上架之后,不需要去维护底层的任何一台服务器。无论是计算组件、数据库组件,还是前端组件,都可以在无服务器化模式下部署,客户只需关注各个组件的代码和应用本身,至于它们具体运行在哪些底层服务器上,何时需要扩容或缩容,这些都不再需要客户关注,全部由云平台自动完成。

根据客户拥抱云原生的不同程度,讲师将战斗服务的托管分为三个层次。第一层是云移植,也是最容易的方式。简单来说就是将线下IDC的服务器配置和应用原封不动地以1:1的形式直接迁移到云上。线下有一台服务器,云上就开一台虚拟机,这就是最简单的云移植方式。

第二层是容器化。很多客户开始尝试解决云移植带来的各种问题,将一些战斗服务或平台服务部署在容器平台上,比如Kubernetes或亚马逊云科技自研的ECS平台,以解决游戏运行时环境不一致的问题。

第三层是纯云原生的无服务器环境。客户将更多精力放在游戏开发、创意和迭代上,因此开始拥抱真正的无服务器部署,利用亚马逊云科技的Lambda、DynamoDB等无服务器服务构建应用,实现分钟级的扩缩容,无需维护底层实例。

讲师接着对这三种部署模式进行了更详细的介绍和对比。首先是实例托管模式,即我们常见的基于虚拟机的游戏部署架构。从逻辑上可以将其分为两个主要模块:大厅服务或平台服务,以及游戏服务。

平台服务承载了诸如用户注册、商城系统、聊天系统等核心功能,这些业务属于不太时间敏感的,用户可以在一定程度上忍受延迟,因此可以将平台服务部署在较为中心的位置,无需考虑离用户最近,以降低成本。同时,由于平台服务往往是核心服务,承载了众多功能模块,建议对其进行微服务化拆分,让每个模块只负责自己的部分内容,并可以按功能模块进行横向弹性伸缩。

而战斗服务,尤其是魔兽类游戏,对延迟要求非常高,因此通常建议采用分布式部署,将战斗服务部署在离玩家最近的地方,比如将日本玩家的战斗服部署在东京,欧洲玩家的部署在法兰克福等,以提供就近接入。

在机型选择上,亚马逊云科技自研的ARM架构平台Graviton相比传统的X86架构,如英特尔芯片实例,能提供高达40%的性价比优势。越来越多的客户开始将战斗服迁移到Graviton实例上,以降低成本。不过需要注意的是,如果游戏采用较高级的开发语言如Go、Java或Python,可以无缝迁移到ARM上直接运行;但如果是较底层的语言如C++或C#,可能需要重新编译后再迁移到ARM架构上。

为实现战斗服务的弹性扩缩容,可以利用亚马逊云科技的Auto Scaling组功能,根据预先设置的指标如CPU利用率,自动添加或移除实例资源,保持CPU利用率在合理水平。如果节点出现故障,Auto Scaling也能自动将故障实例移除,并替换为健康实例,以对外提供服务。

在这方面,堡垒之夜是一个典型的最佳实践案例。2019年,尽管堡垒之夜已经取得了巨大成功,注册用户达到1亿,但到了2020年上半年,其玩家数量就暴增到3.5亿,大量增加了基础设施成本。为此,他们将核心的战斗服务和语音聊天服务大规模迁移到Graviton实例上,直接降低了20%的成本开支。随着堡垒之夜的大规模使用,Epic Games也使虚幻引擎对Graviton CPU做了兼容优化,让所有游戏开发者都从中受益。

第二种是容器托管模式。这是基于容器的一种典型后端服务架构,按服务类型可分为三块:网关服务器、非场景服务器和场景服务器。网关服务器负责维护用户连接,接收用户请求并转发给后端组件;非场景服务器包括登录服务、注册服务、聊天服务、交易服务等;场景服务即我们常说的战斗服务,承载角色战斗、移动等游戏内容功能。

从有状态和无状态的角度来看,无状态服务可以利用亚马逊云科技的Spot实例进行部署,以最大程度降低成本。Spot实例是亚马逊云科技将当前的冗余资源以非常便宜的价格提供给用户使用,在极端情况下,折扣能达到原价的一折。

而对于流量的加速,HTTP协议的流量可以利用亚马逊云科技的CDN产品CloudFront进行动静态一体的加速;TCP或UDP流量则可以使用Global Accelerator进行网络加速,提升用户的网络体验。

在容器化平台方面,亚马逊云科技的EKS服务可以与开源Kubernetes版本完全兼容,客户可以无缝将应用迁移到EKS上。EKS会持续维护与社区版本同步,给予客户充分时间进行版本升级和验证。同时,EKS也可以继承亚马逊云科技所有安全相关服务,与亚马逊云科技的身份管理、数据加密等服务深度集成。

EKS的控制平面是完全托管的,客户无需维护。对于每个客户,控制平面都在VPC层面实现了隔离。所有组件包括API Server、Etcd等都实现了跨AZ的高可用,并可以根据集群扩展自动扩容。而在数据平面的Worker节点层面,亚马逊云科技开源的Karpenter组件可以根据负载要求,自动对Pod或节点进行横向扩缩容,实现精细化的资源管理。

Karpenter支持多种计算选项,包括On-Demand实例、Spot实例,甚至可以针对不同应用将工作负载调度到不同的CPU架构,如x86或ARM架构,进一步优化成本。在容器化领域,卡普空公司利用亚马逊云科技的容器化平台节省了将近30%的运营成本,可以说是容器化部署的一个最佳实践。

最后是云原生的无服务器部署模式。讲师以漫威Snap游戏为例,该游戏由曾主导炉石传说的工作室Second Dinner与国内朝夕光年联合开发,是一款手机好的,我继续为您详细叙述云原生无服务器部署模式:

漫威Snap游戏全面采用了云原生的无服务器架构,在整个游戏中不存在任何EC2实例,而是大量利用了亚马逊云科技的无服务器服务,包括Lambda、API Gateway、GameLift等,并在七大区域进行了部署,覆盖欧美及亚太地区。

以漫威Snap这款卡牌对战游戏为例,它的架构可分为接入层、服务层和平台服务层三部分。接入层由亚马逊云科技的网络服务组成,利用Route 53进行DNS解析,Web应用程序防火墙(WAF)保证请求安全,CloudFront对前端网络请求进行加速。

网络协议分为两种:游戏开始前,玩家发起对战请求采用HTTP协议,该请求由Lambda转发到GameLift的FlexMatch平台进行玩家匹配;一旦匹配成功,玩家就会通过WebSocket协议实时接收战斗服务器返回的服务数据。在游戏过程中产生的监控、报警、日志等都由CloudWatch这一无服务器监控服务完成。

在这个架构中,Lambda是亚马逊云科技最具特色的无服务器计算服务。它发布于2014年,是业界首个纯无服务器计算服务。Lambda的主要特点包括:无需运维底层服务器,只需上传代码到平台即可运行;计算资源的扩缩容由亚马逊云科技自动处理;采用响应式服务模式,代码运行由特定事件如对象上传触发;纯按需付费,只在使用时收费,计算时长已精确到毫秒级。

针对无服务器计算常见的冷启动问题,亚马逊云科技推出了Snap Start技术,可以为Java函数提供高达10倍的冷启动优化。它的原理是在函数初始化的最后阶段对其制作快照,下次调用时直接加载快照而无需重新初始化,从而大幅降低冷启动时间。

另一个关键的无服务器组件是GameLift,它具有低成本、就近接入和高可用等特点。GameLift的核心是匹配引擎,可以预先设定匹配规则,如将延迟相近的玩家分配到同一房间,或将等级相近的玩家匹配在一起等。

在漫威Snap的架构中,玩家先向API Gateway发送匹配请求,由Lambda调用GameLift的FlexMatch API完成玩家匹配。匹配成功后,GameLift会将事件推送到简单通知服务SNS,触发Lambda将结果存入无服务器数据库DynamoDB,最终通知玩家已找到战斗对手,可以加入战斗服务进行对战。

这种无服务器会话托管方案中,游戏开发商无需运维任何EC2实例,通过亚马逊云科技的无服务器服务就可以构建出完整的游戏架构。在这方面,一个典型的最佳实践是猛兽派对游戏。该游戏在2023年底发布当天,前两个小时就有超过10万用户同时涌入游戏,利用GameLift的FlexMatch功能可以完美承接这样的高并发访问流量。

总的来说,无服务器架构让游戏开发商可以把更多精力放在游戏本身的开发、创意和迭代上,而无需操心底层基础设施的运维工作,实现了真正的应用现代化。通过利用亚马逊云科技的一系列无服务器服务,游戏开发商可以快速构建并扩展游戏服务,根据需求分钟级扩缩容,从而获得前所未有的敏捷性和弹性,真正实现了游戏基础设施现代化的目标。

总结

在这场精彩的演讲中,演讲者分享了游戏战斗服务现代化的关键挑战和解决方案。首先,他强调了弹性扩容、集中管理和高可用性是游戏战斗服务面临的三大挑战。接着,他回顾了游戏服务器计算平台的演进历程,从物理服务器到云上虚拟机,再到容器化和无服务器架构,每一步都在解决前一阶段的痛点。

演讲者详细介绍了三种部署模式:实例托管、容器托管和云原生部署。他解释了每种模式的架构特点、优缺点和适用场景,并分享了亚马逊云科技在这些领域的产品和服务。特别值得一提的是,他深入探讨了亚马逊云科技的Graviton ARM架构、EKS容器服务和GameLift无服务器游戏服务,展示了它们在提高性能、降低成本和简化运维方面的优势。

最后,演讲者呼吁游戏开发商拥抱云原生,利用无服务器架构来降低运维负担,专注于游戏创意和迭代。他以漫威SNAP游戏为例,详细阐述了如何利用亚马逊云科技的Lambda、API Gateway、GameLift等服务构建一个高性能、低成本且无需维护服务器的游戏架构。总的来说,这场演讲为游戏开发商提供了宝贵的技术见解和实践经验,有助于他们顺利完成游戏战斗服务的现代化转型。