CLOUD技术笔记在阿里云 ECS 实例中，共享型（如 t5、t6）与计算型（如 c7、c8）在 CPU 资源分配机制上存在本质区别，主要体现在CPU 性能基线、资源独占性以及适用场景三个方面：
1. 核心机制差异
| 特性 | 共享型 (Shared) | 计算型 (Compute-Optimized) |
|---|---|---|
| CPU 分配模式 | 共享突发模式 多个用户共享同一物理 CPU 核心。当实例负载较低时，可借用未使用的 CPU 周期；当负载较高或需要持续高算力时，会受限于“性能基线”。 |
独享专属模式 每个 vCPU 对应一个或多个物理 CPU 核心（通常采用超线程技术优化），资源被该实例独占，不与其他实例争抢。 |
| 性能基线 | 有基线限制 默认提供一定的基准性能（如 20% 或更高，取决于具体规格）。若需超过此基线，需消耗积分（Burstable）。一旦积分耗尽，CPU 频率会被强制降回基线水平，导致性能骤降。 |
无基线限制 提供 100% 的持续 CPU 性能。无论负载高低，都能稳定输出标称的算力，不会出现因积分耗尽导致的降频。 |
| 资源隔离性 | 弱隔离 在同一宿主机上的其他实例若出现“邻居噪声”（占用大量 CPU），可能会轻微影响你的实例性能。 |
强隔离 通过硬件级或虚拟化层深度隔离，确保计算资源完全独立，不受同宿主机其他实例干扰。 |
2. 具体表现场景
-
共享型实例：
- 平时状态：如果业务是轻负载（如开发测试环境、小型网站、低流量应用），CPU 使用率长期低于基线，实例可以免费获得额外的突发算力，体验流畅。
- 高负载状态：一旦业务进入高峰期（如促销活动、数据处理），需要长时间满负荷运行，共享型实例会迅速耗尽突发积分，CPU 频率被锁定在基线（例如从 3.0GHz 降至 0.6GHz），导致响应变慢甚至超时。
-
计算型实例：
- 全时段状态：无论是空闲还是满载，CPU 都能保持最高频率运行。
- 适用场景：适合对稳定性要求极高、需要持续高性能的计算任务，如视频转码、科学计算、大型数据库、游戏服务器等。
3. 选型建议
- 选择共享型：如果你的业务具有明显的波峰波谷特征，且大部分时间处于低负载状态（例如个人博客、开发测试机、内部管理系统），共享型能以更低的成本满足需求。
- 选择计算型：如果你的业务需要持续稳定的高算力，或者无法容忍 CPU 性能波动（例如核心交易系统、实时渲染、高频交易），必须选择计算型以确保 SLA（服务等级协议）和用户体验。
总结：共享型是“有余力时多给，没积分时保底”，适合弹性业务；计算型是“始终满血，绝不掉链子”，适合关键业务。
