CLOUD云枢不适合。突发性能实例（Bursting Performance Instances，如 AWS t 系列、阿里云 burst_b 系列等）通常不建议用于长期运行且负载稳定的 Web 服务。
这类实例的设计初衷是应对间歇性或低平均负载的工作场景，其核心机制依赖“CPU 积分”：
- 在空闲时积累 CPU 积分；
- 在需要时消耗积分以突破基础性能限制（突发）。
- 一旦积分耗尽，CPU 性能会被严格限制在基础水平（通常为基线性能的 10%~20%），导致响应延迟甚至服务不可用。
为什么不适合长期运行的 Web 服务？
| 问题类型 | 具体影响 |
|---|---|
| 性能波动 | 用户请求突增时可能因积分耗尽而卡顿，造成用户体验下降或超时错误。 |
| 成本风险 | 为维持稳定性能需频繁扩容或升级，反而比直接选用通用型/计算型实例更贵。 |
| SLA 保障弱 | 多数云厂商对突发实例不提供严格的性能 SLA，难以满足生产环境要求。 |
| 监控复杂 | 需持续监控 CPU 积分余额，增加运维负担。 |
推荐替代方案
✅ 通用型实例（如 m/g 系列）：平衡计算与内存，适合大多数 Web 服务。
✅ 计算优化型实例（如 c/x 系列）：高 CPU 密集型场景（如 API 网关、微服务集群）。
✅ 弹性伸缩组 + 按需/预留实例：结合自动扩缩容策略，兼顾成本与稳定性。
💡 例外情况：仅当您的 Web 服务具有极低且可预测的流量模式（例如内部测试站、夜间批处理触发的前端展示页），且能接受偶尔的性能降级时，才考虑使用突发实例作为临时方案。
建议根据实际 QPS、P99 延迟要求和业务连续性需求，选择匹配的实例类型，必要时通过压测验证性能表现。