峰值21WQps、亿级DAU，小游戏《羊了个羊》是怎么架构的？

小游戏《羊了个羊》 短短的7天内，DAU突破了1亿、吞吐量峰值21WQps。

《羊了个羊》运营后台数据显示，在短短的7天内，这款小游戏的DAU就突破了1亿。

要知道，除了王者荣耀、原神等屈指可数的现象级手游之外，1亿DAU是这个行业的天花板，

可是，它却被一个看上去设计粗糙的小程序游戏轻松实现了。

然而，其最初技术架构仅支撑 5000QPS并发，7天内突破了1亿、吞吐量峰值21WQps

如何通过架构优化，让一款小程序游戏可以在短时间内实现对上亿DAU的支持？

技术架构、运维体系、以及安全防范等技术体系都存在巨大的挑战。

那么：峰值21WQps、亿级DAU，超高吞吐小游戏，是怎么架构的？

1 低吞吐、低可用的最初技术架构

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

因为技术以及时间等因素，在设计上有些简单，

如下图1所示，

玩家流量通过一个接入层 LB进入，

传输给服务层几个 POD 进行游戏逻辑处理，

再将数据进行存储，

其中，热数据存储在Redis中, 持久化数据存在MongoDB。

最初的服务层几个 POD ，都是单点服务

单点服务的性能瓶颈，再加上代码未进行充分优化，造成当时的系统最高只能承受5000的QPS，

但实际流量增长很快， 并且持续升高并到达性能瓶颈，游戏服务开始瘫痪，全部玩家无法再进行游戏。

2 技术架构全面升级

大部分项目，都存在低吞吐、低可用的最初技术架构

但是，如果吞吐量一上来，就面临着优化

so，

面对服务中断， 《羊了个羊》团队在详细分析原来架构的不足之后，

《羊了个羊》 做了 技术架构全面升级

具体如下图：

接入层的架构优化：

• 启用CDN做游戏动静态资源分离，让玩家使用的游戏资源实现就近下载，减轻网络端压力；
• 设计多LB入口实现入口高可用和限流，避免系统被超额流量过载；

服务层的架构优化：

• 优化服务层的自动扩容，应