云小栈云服务器中的突发性能实例（Burstable Instances），通常指的是如阿里云的 t5/t6/ecs.t 系列、AWS 的 t2/t3/t4g 系列等。这类实例的核心特点是：基础 CPU 性能较低，但可以通过“积分”机制在需要时爆发到更高的 CPU 性能。
其积分机制的工作原理可以概括为以下几个关键部分：
1. 什么是 CPU 积分？
- CPU 积分是衡量突发性能实例 CPU 超额使用能力的虚拟货币。
- 当实例处于低负载状态时，它会赚取积分；
- 当实例需要高 CPU 性能（超过基准性能）时，它会消耗积分。
2. 积分如何赚取？（Earn Credits）
- 基准性能（Baseline Performance）：每个突发性能实例都有一个固定的基准 CPU 使用率上限（例如 10%、20%、30% 等，取决于实例规格）。
- 赚取规则：
- 当实际 CPU 使用率 低于 基准性能时，实例会按差值比例赚取积分。
- 例如：基准性能为 10%，当前 CPU 使用率为 5%，则每秒可赚取相当于 5% CPU 性能的积分。
- 积分有最大存储上限（Credit Balance Cap），达到上限后不再继续赚取。
✅ 举例：
实例基准为 10%，最大积分为 14400（约等于 4 小时满负荷运行）。
如果 CPU 长期空闲，积分会逐渐累积至最大值。
3. 积分如何消耗？（Consume Credits）
- 当 CPU 使用率 超过基准性能 时，实例开始消耗积分以维持高性能。
- 消耗速率 = 实际 CPU 使用率 − 基准性能。
- 例如：基准为 10%，当前使用 50%，则每秒消耗 40% 对应的积分。
⚠️ 注意：
如果积分耗尽，实例将被限制回基准性能，即使业务需求很高也无法突破，可能导致应用响应变慢或超时。
4. 初始积分与重置策略
- 新创建的实例：通常会赠送一定数量的初始积分（如 14400 分），以便启动初期有足够的突发能力。
- 积分不会跨周期清零：只要实例不停止，积分会持续累积（直到上限）或消耗。
- 停止实例：积分不会丢失，重启后仍保留剩余积分。
5. 监控与告警
- 云平台提供详细的监控指标：
CPUUtilization：当前 CPU 使用率CPUCreditBalance：剩余积分CPUCreditUsage：已消耗积分CPUCreditConsumptionMode：当前是否在使用积分
- 建议设置告警：当
CPUCreditBalance低于阈值时通知用户，避免性能骤降。
6. 适用场景 vs 不适用场景
| 场景 | 是否推荐 |
|---|---|
| Web 服务器、开发测试环境、低频访问应用 | ✅ 推荐（成本低，偶尔高峰可用积分应对） |
| 数据库、高频交易、持续高负载应用 | ❌ 不推荐（积分易耗尽，导致性能不稳定） |
| 批量处理、周期性峰值任务 | ✅ 推荐（平时低负载攒积分，高峰期爆发） |
7. 如何避免积分耗尽？
- 合理选择实例规格：根据业务模型选择基准性能合适的型号。
- 监控积分余额：设置自动告警。
- 升级实例类型：如果频繁耗尽积分，考虑升级为通用型或计算型实例。
- 优化应用性能：减少不必要的 CPU 开销，延长低负载时间以积累积分。
- 启用“无限制模式”（Unlimited Mode，如 AWS t3 实例）：允许积分耗尽后仍以较高性能运行，但会产生额外费用。
总结
突发性能实例的积分机制是一种成本与性能的平衡设计：
- 平时省积分 → 高峰用积分
- 适合波动性 workload
- 不适合持续高负载场景
理解并监控积分状态，是高效使用此类实例的关键。
