如何像Marvel Snap一样打造“无服务器游戏架构”

【GameLook专稿，未经授权不得转载！】
GameLook报道/去年下半年上线的《Marvel Snap》毫无疑问是一匹黑马，不仅拿下了TGA 2022的年度最佳手游奖项，在市场表现上也十分亮眼，自上线后便迅速进入过超70个国家和地区的iOS免费榜TOP10，并一度登顶全球单日下载榜首位，首月流水破亿。

第三方数据显示，目前该游戏的过去30天流水依旧在9000万元左右。

作为业内备受大中小游戏厂商偏爱的卡牌游戏，《Marvel Snap》的成功必然具有可学习借鉴的要素。从研发到发行一系列综合因素的共同作用下，游戏公司才能够产出一款成功的游戏。

在近日亚马逊云科技举办的2023游戏开发者大会上，来自亚马逊云科技的资深游戏架构师齐海澎就以《Marvel Snap》这个绝佳的案例，讲述了无服务器架构在节约游戏研发成本、提高效率方面的作用。

以下是亚马逊云科技资深游戏架构师齐海澎的演讲实录：

齐海澎：大家好，我是亚马逊云科技的资深解决方案架构师谢海鹏，同时也是亚马逊中国游戏技术社区的负责人。非常高兴今天有机会跟大家分享这个技术话题“像《Marvel Snap》一样打造一款无服务器游戏架构”。

去年TGA评选的年度最佳移动游戏《Marvel Snap》，通过介绍它，我们能够了解它使用了哪些服务，同时帮助大家理解Serverless的游戏架构的好处，希望能对大家有所帮助，更希望我们亚马逊云科技的服务能够为各位业务的创新提供助力、如虎添翼。

我们今天的议题主要分为这三个部分，同时最后我会做一个总结，并为大家准备了会后的拓展阅读：

在讲案例之前，我们先铺垫一下Serverless的好处，什么样的业务更适合Serverless？

这一段是世界四大会议室事务所德勤统计过的一些数据，开发人员80%的时间花在了应用程序的维护和运营上，只有20%的时间用在了创新上。

回想一下，我们的工作经历中，是不是总是在维护和部署上花费了太多的精力？为了解决这一问题，我们连带着要去解决更多的问题，是不是非常想在开发上做更多的创新，而不是总想着维护这些旧的系统？

那么我们应该如何解决这些问题呢？我们的答案是将系统性的服务打散成微服务、打散成API，甚至想办法将它Serverless化。

提到系统的打散，我们首先想到的就是微服务。诚然，容器技术已经越来越被大家所接纳和广泛地应用，我们很多的服务也可以通过容器的这种高密度做成各种小的微服务（Micro Service）。这些无服务或者是小的模块相对比较独立，但同时也比较统一。

为什么要把这种结构化的应用变成模块化呢？加尔定律介绍，一个运转正常的复杂系统总是从一个运转正常的简单系统演化而来。

无处不在的云本质上就是一个非常复杂的分布式系统，它建立在这些简单的原则之上，如果你想要构建一个有效的复杂的系统，就需要先构建一个更简单的系统，随着时间的推移，对它进行不断地改进。

从这个图我们可以看到，我们有非常丰富的服务体系去支撑每一个微服务的架构，而且它是Serverless化的，甚至你都不需要去容器化，只需要把代码上传上去，就可以非常方便地帮你自动化地管理。同时通过这种消息总线，将你们的服务生产消息和事件进行统一的管理和传递，同时将数据的持久化做到对应的数据库中。

这样的好处非常地多，首先就是非常节省人力。在我们接触过的一些无服务器项目里，参与运维的人员其实非常少，传统的业务里，我们可能需要网络工程师、技术架构的运维工程师、业务的运维等角色。

而Serverless项目往往只需要一两个懂DevOps的运维，或者干脆完全都是开发工程师，就可以通过SDK代码管理的方式进行所有的管理。这些被节省的人力所负责的事情，亚马逊云科技后台会全都统一帮你进行管理。

其次就是节省时间。不需要协调任何资源，比如找基础设施、选型、选点、选择扩容方案等，能大大地加速了业务上线的速度和上线后的维护工作。

最后就是整套架构体系非常贴近于开发人员的思路，就像写代码的时候程序需要申请多少核多少内存，全部都可以通过亚马逊云科技的API和SDK进行底层的申请资源，天然地解决了开发和部署的壁垒。

以上，好处非常贴近云原生。如果做得好可以做到省人、省事还有省时。

前面讲了Serverless的几点好处，接下来我们介绍《Marvel Snap》这个项目的Serverless之旅。

刚刚过去的GDC大会上，我也负责这款游戏发行的同事一起在GDC大会上做了分享主要，就是介绍这款去年TGA年度最佳手游大奖的获得者《Marvel Snap》。

它都使用了哪些服务呢？

可以说从网络加速到计算、存储，完全使用了我们的Serverless服务，这里就不一一介绍了，我们主要使用了Lambda这种函数式的计算服务，匹配使用了托管的GameLift FlexMatch游戏的对战匹配服务，数据库使用了DynamoDB这款亚马逊的明星产品。

从亚马逊电商到迪士尼影业再到游戏行业里的《皇室战争》《堡垒之夜》《绝地求生》还有拳头游戏这些游戏公司，大量地使用了DynamicDB。

那么使用了这些服务，客户的体验到底是怎么样呢？首先我们要提到他的制作人，我想大家可能会有些眼熟，他就是前暴雪游戏《炉石传说》的制作人Ben Brode。

这款游戏上线以后大获成功，Ben也表达了对亚马逊云科技的高度肯定，他表示合作以来，让亚马逊帮助他管理后端服务，能够让他们非常专注于游戏开发，而且游戏上线以后扩展性非常好，能够非常动态地适配全球的玩家，很高兴能够继续跟我们继续合作。

他们的首席软件工程师还有后端的架构负责人也对亚马逊整套的Serverless服务表示了高度的肯定，上线之后的零错误启动、控制成本、实现双赢是对我们服务最高的评价。

那么这款游戏它的架构是什么样子的？

首先我们可以看一下传统卡牌游戏的架构，可以看到，其实还是非常传统的三层架构：一个集群做登录、匹配等一系列工作；一个集群做游戏对战服；然后另外一个集群用来做它整个平台的聊天、排行榜等服务。

接下来介绍的Serverless架构就没有那么明确的分层概念了，每个功能都可以独立成一个链条存在。

我们先来看一个非常high-level的架构图，如果全部展开，其实非常大，所以我们先概括一下整体的架构情况，后面我们再通过不断地打散，对每一个微服务进行理解。

如何通过咱们的服务和API去进行设计？大概的游戏逻辑是什么样子呢？

首先就是前面的接入层，我们通过CDN的加速以及Buff防火墙的保护，接着进入API Gateway。我们将服务分成长链接和短链接两种类型，其实它会有很多很多的Domain分别路由到不同功能的Lambda里。我们可以看到。我们整体用了大概两三百个Lambda。

而匹配上，我们通过GameLift去做搓合游戏的部分，匹配完成后我们把结果写到DynamoDB里，然后玩家就可以通过客户端将每个回合的操作同步到我们的数据库里，直到对战的完成。

整个游戏从开始对战到游戏结束，再到进入游戏结算以及卡牌的收集，整个过程都不需要任何一台服务器的参与，全部是通过代码进行管理的。

这整个架构可以说非常地先进，这个架构支撑了全球数千万的下载，以及每天大概百万DAU的卡牌对战服务。

那么支撑了这么大量级的Serverless游戏服务，后端用了哪些设计原理呢？

首先就是它每个模块是分别独立的，它独立支撑起自己负责的逻辑。

游戏总共分为五大模块，比如说我们可以把这些实践复制到我们其他游戏客户，或者说任何我们自己的业务里。这样的话我们任何客户的类似场景都可以复用这些模块。

第二，每个模块其实又是统一的。API这种开发模式和数据的结构它都是统一进行的。

第三，每项功能都可以用独立的表去存储自己的持久化数据还有缓存数据，将所有的请求无状态化。这就是从项目里总结的几点设计原理。

那么我们怎么去理解呢？

首先第一点就是模块独立，同时模块的数据表是可以共用的，既保证了我们的每个模块独立，同时数据也可以进行统一。

按功能去区分，我们可以使用WebSocket保持客户的长链接和HTTP的短链接。这样的话既能够区分长链接，又能区分短链接，这样不仅能够保证我们的业务功能完整，也能保证整个请求的成本降低。

然后验证等API的功能，可以在不同的模块进行复用。

然后信息等所有的交互全都放在DynamoDB里。

通过SNS、SQL还有EventBridge这些消息总线，进行推送和队列延迟触发的功能，能够大大降低LAMBDA计算的消耗。

然后逻辑也可以很好地进行解耦，比如说匹配完成以后创建了GameID，玩家对局就可以通过Game表中实时更新的对局信息，实现对战部分，然后对战的模块就可以交给下一个模块进行完成。所有的数据通过DynamoDB进行传递。

游戏开发的过程中，整个过程其实可以做得非常优雅。

游戏的开发可以通过Github把它的代码进行托管和管理，然后把他的C#和Go的代码放到S3上面，然后运维团队就可以通过写好的CDK去完成SAM和ColorFormation的模板建立，通过CodePipeline进行代码的构建和部署。LAMBDA、API、Gateway等这些创建也都是通过这整个Pipeline进行构建的。

所以在发布的过程中都是通过版本控制去做的，然后新建的LAMBDA完成测试以后，就可以通过切换进行蓝绿的部署，老的LAMBDA不用也不需要花费任何额外的金钱。方便出问题以后及时进行回滚。

那么当运维团队和发行团队还有运营团队共同制定好发布计划以后，他们就可以通过线上的账号去操作测试账号，完成测试代码和模板。整个过程只需要进行代码的操作，而不需要管理一台服务器，也不需要任何的人工的部署和维护。

前面讲了它怎么去部署，如何Debug Serverless这些服务呢？

我们就要提到Cloudwatch。几乎所有的信息都可以通过Cloudwatch去获取，通过Cloudwatch和开发自己的一些监控工具或监控平台，可以做到关键指标的监控。

而这里我们要提到X-Ray这个服务，这个是微服务调用链里，整个监控链条里面非常重要的监控服务，它可以在soft-launch阶段，或者在测试阶段，有效地帮助我们客户进行监控各个环境里一些应用效能情况，开发测试阶段可以帮客户花小钱节省线上发布以后可能会浪费的大钱。

还有一些监控指标比较关键。比如说API Gateway的一些request、SNS的TPS和SQS的Dialect Q等，这些指标都是非常关键的一些监控服务，这些服务都可以帮助我们快速地分析应用的运行情况。

案例的最后我想总结一下整个serverless游戏上线的关键步骤。

游戏服务启动阶段其实最关键的就是理解服务。保证整个逻辑的自洽，还有就是拓展有没有错误。

第二就是压测。整个压测是非常关键的，能够提前发现业务的瓶颈，从而提高整个业务的承载能力，对问题提前进行解决。

最后就是对监控进行分析，可以将成本优化到极致。

接下来我们来看一下Serverless架构的核心部分，整个数据库如何去选型？

有句话说得好，工欲善其事必先利其器，那么可以选择什么样的数据库来帮助我们的应用如虎添翼呢？使用serverless架构那么首先要想到我们的数据库也最好用到Serverless。

Serverless数据库它的架构主要是可以做到动态扩展。我们传统的数据库很难做到，如果说预备多了可能会浪费，预备少了可能不够用，手动伸缩太浪费人力，而且可能会面临数据库重启，业务的中断。

那么我们就需要Serverless去帮助我们解决这些问题。Serverless数据库其实具备非常高的可用性，无须管理、自动伸缩、按量收费，可以做到非常好的动态伸缩能力，而且Serverless的价格能够动态适配我们玩家人数的变化。

从这张图我们可以看到，自建数据库需要管理这么多的事情，第二个就是托管，可以减少一大半的工作量，而serverless数据库更是帮我们减轻了在管理上，所有需要操心的点，基本上就不用操心任何底层的选型等东西。

我们这些数据库还具备全球部署的能力，依托于亚马逊云科技底层遍布全球的骨干网，可以快速帮助客户完成容灾设计，提升整体系统的可用性。

利用骨干网比之前Internet的传输更加稳定和快速，全球的数据同步整体不超过一秒钟，而且故障的时间也不会超过一分钟。在整个关系型数据库和非关系型数据库，以及内存型文档型，都支持跨区域的全球数据同步。

今天的分享接近尾声，最后一部分其实是总结和拓展阅读部分，这也是我给大家准备的一些take away。首先是回顾总结一下今天的内容，接着这三篇Serverless的游戏方法论的blog，非常有质量也非常推荐大家去阅读一下。

非常感谢大家能够参加我们线上的Game Tech Day的活动，希望大家能够获取到自己有用的信息，我们也将竭诚为大家服务，谢谢。