CLOUD云枢阿里云的突发性能型实例（如 t5、t6、g7t 系列等）核心设计逻辑在于“基线性能 + 积分累积与消耗”。这种模式旨在以较低的成本提供基础计算能力，同时在短时高负载场景下允许 CPU 性能突增，非常适合开发测试环境、小型 Web 服务器或低频访问的应用场景。
其工作机制主要围绕 CPU 积分（CPU Credits） 这一概念展开，具体流程如下：
1. 积分的获取（积累阶段）
当实例处于空闲状态或低负载状态时，系统会按照固定的速率向该实例发放 CPU 积分。
- 发放速率：取决于实例规格。例如，某类实例可能每秒生成 20 个积分。
- 上限限制：每个实例都有一个最大积分容量（Credit Balance）。当积分达到上限后，即使实例依然空闲，也不会继续增加积分，防止无限累积。
2. 积分的消耗（运行阶段）
当实例启动并产生 CPU 使用率时，需要消耗积分来维持超出“基线性能”部分的计算能力。
- 基线性能（Baseline Performance）：这是实例在零积分状态下仍能稳定运行的最低 CPU 性能水平。通常表现为一个较低的百分比（如 10%~30%，具体视规格而定）。在此水平以下运行不消耗积分。
- 超配运行：一旦 CPU 使用率超过基线性能，就会开始消耗积分。消耗速率与超出基线的程度成正比。例如，如果 CPU 使用率达到 100%，而基线是 20%，则每分钟消耗的积分远高于仅维持在 25% 时的消耗量。
3. 积分耗尽后的行为（关键机制）
这是用户最关心的部分——当积分余额为 0 时会发生什么？
- 性能受限：实例不会停机，但 CPU 性能会被强制限制在基线性能水平。
- 表现特征：应用响应变慢、任务执行时间显著延长、甚至出现超时错误。此时无法通过重启实例恢复积分，因为重启后仍从当前积分状态（通常为 0）开始，且仍需重新积累。
- 恢复方式：只有当实例再次进入低负载状态，重新积累足够积分后，才能恢复高性能运行。
4. 监控与管理建议
为了保障业务稳定性，建议采取以下措施：
- 开启监控告警：通过 CloudMonitor 设置“CPU 积分余额”低于阈值（如 100 分）时触发告警。
- 合理选型：若业务持续高负载（如长期 >80% CPU），应选择不支持积分机制的标准型或计算型实例，而非突发性能型，否则将面临严重的性能瓶颈。
- 观察趋势：定期分析实例的 CPU 使用曲线和积分变化趋势，判断是否适合继续使用突发性能型实例。
总结
突发性能型实例的本质是一种资源借用模型：你在低负载时“存钱”（积积分），在高负载时“花钱”（用积分）。一旦“存款”归零，系统将自动降级到最低可用性能标准。因此，它适用于间歇性高峰、非持续性高负载的业务场景，而不适用于对 CPU 性能连续性要求极高的生产核心服务。