ECLOUD博客“突发型云服务器”（Burstable Instance，如 AWS T3/T2、阿里云突发性能实例、腾讯云共享型实例等）在高并发请求下通常表现较差，不推荐用于长期或持续的高并发场景。原因如下：
✅ 设计定位不同：
突发型实例是为间歇性、低平均负载但偶有短时峰值的工作负载优化的（例如：开发测试环境、轻量级网站、小型数据库、CI/CD 构建节点）。它通过“CPU 积分（CPU Credits）”机制提供弹性算力，而非持续保障的计算能力。
⚠️ 高并发下的典型问题：
| 问题类型 | 具体表现 | 原因说明 |
|---|---|---|
| CPU 积分耗尽 → 性能骤降 | 请求响应延迟飙升（如 P99 延迟从 50ms 涨至数秒）、超时、服务不可用 | 高并发持续消耗 CPU，积分快速耗尽后，CPU 被限制在基准性能（如 T3.micro 基准仅 10% vCPU），远低于需求 |
| 无资源保障 | 无法承诺 CPU/内存/网络带宽的稳定可用性 | 突发型实例共享物理资源，存在“邻居噪音（noisy neighbor）”风险，高并发时可能受同宿主机其他实例干扰 |
| 自动限频不可控 | 系统内核主动 throttling（如 cpu.cfs_throttled 计数激增），进程被强制暂停 |
Linux CFS 调度器按积分配额限制 CPU 时间，非平滑降级，易引发雪崩式失败 |
| 横向扩展受限 | 单实例扩容能力弱（无法提升基准性能），只能靠增加实例数，但冷启动+注册时间长 | 突发型实例不支持“升配提基线”，突发能力依赖历史积分积累，新实例初始积分少，启动即瓶颈 |
🔍 真实场景对比示例（以 AWS T3.medium 为例）：
- 基准性能：20% vCPU（约 0.4 核持续算力）
- 初始积分：24 分（每分钟赚 0.2 分，满负荷 1 分钟耗 1 分）
- 若突发需 100% CPU 持续 2 分钟 → 需消耗 120 分，但初始仅 24 分 → 2 分钟后即被限频至 20%，后续请求大量排队。
✅ 什么场景才适合？
✔️ 日均 CPU 利用率 < 15%，偶有 1–2 分钟 80%+ 的短时峰值（如定时报表生成）
✔️ 可容忍秒级延迟波动或短暂降级
✔️ 成本极度敏感，且负载可预测、可调度（如夜间批量任务）
✅ 高并发的推荐替代方案：
- ✅ 通用型/计算型实例（如 AWS m6i/c6i、阿里云 g7/c7）：提供稳定、可承诺的 CPU 性能，支持弹性伸缩（ASG/K8s HPA）
- ✅ Serverless（如 AWS Lambda、阿里云函数计算）：自动扩缩容，毫秒级启停，天然适配突发流量
- ✅ 容器化 + 弹性集群（EKS/ACK + Karpenter）：按需调度，资源隔离强，支持细粒度 QoS 控制
📌 一句话总结：
突发型实例 ≠ “应对突发流量的高性能实例”，而是“为低负载省成本、偶尔透支一下”的经济型选择。将它用于高并发生产服务，如同用自行车拉重卡——短期勉强，长期必翻车。
如您有具体业务场景（如 Web API、实时消息、视频转码等），我可帮您分析是否适用及推荐更优架构方案。