name: Scale Game description: 在极端情况下（1000倍变大/变小、瞬时/长达一年）测试，以揭示正常规模下隐藏的根本真相 when_to_use: 当不确定可扩展性、边缘案例不清晰或验证生产环境架构时 version: 1.1.0
规模游戏
概述
在极端规模下测试你的方法，以发现什么会崩溃，什么能意外存活。
核心原则： 极端情况揭示正常规模下隐藏的根本真相。
快速参考
| 规模维度 | 测试极端情况 | 它揭示的内容 |
|---|---|---|
| 数量 | 1项 vs 10亿项 | 算法复杂度限制 |
| 速度 | 瞬时 vs 1年 | 异步需求、缓存需求 |
| 用户 | 1用户 vs 10亿用户 | 并发问题、资源限制 |
| 持续时间 | 毫秒 vs 年 | 内存泄漏、状态增长 |
| 失败率 | 从不失败 vs 总是失败 | 错误处理充分性 |
过程
- 选择维度 - 什么可以极端变化？
- 测试最小值 - 如果这1000倍更小/更快/更少会怎样？
- 测试最大值 - 如果这1000倍更大/更慢/更多会怎样？
- 注意什么崩溃 - 限制出现在哪里？
- 注意什么存活 - 什么是根本稳健的？
例子
例子1：错误处理
正常规模： "当错误发生时处理错误"工作正常 在10亿规模： 错误数量压倒日志记录，导致系统崩溃 揭示： 需要使错误不可能（类型系统）或预期它们（混沌工程）
例子2：同步API
正常规模： 直接函数调用工作 在全局规模： 网络延迟使同步调用不可用 揭示： 异步/消息传递成为生存需求，而非优化
例子3：内存状态
正常持续时间： 工作数小时/数天 在年尺度： 内存无限制增长，最终崩溃 揭示： 需要持久化或定期清理，不能依赖内存
需要此方法的红色标志
- “它在开发中工作”（但它在生产中会工作吗？）
- 不知道限制在哪里
- “应该扩展得好”（未经测试）
- 对生产行为感到惊讶
记住
- 极端情况揭示根本
- 在一个规模工作的东西在另一个规模失败
- 测试两个方向（更大 AND 更小）
- 早期使用见解验证架构