在游戏运营行业，函数计算如何解决数据采集分析痛点？

众所周知，游戏行业在当今的互联网行业中算是一棵常青树。在疫情之前的 2019 年，中国游戏市场营收规模约 2884.8 亿元，同比增长 17.1%。2020 年因为疫情，游戏行业更是突飞猛进。玩游戏本就是中国网民最普遍的娱乐方式之一，疫情期间更甚。据不完全统计，截至 2019 年，中国移动游戏用户规模约 6.6 亿人，占中国总网民规模 8.47 亿的 77.92%，可见游戏作为一种低门槛、低成本的娱乐手段，已成为大部分人生活中习以为常的一部分。

对于玩家而言，市面上的游戏数量多如牛毛，那么玩家如何能发现和认知到一款游戏，并且持续的玩下去恐怕是所有游戏厂商需要思考的问题。加之 2018 年游戏版号停发事件，游戏厂商更加珍惜每一个已获得版号的游戏产品，所以这也使得“深度打磨产品质量”和“提高运营精细程度”这两个游戏产业发展方向成为广大游戏厂商的发展思路，无论是新游戏还是老游戏都在努力落实这两点：

• 新游戏：面向玩家需要提供更充足的推广资源和更完整的游戏内容。

• 老游戏：通过用户行为分析，投入更多的精力和成本，制作更优质的版本内容。

这里我们重点来看新游戏。一家游戏企业辛辛苦苦研发三年，等着新游戏发售时一飞冲天。那么问题来了，新游戏如何被广大玩家看到？

首先来看看游戏行业公司的分类：

• 游戏研发商：研发游戏的公司，生产和制作游戏内容。比如王者荣耀的所有英雄设计、游戏战斗场景、战斗逻辑等，全部由游戏研发公司提供。

• 游戏发行商：游戏发行商的主要工作分三大块：市场工作、运营工作、客服工作。游戏发行商把控游戏命脉，市场工作核心是导入玩家，运营工作核心是将用户价值最大化、赚取更多利益。

• 游戏平台/渠道商：游戏平台和渠道商的核心目的就是曝光游戏，让尽量多的人能发现你的游戏。

这三种类型的业务，有专注于其中某一领域的独立公司，也有能承接全部业务的公司，但无论那一种，这三者之间的关系是不会变的：

所以不难理解，想让更多的玩家看到你的游戏，游戏发行和运营是关键。通俗来讲，如果你的游戏出现在目前所有大家熟知的平台广告中，那么最起码游戏的新用户注册数量是很可观的。因此这就引入了一个关键词：买量。

根据数据显示，2019 年月均买量手游数达 6000+ 款，而 2018 年仅为 4200 款。另一方面，随着抖音、微博等超级 APP 在游戏买量市场的资源倾斜，也助推手游买量的效果和效率有所提升，游戏厂商更愿意使用买量的方式来吸引用户。

但需要注意的是，在游戏买量的精准化程度不断提高的同时，买量的成本也在节节攀升，唯有合理配置买量、渠道与整合营销之间的关系，才能将宣发资源发挥到最大的效果。

通俗来讲，买量其实就是在各大主流平台投放广告，广大用户看到游戏广告后，有可能会点击广告，然后进入游戏厂商的宣传页面，同时会采集用户的一些信息，然后游戏厂商对采集到的用户信息进行大数据分析，进行进一步的定向推广。

游戏运营核心诉求

---

游戏厂商花钱买量，换来的用户信息以及新用户注册信息是为持续的游戏运营服务的，那么这个场景的核心诉求就是采集用户信息的完整性。

比如说，某游戏厂商一天花 5000w 投放广告，在某平台某时段产生了每秒 1w 次的广告点击率，那么在这个时段内每一个点击广告的用户信息要完整的被采集到，然后入库进行后续分析。这就对数据采集系统提出了很高的要求。

这其中，最核心的一点就是系统暴露接口的环节要能够平稳承载买量期间不定时的流量脉冲。在买量期间，游戏厂商通常会在多个平台投放广告，每个平台投放广告的时间是不一样的，所以就会出现全天不定时的流量脉冲现象。如果这个环节出现问题，那么相当于买量的钱就打水漂了。

数据采集系统传统架构

---

上图是一个相对传统的数据采集系统架构，最关键的就是暴露 HTTP 接口回传数据这部分，这部分如果出问题，那么采集数据的链路就断了。但这部分往往会面临两个挑战：

• 当流量脉冲来的时候，这部分是否可以快速扩容以应对流量冲击。

• 游戏运营具备潮汐特性，并非天天都在进行，这就需要考虑如何优化资源利用率。

通常情况下，在游戏有运营活动之前，会提前通知运维同学，对这个环节的服务增加节点，但要增加多少其实是无法预估的，只能大概拍一个数字。这是在传统架构下经常会出现的场景，这就会导致两个问题：

• 流量太大，节点加少了，导致一部分流量的数据没有采集到。

• 流量没有预期那么大，节点加多了，导致资源浪费。

数据采集系统Serverless架构

---

我们可以通过函数计算 FC 来取代传统架构中暴露 HTTP 回传数据这部分，从而完美解决传统架构中存在问题，参考文章：资源成本双优化！看Serverless颠覆编程教育的创新实践。

先来看架构图：

传统架构中的两个问题均可以通过函数计算百毫秒弹性的特性来解决。我们并不需要去估算营销活动会带来多大的流量，也不需要去担心和考虑对数据采集系统的性能，运维同学更不需要提前预备 ECS。

因为函数计算的极致弹性特性，当没有买量、没有营销活动的时候，函数计算的运行实例是零。有买量活动时，在流量脉冲的情况下，函数计算会快速拉起实例来承载流量压力；当流量减少时，函数计算会及时释放没有请求的实例进行缩容。所以 Serverless 架构带来的优势有以下三点：

• 无需运维介入，研发同学就可以很快的搭建出来。

• 无论流量大小，均可以平稳的承接。

• 函数计算拉起的实例数量可以紧贴流量大小的曲线，做到资源利用率最优化，再加上按量计费的模式，可以最大程度优化成本。

架构解析

---

从上面的架构图可以看到，整个采集数据阶段，分了两个函数来实现，第一个函数的作用是单纯的暴露 HTTP 接口接收数据，第二个函数用于处理数据，然后将数据发送至消息队列 Kafka 和数据库 RDS。

1. 接收数据函数

我们打开函数计算控制台，创建一个函数：

• 函数类型：HTTP（即触发器为 HTTP）

• 函数名称：receiveData

• 运行环境：Python3