手游团队最难熬的时刻，通常是新服开放、版本更新或大型活动上线后的头几个小时。玩家一下子涌进来，登录排队，充值失败，匹配超时，口碑也跟着掉。阿里云手游相关的基础设施，主要解决的就是高峰时的承载问题，同时尽量不让平时的成本虚高。
手游为什么越来越多地用云上资源
早些年，很多团队自建机房，服务器按峰值买，平时大半闲着。突发流量来了，采购和部署又跟不上。云把服务器、数据库和存储变成按需取用的资源，扩容按分钟计算，流量回落后也能缩回去。
对手游来说，云上架构的用处大致有三类：
- 弹性伸缩：按在线人数自动增减游戏服务器实例。平日少开几台，高峰前由规则自动加上，不用半夜找人手动扩容。
- 全球覆盖：海外发行时，把节点放在玩家所在地区，延迟通常能降下来。具体放哪些地区，要看玩家分布，不能只凭感觉。
- 安全防护：手游常遭遇流量攻击和外挂刷量。防护服务能把异常流量挡在外面，但规则要根据自己的业务调整，默认配置未必适合登录和充值接口。
阿里云手游项目里常用的几类服务
选型时没必要一次全部接入。多数团队先用下面几类，等业务变复杂了再逐步加。
计算与容器
游戏逻辑服务器一般放在弹性计算实例或容器集群里。容器方便按房间或区服快速复制，也方便灰度发布，可以先放一小部分玩家进来看结果。上线前要测出单个实例能稳定承载的人数，再据此设定扩容阈值，比如 CPU 使用率或房间数超过某个数值时新增实例。没有压测数据之前，阈值最好先留出余量，不要定死。
数据库与缓存
背包、排行榜、好友关系这类数据读写非常频繁。关系型数据库保存充值记录、账号信息这些必须准确的核心数据。缓存负责排行榜、在线状态这类高频读取。两边分工清楚，大量请求才不会全部压到数据库上。
对象存储与内容分发
安装包、资源更新包和截图视频的体积都不小。放在对象存储里，再经内容分发网络发给玩家，更新等待时间会短一些。版本更新当天，这一步直接影响玩家会不会卡在下载界面上放弃。
实时通信与安全防护
语音开黑和实时对战对延迟敏感，音视频服务要单独测试。游戏盾或 DDoS 防护用来应对恶意攻击。两类服务都要在上线前压测一遍，并确认告警消息能送到值班人手上。
案例：一款休闲手游的周末活动高峰
某休闲手游团队（以下简称“该团队”）在 2023 年底推出限时联动活动。上线前，日活约为 [待核实：日活数字]，运营预计活动首日在线峰值会达到平日的 [待核实：倍数] 倍。
该团队原有架构是单一地域的几台固定服务器，数据库和逻辑服务混在一起运行。以往活动开始后，前 30 分钟排队最严重，登录接口会陆续超时。
针对这个问题，技术负责人做了三处调整：
- 把登录和匹配服务拆成独立的容器集群，并按在线人数设置自动扩容规则。拆开之后，某一块出问题时不会拖垮整个服务。
- 排行榜数据迁入缓存，数据库只负责写入和对账。排行榜被频繁刷新时，大量读请求不再直接打到数据库。
- 活动前一周做两轮压测，模拟峰值的 [待核实：压测倍数] 倍流量，逐个记录接口的响应时间和错误率。压测结果直接用来校准扩容阈值。
活动当晚，在线人数在开启后 20 分钟内升到峰值，自动扩容按规则新增了 [待核实：实例数量] 个实例。登录平均耗时从 [待核实：改造前耗时] 降到 [待核实：改造后耗时]，充值成功率保持在 [待核实：成功率] 以上。整个过程中，运维人员没有手动干预。
这次改造的效果来自三个具体动作。拆分服务缩小了故障范围，缓存减轻了数据库的读压力，压测则让扩容阈值有了依据。单纯加机器解决不了数据库的瓶颈，这一点在改造前后的对比里看得很清楚。
上线前的检查清单
- 核对峰值预估的依据，包括历史活动数据、买量计划和社区热度。把每项依据写下来，不要只凭一句“应该会很火”。
- 压测至少覆盖登录、充值、匹配三条核心链路。只压单个接口，测不出几条链路同时请求时的相互影响。
- 给自动扩容设定上限和下限。下限保证开服时有足够实例，上限防止异常流量把账单顶上去。
- 备份数据库，并实际演练一次回滚。没有演练过的回滚流程，出事时大概率用不上。
- 配置告警并指定到具体的人，确认夜间有人能收到。告警发到一个没人看的群里，等于没有配置。
- 提前和客服、运营对齐公告，写清楚可能的排队时长和维护时间。否则玩家在群里反馈卡顿时，客服没有统一口径可以回复。
常见误区
第一个误区是把扩容当成万能办法。实例数量上去了，如果数据库连接数上限没有调整，瓶颈只是换了位置。第二个误区是压测只盯单个接口，忽略多个接口同时请求时的相互影响。第三个误区是活动结束后不缩容，实例一直开着，费用会悄悄累积。
选型时，压测数据和成本报表应该排在产品列表前面。方案是否有效，最终要用这两份数据来验证。
