name: 尺度游戏 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 更小）
- 使用见解早期验证架构