Server Survival 游戏平衡数学模型全解析：从容量阈值到最优扩容策略的量化指南

• 游戏开发
• 教育

导读：本文以仓库 docs/GAME_BALANCE_ANALYSIS.md 为骨架，结合 src/config.js、src/core/actions.js、src/entities/Service.js 等源码与测试，系统推导 Server Survival 的经济与负载平衡模型。你将掌握：最小架构何时过载、现金流转正点在哪、EC2:S3:RDS 的最优配比、升级与新建的性价比取舍，以及 50% 负载阈值为何是整套平衡的"心脏"。

Server Survival 是一款以云架构为教学目标的塔防游戏：玩家用真实云服务（WAF、ALB、Compute、S3、DB……）搭建架构，抵御持续增长的真实流量并从中盈利。本文档（Issue #17 的产出物）用数学手段回答了五个核心问题：架构何时过载、经济何时盈利、服务配比如何最优、升级时机如何选择、故障级联如何发生。以下内容完整继承文档骨架，并逐一用仓库源码与测试交叉验证。

1. 游戏参数总览

1.1 起始条件与流量模型

流量被分为六类，各自有不同的奖励（reward）与处理权重（processingWeight），定义于 src/config.js 的trafficTypes：

合法流量合计 80%（S3 承担 35%，DB 承担 45%）。从源码看，Request对象的value、processingWeight、destination均直接读取typeConfig（见 src/entities/Request.js），与文档表格一一对应。

源码侧补充：除文档中的六类流量外，当前 src/config.js 还定义了第七类INFERENCE（AI Wave 特性 #87），奖励 $0.50、权重 1.0、目的地 gpu，仅在生存模式后期按阶段注入（0 → 3% → 10%）。文档撰写时未包含该类型，读旧文时需注意区分。

1.2 服务成本与容量

文档给出的是平衡分析基线参数：

对应实现位于 src/config.js 的services对象。注意两处已随版本演进（当前源码为准）：

• WAF 容量当前为30、ALB 为20、S3 为25、SQS 成本$45/容量50/维护$3/min——文档撰写时数值更大。容量差异不影响文档的数学方法论，但实战参考应以 src/config.js 当前值为准。
• Compute 与 DB 的 Tier 升级表在源码中有明确声明（tiers数组）：Compute T2 成本 $100、T3 $160；DB T2 $200、T3 $350，与文档一致。

1.3 维护费缩放与失败公式

维护费缩放（src/config.js 的upkeepScaling，实现见 src/core/actions.js 的getUpkeepMultiplier）：

multiplier = 1.0 + (2.0 - 1.0) × min(t/600, 1.0)

即从 1.0× 线性爬升到 2.0×，历时 600 秒（10 分钟）。源码中该缩放仅对survival模式生效，且可被COST_SPIKE事件的costMultiplier（如 3.0）叠加。

负载失败公式（核心！实现于 src/core/actions.js）：

failChance(load) = 0 若 load ≤ 0.5 = 2 × (load - 0.5) 若 load > 0.5

其中load为服务总负载（totalLoad），定义在 src/entities/Service.js：(processing + queue + 分区/批次深度) / (capacity × instances × 2)。分母携带 ×2 意味着50% 的 totalLoad 恰好对应 100% 额定容量——这是下文所有阈值计算的根。

测试佐证：tests/sim/economy.test.mjs第 167-177 行显式断言calculateFailChanceBasedOnLoad(0.5) === 0且calculateFailChanceBasedOnLoad(0.75) ≈ 0.5、(1.0) ≈ 1.0，与公式完全一致。

2. 可持续性阈值分析：最小架构何时过载

2.1 最小架构与各节点吞吐上限

最小架构为：WAF → ALB → Compute(T1) → S3/DB。各节点理论吞吐 = 容量 ÷ 处理耗时：

由于 20% 流量是 MALICIOUS（被 WAF 拦截，不进入后端），Compute 对合法流量的有效容量为6.67 × 0.8 ≈ 5.33 req/s。

2.2 失败曲线介入后的安全区间

失败公式在 50% 负载（3.33 req/s）开始起效：

• 50% 负载（3.33 req/s）→ 失败率 0%
• 75% 负载（5 req/s）→ 失败率 50%
• 100% 负载（6.67 req/s）→ 失败率 100%

因此单台 Compute T1 的安全运行区间约 3.3 req/s，边际区间 4-5 req/s（失败率攀升）。

2.3 到达关键 RPS 的时间表

由RPS = 0.6 + ln(1 + t/30) × 1.8反解时间：

结论：最小架构在 3-4 RPS（约 2-3 分钟）后不可持续，玩家必须在此之前扩容。

源码侧印证：CONFIG.load（src/config.js）的 UI 预警阈值正是围绕这条曲线设计的——ringYellow: 0.25（50% 容量）、ringOrange: 0.35（70%）、ringRed: 0.45（90%，下一帧开始掉请求）、alertUtil: 0.375（85%，首次失败前告警）。注释明确指出"红灯 = 到达容量、即将开始丢弃"，并断言排序alertUtil < ringRed = failureOnset（见tests/sim/rings-and-alert.test.mjs）。玩家在 UI 上看到红圈时，数学上已经站在悬崖边上。

3. 经济可行性分析：现金流何时转正

3.1 收入计算

每个合法请求的平均奖励：

Avg Reward = (0.30 × $0.80) + (0.20 × $1.20) + (0.15 × $1.80) + (0.05 × $2.00) + (0.10 × $1.20) = $0.24 + $0.24 + $0.27 + $0.10 + $0.12 = $0.97 / 合法请求

80% 为合法流量，因此期望收入 = RPS × 0.8 × $0.97 = RPS × $0.776/s。

3.2 最小可行架构成本

必需服务合计：WAF $40 + Compute T1 $60 + S3 $25 + DB T1 $150 =$275。起始预算 $340 剩余$65缓冲。

最小维护费（1.0× 倍率）：$4 + $12 + $5 + $24 = $45/min = $0.75/s。

3.3 盈亏平衡点

收入 = 维护费 RPS × $0.776/s = $0.75/s RPS ≈ 0.97 req/s

• 游戏开始（0.6 RPS）：收入 $0.466/s，维护 $0.75/s，净亏 -$0.284/s；
• 约5-6 秒后达到 0.97 req/s 转正；
• 10 分钟（2.0× 倍率）：维护 $1.50/s，盈亏平衡 RPS 升至 1.93；此时实际 RPS 约 6.5，收入 $5.04/s，净利 +$3.54/s。

3.4 最小架构现金流预测

结论：经济上可行——30 秒后收入超过维护费。但该预测未计入"为承接增长 RPS 而扩容"的支出。

3.5 扩容资金需求

• RPS 达 3.3（约 1:41）需第二台 Compute（$60）：届时资金约 $100-120，可负担；
• RPS 达 6.67（理论 2× Compute 容量）需第三台 Compute 或升级 T2（$100 更优）：约 6 分钟时资金 $400+，可负担。

源码侧补充：维护费按config.upkeep / 60每秒扣减，tests/sim/economy.test.mjs第 179-187 行验证了该扣减逻辑与STATE.finances.expenses.upkeep记账。此外生存模式还存在degradation（服务健康衰减，src/config.js）、randomEvents（含 3× 维护费 COST_SPIKE、4× 流量 TRAFFIC_BURST 等，src/config.js）等额外经济扰动——文档的静态模型是理想基线，实战预算必须为这些事件留出安全垫。

4. 最优配比分析：EC2:S3:RDS 该几比几

4.1 每 100 请求的流量分布

• S3 方向：30 STATIC + 5 UPLOAD =35 请求
• DB 方向：20 READ + 15 WRITE + 10 SEARCH =45 请求
• WAF 拦截：20 MALICIOUS

4.2 加权负载（processingWeight）

S3: (30 × 0.5) + (5 × 2.0) = 15 + 10 = 25 加权单位 DB: (20 × 1.0) + (15 × 1.5) + (10 × 2.5) = 20 + 22.5 + 25 = 67.5 加权单位

DB 承受的加权负载是 S3 的 2.7 倍——这解释了为何 DB 单节点更贵（$150 vs $25）且升级收益更高。

4.3 各 RPS 下的吞吐需求

4.4 容量分析

• S3：单节点 500 req/s，可支撑 1428 总 RPS——任何现实 RPS 下 1 台 S3 足够；
• DB T1：单节点 26.67 req/s，可支撑 59 总 RPS；7 RPS 时利用率仅 ~12%——极高 RPS 前 1 台 DB T1 足够；
• Compute T1：6.67 req/s，3.3 RPS 时已达 50% 安全上限——最需要频繁扩容的节点。

4.5 最优配比建议

中期（3-7 RPS）"2:1:1"的直觉是正确的，且 Compute 永远先于存储扩容。

5. 升级时机分析：升级还是新建？

5.1 Compute：升级 vs 新建

维护费对比：2× Compute T1 需 $24/min，而 1× Compute T2 仅$12/min（与 T1 相同）。

推荐：升级到 T2 更划算，理由：

1. 维护费与 T1 相同（$12/min）；
2. 计入维护费节省后，每容量美元性价比更高；
3. 省出一个槽位给 ALB 连接。

最优路径：T1 → T2（$100）→ T3（$160）= $320 获得 18 容量；对比 4× T1 = $240 仅 16 容量却要$48/min维护费。

触发时机：有 $100+ 且需突破 3.3 RPS → 升 T2；有 $160+ 且需突破 6.7 RPS → 升 T3。

5.2 Database：升级 vs 新建

推荐：永远升级 DB——第二台 DB 使维护费翻倍，而升级不增加维护费。DB 是维护费最重的节点（$24/min），升级省下的钱远大于差价。

源码侧印证：Compute/DB 的 tier 升级在 src/config.js 的tiers数组中声明，升级成本（$100/$160、$200/$350）与容量（4/10/18、8/20/35）与文档完全一致。维护费按upkeep字段（$12、$24/min）执行。

6. 故障级联分析：50% 阈值为何如此关键

6.1 失败率-有效吞吐对照表

负载 | 失败率 | 成功率 | 有效吞吐 -------|--------|--------|--------- 0-50% | 0% | 100% | 100% 已处理 60% | 20% | 80% | 80% 70% | 40% | 60% | 60% 80% | 60% | 40% | 40% 90% | 80% | 20% | 20% 100% | 100% | 0% | 0%

6.2 有效容量曲线推导

Effective = Load × (1 - FailChance) = Load × (1 - 2×(Load - 0.5)) 当 Load > 0.5 = Load × (2 - 2×Load) = 2×Load - 2×Load² d(Effective)/d(Load) = 2 - 4×Load = 0 → Load = 0.5

最大有效吞吐出现在 50% 负载：

• 50% 负载：50% 容量 × 100% 成功 =最大值的 50%
• 75% 负载：75% 容量 × 50% 成功 =最大值的 37.5%
• 100% 负载：100% 容量 × 0% 成功 =0

6.3 关键发现：50% 阈值非常严苛

• 超过 50% 负载运营在数学上低效；
• 75% 负载的节点表现不如50% 负载；
• 节点在 ~70-75% 负载以上"事实上报废"。

6.4 是否过于严苛？

支持现行曲线的理由：

• 迫使玩家提前规划；
• 制造张力与挑战；
• 奖励主动扩容。

反对的理由：

• 50% 阈值意味着只能安全使用一半容量；
• 陡峭曲线不宽容；
• 玩家可能感觉基础设施"浪费"。

文档提出的缓和曲线候选（未采用，供平衡迭代参考）：

// 现行：从 50% 线性 failChance = 2 × (load - 0.5) // 75% 时 50%，100% 时 100% // 备选：从 60% 指数（更温和） failChance = Math.pow((load - 0.6) / 0.4, 2) // 备选：对数 failChance = load > 0.7 ? Math.log(1 + (load-0.7)*10) / 3 : 0

源码侧印证：失败公式在 src/core/actions.js 原样实现；Service 在每帧调用它并叠加健康衰减惩罚（totalFailChance = min(1, failChance + healthPenalty)，见 src/entities/Service.js）。tests/sim/economy.test.mjs对公式边界值做了断言；tests/sim/beatability.test.mjs等测试也围绕该曲线验证了整体可通关性。

7. 平衡性建议与结论

7.1 参数调整建议

现状备注：从 src/config.js 看，当前源码已实现rpsAcceleration（60s→1.3×、120s→1.6×、180s→2.0×、300s→2.5×、420s→3.0×、600s→4.0×），属于文档"RPS 增长率过慢"建议的后续落地，阅读历史文档时宜结合此机制理解当前节奏。

7.2 核心问题答案汇总

7.3 游戏可否通关？死亡是否必然？

可通关——正确操作路径：

1. 立即搭建 WAF → Compute → S3 → DB；
2. 2-3 分钟时将 Compute 升至 T2；
3. 保持 Compute 负载低于 50%；
4. 仅在需要时升级 DB（贵但扩展性好）；
5. 约 15-20 分钟后，若基础设施跟上节奏，游戏进入"稳态可解"状态。

死亡并非必然——但增速会显著放缓：

配以 3× Compute T3（或 6× T2）+ 1× DB T2，即可无限期维持。

附录：RPS 里程碑表

延伸阅读

• 平衡分析原始文档（Issue #17 产出）
• 服务与流量参数定义（services/trafficTypes/survival配置）
• 失败公式与收支实现（calculateFailChanceBasedOnLoad、getUpkeepMultiplier、spawnRequest）
• 服务负载模型（totalLoad、平滑负载、维护费扣减）
• 请求实体（processingWeight、reward、SLO 映射）
• 经济与失败率测试、可通关性测试、环与告警测试

本文基于 Issue #17《计算游戏平衡数学模型》的完整推导，并以上述源码与测试作为实现级佐证。

• 游戏开发
• 教育