首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >7天DAU超亿级,《羊了个羊》技术架构升级实战

7天DAU超亿级,《羊了个羊》技术架构升级实战

作者头像
腾讯云开发者
发布2023-01-18 12:42:16
8080
发布2023-01-18 12:42:16
举报

导语 | 在短短的7天内,羊了个羊小游戏的DAU突破了1亿。然而,其最初技术架构仅支撑5000QPS并发,无论技术、人力、资源以及服务都难以应对。用户涌入、数据飙升,给原有的技术架构、运维体系、以及安全防范等技术体系都带来了巨大的挑战。如何通过架构优化,让一款小程序游戏可以在短时间内实现对上亿DAU的支持?本文将从技术角度解读这背后的技术实践历程,希望为正在从事小游戏开发的技术同行带来一些参考。

目录

1 背景

2 架构全面升级

3 插件集成

    3.1 一崩再崩,自动扩容为何不灵?

    3.2 运维能力不足,如何快速补齐?

    3.3 BOT刷排行,如何保持游戏公平?

4 小游戏设计的“三高”原则

背景

谁也没有想到,去年9月,一款卡通背景消除闯关游戏《羊了个羊》全网迅速刷屏。但凡一个拿着手机目不转睛的人,九成概率都在忙着通关,还有大批的人,因为不能通关而通宵达旦,夜不能寐。

后台数据显示,在短短的7天内,这款小游戏的DAU就突破了1亿。要知道,除了王者荣耀、原神等屈指可数的现象级手游之外,1亿DAU是这个行业的喜马拉雅山,可是,它却被一个看上去设计粗糙的小程序游戏轻松实现了。

用户涌入、数据飙升,实际上给原有的技术架构、运维体系、以及安全防范等技术体系都带来了巨大的挑战,这个创业团队一共只有几个人,最初的技术架构仅支撑5000QPS并发,因此,无论技术、人力、资源以及服务都越来越难以应对。

如何通过架构优化,让一款小程序游戏可以在短时间内实现对上亿DAU的支持?本文将从技术角度解读这背后的技术实践历程,希望为正在从事小游戏开发的技术同行一些参考。

架构全面升级

一款小游戏能不能成功,不仅和本身的通关设计有着巨大的关系,而且还和上量之后,系统能否持续稳定也密切相关。《羊了个羊》这款小游戏在爆火之后的前几天,曾经在技术架构面临严峻考验,这对一款正在用户量快速爬坡的小游戏来说,可以说是致命的挑战,如果不能快速解决,将会大幅降低玩家的游戏体验,从而快速被用户抛弃。

《羊了个羊》在最开始也遇到了这样的问题,就是一瞬间,涌入海量用户,速度之快,人数之多,超过了所有人的预期。就像一条双向两车道,车流量不大的情况下,还能正常行驶,可一旦来了成千上万辆车,交通的效率肯定大打折扣,甚至堵死。

现在回过头看,最开始的技术架构因为技术以及时间等因素,在设计上有些简单,如下图1所示,玩家流量通过一个LB进入,传输给几个POD进行游戏逻辑处理, 再将数据进行存储,其中,热数据存储在Redis中, 持久化数据存在MongoDB。

由于设计时,对如此大流量缺乏充分考虑,实际上也没有料想到会有这么大的流量,而且单点服务的性能瓶颈,再加上代码未进行充分优化,造成当时的系统最高只能承受5000的QPS,但实际流量增长很快, 并且持续升高并到达性能瓶颈,游戏服务开始瘫痪,全部玩家无法再进行游戏。

《羊了个羊》最开始技术架构

面对服务中断, 《羊了个羊》和腾讯云服务团队在详细分析原来架构的不足之后,决定从三个方面,针对原有架构做重点优化:在计算扩容层,依靠腾讯云云原生产品为原有技术架构升级,实现服务高可用;为快速补齐运维能力,通过业务日志诊断程序性能,配合业务调优以减少服务器压力;最后在安全防范领域,通过安全方案抵抗异常流量攻击。

《羊了个羊》最新技术架构

具体措施上,首先通过引入腾讯云TKE Serverless 的弹性机制, 实现游戏服自动纵向和横向扩展,实现服务解藕,增加容错和熔断机制;

其次,通过腾讯云开箱即用的日志服务 CLS,对游戏接口稳定性/异常调用趋势进行监控,帮助用户快速观测产品质量 ,并第一时间获取到异常panic统计分析和告警 。

同时,还要针对许多恶意BOT流量大量涌入到游戏中,导致游戏服务器 QPS、带宽快速升高,影响服务可用性等情况,引入WAF+高防包, 抵御外部异常流量攻击。

在此之外,双方产研团队还通过启用CDN做游戏动静态资源分离,让玩家使用的游戏资源实现就近下载,减轻网络端压力;设计多LB入口实现入口高可用和限流,避免系统被超额流量过载;把MongoDB转换为读写分离模式,配合代码逻辑优化实现性能提升,引入分库实现业务分层与隔离,Redis缓存热数据,分担数据库查询压力等。

经过上述一系列技术升级, 新架构经受住了一波又一波的流量峰值考验,甚至在高峰期DAU过亿后,游戏技术系统依旧表现稳定,这对于一个发布才几个月的小游戏来说,在国内也很难再找到这样的例子。

技术实战:扩容、运维、安全

下面我们将从扩容、运维、以及安全三大核心环节入手,详细介绍在具体实操过程中,双方是如何应对流量的爆发挑战的。

3.1 一崩再崩,自动扩容为何不灵?

在展开之前,先说下这次起到至关重要的一款产品----TKE Serverless ,它是基于腾讯云 TKE 容器服务孵化出来的一种全新的无需管理服务器形态的 Kubernetes 容器服务平台,最核心的利器是拥有一个全新的集群节点管理模式,称之为超级节点。

上云的开发者都知道虚拟机,超级节点就类似于一台超大规格的 CVM 虚拟机,它是基于 Serverless 容器技术,模拟 Serverful 有节点管理体验的新形态容器集群节点。如果用户需要进行固定资源的扩缩容,仅需要对这台“超大规格的 CVM”进行升降配,简单点击几个鼠标,就可以配置完成,资源管理变得极为简单。

实际上,《羊了个羊》在6月上线初期就采用了 TKE Serverless 的云原生方式部署游戏系统,希望借助产品的免运维及快速扩缩容能力,支撑未来玩家的规模增长,但在9月上旬,《羊了个羊》突然一夜爆火,玩家规模急剧上升,游戏系统开始出现不稳定的情况。

经过梳理发现,因为初始配置的容器规格比较低,副本数也相对较少,当初始玩家规模不断上涨时,《羊了个羊》团队根据 TKE 控制台的监控/告警能力,发现容器的 CPU/内存等各项指标都达到了最大值,运维同学当时随即做出调整,游戏服务的各项指标稳定了下来。

但随着玩家规模继续上涨达到千万级别时,游戏又开始出现了偶发的不稳定问题,表现为内存指标快速增加直到打满整个容器,且流量还在不断增长中。腾讯云团队紧急联合《羊了个羊》产研团队分析应用的瓶颈,快速解决了如服务内存泄露、服务分级缓存策略、云产品配额限制等多个问题,这才让游戏服务逐渐稳定了下来。

由于《羊了个羊》技术团队配置了基于 CPU 指标的容器 HPA 动态扩缩容策略,在游戏日活持续陡增的情况下,系统能够在秒级自动扩容了近万核容器资源。在此期间,也无需投入人力运维 Kubernetes 集群以及担心资源不足等问题,从而可以把精力都投入到游戏玩法优化上来。在随后的两周时间,尽管玩家规模增长到几百倍以上,最终达到了上亿的日活,这套服务依旧保持稳定。

3.2 运维能力不足,如何快速补齐?

通过技术架构的迭代以及不断激增的用户,《羊了个羊》技术团队也认识到,因为爆火太快,更需要快速补齐运维能力,才能更好的持续调整和提升游戏体验。

为此,《羊了个羊》选择了开箱即用的日志服务 CLS,CLS 对游戏接口稳定性、异常调用趋势的监控可帮助他们快速观测产品质量 ,并第一时间获取到异常panic统计分析和告警 ;在游戏运营方面,玩家登录链路耗时/对局时间等数据亦可通过 CLS 分析、校验及处理,进而调整和提升游戏体验;同时还能满足游戏用户行为及审计对账等需求。

TKE Serverless在提供充足的计算资源后,可以使用CLS的云原生特性实现稳定性和程序调优。用户研发人员仅需在容器控制台点击新建日志采集按钮即可完成数据接入,无需在运维上投入人力。

借助云原生的能力和CLS的SQL分析、仪表盘、监控告警能力,分析出程序可优化点, 解决游戏开发商在初期和爆发期对游戏稳定性和运营数据分析的难题。

除了运维数据外,用户还将部分运营数据接入CLS。在游戏调整玩法、分析活动数据时,运营人员可借助CLS快速观测数据变化,并作出应对策略。游戏开发商在将CLS用作简单运维工具查日志、做接口调用告警外的同时,还将游戏的通关数据、用户行为分析、审计对账等运营数据在CLS中存储分析。

3.3 恶意BOT抢刷排行,如何保持游戏公平?

哪里有流量,哪里就有黑产。

由于设计之初没有充分考虑安全问题,因此引来大量不法分子通过恶意BOT抢刷游戏排行,几乎每分每秒,都有恶意流量访问游戏接口,并且这一部分恶意群体通过互联网、QQ群和微信群中传播恶意刷排行的脚本,极大的破坏了游戏公平性,让本该属于游戏对抗的乐趣被恶意BOT抹杀。

而且更重要的是随着羊了个羊热度的不但攀升,许多恶意BOT流量的大量涌入,导致游戏服务器 QPS、带宽快速升高,一度影响服务可用性。经过双方产研团队合作,决定快速接入腾讯云WAF进行防护,一开始接入WAF的时候,相关 QPS 峰值已达 21W,接入WAF之前CPU一直处于临界值水位 、网络链接打满的导致服务不可用的情况。

通过选择负载均衡型WAF即可在不改动网络架构的情况下3秒完成业务接入,实现在用户无感的情况下对恶意流量进行清洗及防护。为了有效打击攻击者的恶意流量, WAF 中 BOT 行为管理也提供了全链路、全生命周期的的恶意行为流量体系,实现快速高效的恶意流量治理。

小游戏设计的“三高”原则

通过腾讯云这次完整支持《羊了个羊》团队在小游戏架构扩容、系统运维以及安全防范领域的实战经验,我们也得到了一些启发,希望给同行一些参考。比如面对突发流量,小游戏系统在设计的过程中需要考虑以下能力:第一是高性能,能够承载瞬时爆发流量,保证响应时长在可接受的范围;其次是高可用,系统持续提供服务,小概率发生宕机时,过载保护将故障控制在可承受范围内,不影响核心业务;最后是高扩展,服务系统应该具备水平和垂直扩展能力,在成本和可用性中实现最佳平衡点。

我们也看到,目前在国内甚至国际上,小游戏发行商还是以中小型游戏公司为主,公司大都处于早期创业或融资阶段,对云产品不熟悉、技术能力参差不齐,在算力资源、技术架构、业务逻辑、运维经验方面缺乏成熟的经验,这些都是小游戏公司早期非常典型的困境。通过腾讯云和《羊了个羊》产研团队的这次密切合作,不仅让腾讯云在服务类似客户上积累了宝贵的经验,也为未来的发展指明了清晰的目标,就是针对不同赛道搭建标准化架构,为游戏公司的业务保驾护航

上期文章的开发者读者们太热情啦

😻小云继续给各位加赠福利😻

扫码下图一键领红包封面

如被领取完 请关注开发者公众号

在后台回复【2023】继续领取

你可能感兴趣的腾讯工程师作品

| 你的2022年度开发者关键词,请查收>>

React语境下前端DDD的长年探索经验

| 国民级应用:微信是如何防止崩溃的?

| 从Linux零拷贝深入了解Linux-I/O

技术盲盒:前端后端AI与算法运维工程师文化

🔹关注我并点亮星标🔹

工作日晚8点 看腾讯技术、学专家经验

点赞|分享|在看 传递好技术

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2023-01-16,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 腾讯云开发者 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  •     3.1 一崩再崩,自动扩容为何不灵?
  • 3.1 一崩再崩,自动扩容为何不灵?
  • 3.3 恶意BOT抢刷排行,如何保持游戏公平?
相关产品与服务
容器服务
腾讯云容器服务(Tencent Kubernetes Engine, TKE)基于原生 kubernetes 提供以容器为核心的、高度可扩展的高性能容器管理服务,覆盖 Serverless、边缘计算、分布式云等多种业务部署场景,业内首创单个集群兼容多种计算节点的容器资源管理模式。同时产品作为云原生 Finops 领先布道者,主导开源项目Crane,全面助力客户实现资源优化、成本控制。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档