阿里云突发性能实例的CPU是如何分配的？

阿里云突发性能实例（Burstable Instances，如 t5、t6、t7 系列）的 CPU 分配机制基于基准性能 + 积分累积与消耗的动态模型。其核心逻辑并非直接分配固定的 vCPU 算力，而是通过“积分”来平衡长期平均性能与短期突发需求。

1. 基础架构：基准性能与积分系统

每个突发性能实例都拥有一个基准 CPU 使用率（通常以 vCPU 为单位，例如 0.2 vCPU 或 0.3 vCPU）。这是实例在长时间运行下能持续维持的平均性能水平。

• 基准性能：无论是否产生积分，实例始终拥有这部分固定的计算能力。例如，一个基准为 0.2 vCPU 的实例，在没有额外积分时，平均每秒只能消耗约 0.2 个 vCPU 的计算资源。
• CPU 积分：当实例的实际 CPU 使用率低于基准性能时，系统会向该实例账户中注入CPU 积分。这些积分代表了“未使用的基准算力”，可以储存起来供未来使用。

2. 动态分配机制：如何触发高负载？

当您的应用需要短时爆发高性能（如处理突发流量、编译代码、运行批处理任务）时，实例可以消耗积分来提升 CPU 使用率，最高可达 100% 的全 vCPU 性能（具体上限取决于实例规格和当前积分状态）。

• 积分积累阶段：
  如果实例当前的 CPU 使用率低于基准线（例如基准是 0.2 vCPU，实际只用到了 0.1），每秒钟会积累相应的积分。积累速度 = (基准性能 – 实际使用率) × 时间。

• 积分消耗阶段：
  当业务需要更高性能时，实例开始消耗已积累的积分。此时，CPU 使用率可以瞬间突破基准限制，最高提升至单核满负荷状态。

  • 消耗速率：消耗积分的速度等于超出基准部分的 CPU 使用量。例如，若基准为 0.2 vCPU，实际使用达到 1.0 vCPU，则每秒消耗 0.8 个积分。

• 积分耗尽后的行为：
  一旦积分池归零，实例将立即被强制降回基准性能运行。此时，即使您尝试启动高负载任务，CPU 使用率也会被限制在基准线以内，导致任务执行变慢甚至超时。只有当使用率再次低于基准线，积分才会重新积累。

3. 不同代际的差异（t5/t6 vs t7）

虽然核心逻辑一致，但不同代际在实现细节上有所优化：

• T5/T6 系列：采用传统的积分累计模式，积分池有上限（通常为 432,000 秒或类似数值，视规格而定），且积分不会随时间自动重置（除非手动购买或升级）。
• T7 系列：引入了更灵活的策略，支持无积分池模式（部分场景下）或更平滑的突发控制。T7 实例通常提供更高的基准性能比例，并且积分积累和消耗的算法更加精细，减少了“突然断崖式降级”的体验，更适合对稳定性要求稍高的突发场景。

总结

阿里云突发性能实例的 CPU 分配本质上是一种“先存后取”的信用机制：

1. 平时：以较低的基准性能运行，节省下来的算力转化为积分。
2. 突发时：利用积分兑换临时的高性能（最高 100% 全核）。
3. 积分耗尽后：自动回落到基准性能，直到积分再次积累。

这种设计使得用户能够以较低的成本获得偶尔的高性能处理能力，非常适合开发测试环境、小型 Web 服务器或具有明显波峰波谷特征的业务场景。建议监控实例的 CPU 积分余额，避免因积分耗尽导致服务性能骤降。