名称: 规模游戏 描述: 在极端条件下测试（1000倍大/小，瞬时/年长）以暴露正常规模下隐藏的基本真理 使用时机: 当不确定可扩展性、边界用例不清晰，或验证生产量的架构时 版本: 1.1.0
规模游戏
概述
在极端规模下测试您的方法，找出什么会破坏，什么会意外幸存。
核心原则: 极端暴露了正常规模下隐藏的基本真理。
快速参考
| 规模维度 | 测试极端 | 揭示了什么 |
|---|---|---|
| 体积 | 1 项 vs 10亿项 | 算法复杂性限制 |
| 速度 | 瞬时 vs 1 年 | 异步需求，缓存需求 |
| 用户 | 1 用户 vs 10亿用户 | 并发问题，资源限制 |
| 持续时间 | 毫秒 vs 年 | 内存泄漏，状态增长 |
| 失败率 | 从不失败 vs 总是失败 | 错误处理充分性 |
流程
- 选择维度 - 什么可能极端变化？
- 测试最小值 - 如果这比正常小1000倍/快1000倍/少1000倍会怎样？
- 测试最大值 - 如果这比正常大1000倍/慢1000倍/多1000倍会怎样？
- 注意什么会破坏 - 哪里出现限制？
- 注意什么会幸存 - 什么是根本上健全的？
示例
示例 1: 错误处理
正常规模: “发生错误时处理错误” 效果良好 在10亿规模: 错误量淹没日志，使系统崩溃 揭示了: 需要使错误不可能（类型系统）或预期错误（混沌工程）
示例 2: 同步API
正常规模: 直接函数调用有效 在全球规模: 网络延迟使同步调用不可用 揭示了: 异步/消息传递成为生存需求，而非优化
示例 3: 内存状态
正常持续时间: 工作数小时/天 在数年: 内存无限制增长，最终崩溃 揭示了: 需要持久化或定期清理，不能依赖内存
需要此技能的红色标志
- “它在开发环境中工作”（但在生产环境中会工作吗？）
- 不知道限制在哪里
- “应该扩展得很好”（没有测试）
- 对生产行为感到惊讶
记住
- 极端揭示了基本真理
- 在一个规模上有效的在另一个规模上会失败
- 测试两个方向（更大 AND 更小）
- 使用洞见来早期验证架构