简介： 本文将通过剖析一个个具体的场景案例，以期望给相关的游戏开发同学带来共鸣，同时也希望能给非游戏行业的同学带来一些启发。

一、前言

1. 游戏客户上云关注点

游戏行业是一个富有创意又竞争激烈的市场，被称为第九艺术。游戏客户上云主要关注以下 4 个方面：

快速迭代，全球部署

快速迭代是游戏行业的通用需求，包括开发效率、运维效率、架构解耦；同时游戏可能也会出海，所以也需要海外部署或全球部署战略。

高并发、高弹性

每个游戏上线时都会经历新开服、运营拉新等阶段，游戏本身也有日常峰谷，再加上偶尔的活动运营，也会产生峰值，因此在游戏行业高并发高弹性也是一个通用需求。

稳定、可靠、安全

要保证游戏的公平性和用户的玩家体验，防止作弊，所以需要保证游戏的稳定可靠与安全。

数据、运维、成本控制

游戏上线后，通过日志收集数据对用户行为进行分析，根据分析结果针对不同的玩家实施不同的运维策略，将运营重点放在中间的摇摆玩家上，从而做到精准定位、控制成本。

2. 认识函数计算

下文将要介绍的案例主要与函数计算相关，因此在此先对阿里云 Serverless 产品——函数计算做一下简单介绍。

函数计算：只需要专注业务代码，面向函数极简编程（各种编程语言），丰富的云产品间集成与事件驱动方式提供端到端解决方案。

专注业务代码

如上图所示，对于游戏开发者来说，使用函数计算，就只需要选择一个你最擅长的代码，编写这段代码，上传到计算平台，就可以完成开发任务。之后可以通过 API/SDK 调用这个函数，也可以通过云产品事件源去触发函数。

上图是一个简单的例子，用 Java 函数写一个“Hello World”，把它设置成 Java8 的执行环境，256MB 的内存，设置完上传到函数计算，开发任务就完成了，之后主动调用函数即可，无需关注任何基础设施。

这里单独介绍一下“云产品事件源触发函数”。除了主动触发函数，还可以用云产品来触发。比如使用阿里云的对象存储 OSS，上传一个 zip 包到 OSS Bucket 的某个目录，希望上传之后可以自动触发一个函数，然后这个函数可以把 zip 包自动进行解压，云产品事件源触发就可以实现这种效果。另外还有其他很多事件源，比如日志的事件源、 MNS 消息事件源、定时触发事件源等。

100< 代码量

面向函数极简编程，只需要关注核心代码。还支持各种编程语言，对开发者非常友好，开发者可以选一个自己最擅长的语言，写完后上传到函数计算即可。

100ms 极致弹性

如果触发函数，同时过来 10 个、 100 个、1000 个甚至 1 万个请求都不用担心，函数计算会百毫秒级弹出执行环境，每个执行环境去执行函数逻辑代码，再把函数执行的结果返回，帮助在线业务应对各种突发流量。

100% 资源利用率

在计费方面，函数计算是按执行环境的内存和执行时间计费，计费粒度可达毫秒级，只为请求产生的资源消耗买单，资源利用率达 100%，降低成本。

二、Serverless 游戏场景实践案例

1. 高弹性战斗结算业务

战斗结算是强 CPU 密集型，结算系统每日需要大量的计算力，尤其是开服或者活动期间突然涌入的大量玩家，导致需要的计算量瞬间几倍增长，同时需要结算系统保持稳定的延时来保证玩家的用户体验。

以 SLG 游戏或者回合制游戏场景为例，一场战斗结束后，为了用户体验，客户端需要先行结算，展示这一回合的结果，比如打赢了弹出胜利动画，打输了弹出失败动画。如果纯粹依赖客户端，很可能会出现客户端作弊的情况（比如作弊器），所以最后的结算肯定还是由服务器做结算。

随着游戏策划团队想法的增加，游戏越来越复杂，比如 buff、debuff、暴击等等。随着游戏越来越好玩，结算系统会越来越复杂，游戏进程很可能会出现卡顿现象，而最好的解决方案就是把战斗结算这一 CPU 密集型的逻辑抽离出来。这一方案也尤其适用于新开服、活动期间以及每日有日常峰谷的情况等。

如上图，当客户把战斗结算迁移到函数计算上后，明显可以看到，即使 TPS 在日常峰谷呈 90° 直线上升，但是 Latency 延时仍然基本稳定在 200~300 毫秒之间，，充分保证了用户的玩家体验。

在这个场景中，函数计算的核心价值是：

弹性高可用：百毫秒级伸缩扩容，无需预留任何资源。
CI/CD 和版本灰度能力：每当游戏策划有新想法时，战斗结算函数必然会更新，可以通过直接给这个函数设置版本和别名，从而非常安全地灰度到下一个版本的战斗结算函数。

这是游戏场景里非常经典的例子，将 CPU 密集型的逻辑抽离出来放到函数计算上，在不影响 Game server 的服务器的同时，又具备了百毫秒伸缩扩容的能力，保证了玩家用户体验。

2. Serverless 实现超大规模游戏营销

游戏厂商与广告商联合投放大量互联网广告，该业务场景无法准确预估运营流量，高并发、高弹性的后台服务对业务结果至关重要。且大量的营销数据和原始日志需要进行离线分析，驱动运营策略升级。

游戏厂商的需求是：第一，游戏需要大规模营销，波峰波谷无法预估；第二，游戏需要快速上线，对开发效率要求较高。

解决方案如上图，将函数埋点到网页里面，点击时自动触发这个函数，函数再把点击传过来的用户消息持久化到 kafka。这一步函数 TPS 非常高，预估是几万或者十万级别。第二步，通过 kafka connector 把消息持久化以后，connector 可以有 batch 操作，比如把 50 次点击的数据 batch 成 1 个再发给另外一个函数，相当于后面的这个函数变成了 1/50 的调用量，另外这个函数是异步触发，加上 batch 操作，起到削峰填谷的作用，因为只需要把消息写入到数据库就可以完成任务，只要不丢数据就好。同时这个函数打印的日志也可以用 SLS 进行分析或者写入数据库 RDS/ADP 进行玩家画像的分析。

客户压测数据如下图所示，第一个函数 TPS 上升到十几万，第二个削峰填谷后变成不到 3 万。

在这个场景中，函数计算的核心价值是：

事件驱动，解耦架构难点；
弹性高可用，削峰填谷；
快速开发上线，1 天完成开发和压测。

3. Serverless 实现安卓游戏 APK 包按渠道分发

UC 的游戏分发平台的游戏 APK 包需要根据实时请求中的参数获取渠道号，并将渠道号写入 APK 文件固定位置， UC 有每天有大量的且不同渠道的下载请求，能实时让用户断点下载指定渠道的 APK 游戏包。

以阿里内部 UC 游戏分发平台为例，在对象存储里面放了一个原始包，其他包在文件固定位置加一些东西就可以。但是 UC 渠道每天有不同的下载请求，通过 Channel=UC/小米/华为到 CDN，CDN 直接回源到函数计算，比如在函数计算看到回源是小米，从 OSS 拿到原始包把小米渠道信息写进去，再把这个包直接返还给 CDN，其他渠道包同理，只要被下载过一次，都被缓存到 CDN。

这个案例中，函数计算的核心价值是：