是什么
突发性能实例用“基线性能加积分”的机制压低成本：平时按低于整机的基线上限运行，空闲时积累 CPU 积分，需要时消耗积分把 CPU 拉高。积分耗尽后性能会被限制回基线，表现为响应变慢。它适合平均负载低、偶发突发的场景，不适合长期跑满 CPU 的服务。阿里云的 t 系列与公有云上同类 T 系列实例都属于这个模型。
基本信息
| 运行机制 | 空闲时累积积分，负载高于基线时消耗积分 |
|---|---|
| 积分上限 | 实例规格决定积分上限与每小时累积速度 |
| 性能模式 | 标准模式积分耗尽后受基线限制；无性能约束模式可超额但按量计费 |
| 适合负载 | 低负载长尾服务、开发测试环境、轻量网站 |
| 监控指标 | CPU 积分余额、积分消耗与受限时长，均在云监控可见 |
典型使用场景
- 个人站点与小流量 API 服务，日常 CPU 使用率很低
- 开发与测试环境：白天偶有编译或跑测试，夜间空闲攒积分
- 定时任务型负载：任务间歇执行，间隔期可以累积积分
- 成本敏感但可容忍偶发抖动的内部系统
- 大促或活动前的临时扩容：临时实例用完即释放，配合定时释放控制成本
选型自查清单
选型自查清单
- 平均 CPU 使用率是否长期高于基线值？长期高于基线就不合适
- 积分余额是否频繁归零、监控里是否出现性能受限时长
- 业务高峰是否恰好落在积分已经透支的时段
- 是否选择了无性能约束模式，超额部分的费用是否在预算内
- 关键服务是否有降级准备，积分耗尽时能否保证基本响应关键概念
| 概念 | 含义 | 注意事项 |
|---|---|---|
| 基线性能 | 实例长期可稳定使用的 CPU 水平 | 按规格不同，选型时必须与业务平均负载对比 |
| CPU 积分 | 可消耗的突发额度 | 余额与累积速度随规格变化，不能跨实例转移 |
| 积分透支 | 积分不足后继续跑高负载 | 标准模式会限制性能，表现为延迟上升 |
| 无性能约束模式 | 允许超额使用并按量计费 | 账单可能显著上升，需配合预算告警 |
积分耗尽时的表现是变慢而不是报错，监控上看到的是延迟升高、CPU 受限时长增加；如果不看积分指标，很容易误判成网络抖动或磁盘瓶颈。
把突发实例用于持续高负载的生产服务，会造成长期的性能受限；选型阶段就要拿真实压测数据对比基线，而不是等到上线后才发现。