云计算极致弹性的骗局

一句话总结

云厂商卖的是”随时扩容、秒级弹性”，实际交付的是”库存看运气、升配等半天、换代要验证、出了问题没人兜底”。

今天发生了什么

我们的内部某个系统需要紧急扩容。业务处于重保状态，绝对不能出问题。

结果呢？在阿里云上升配一台 ECS，花了超过 5 个小时，到现在还没搞定。

原因：

• 7 代机库存不足，扩不上去
• 9 代机有库存，但不让从 7 代直接升——AMD/Intel 架构差异、机器代数差异等”稳定性考量”不允许跨代升配
• 资源明明有，但就是用不上

这就是云厂商口中的”极致弹性”。

弹性的真相：一张限制清单

云厂商的宣传：需要资源？点一下，秒级到位。

实际情况：

你以为的	实际的
随时扩容	老代际没库存，扩不动
秒级弹性	升配排队 5 小时起步
按需付费	想用新代际？先全量迁移+验证
免运维	云厂商改默认参数不通知你，出了问题你自己查

升级坑死你的案例：https://plantegg.github.io/2026/04/15/AWS-HikariCP-%E8%BF%9E%E6%8E%A5%E8%B6%85%E6%97%B6%E6%A0%B9%E5%9B%A0%E5%88%86%E6%9E%90/

更讽刺的是——今天有库存不代表明天有。库存是动态的，哪天一个大客户扫一波资源，你原来能扩的机型就扩不动了。

换代验证：花钱替云厂商做测试

云厂商每隔两三年推出新一代实例。旧代际的库存会逐渐减少。为了保证未来能弹性扩容，你就得主动迁移到新代际。

迁移意味着什么？

1. 新旧代际的默认参数可能不一致
2. 你要停下业务开发，专门去做兼容性验证
3. 验证过了，也不能保证不漏——因为有些差异只在特定场景才暴露

这不是假设，是真实踩过的坑：

AWS 第 8 代 EC2 实例（2025 年 9 月上线），把 ENI 安全组的连接跟踪超时从 5 天（432000 秒）悄悄改成了 350 秒。没有独立公告，没有迁移指南，甚至 API 在 6 个月后才开始返回这个参数：https://plantegg.github.io/2026/04/15/AWS-HikariCP-%E8%BF%9E%E6%8E%A5%E8%B6%85%E6%97%B6%E6%A0%B9%E5%9B%A0%E5%88%86%E6%9E%90/

后果：所有跨网络的长连接（数据库、消息队列、RPC），只要空闲超过 350 秒，就会被安全组静默丢弃——不发 RST，不通知任何一方。应用端看到的就是”莫名超时”。我们的 Java 服务迁移到 AWS 8 代实例后，HikariCP 连接池每隔 20 分钟就批量报错。

排查花了多久？ 从开 case 到定位根因，19 小时。AWS 自己的支持工程师都要开两轮会议才找到原因。而 AWS 确认，已有 6 家大型企业、10 余个支持案例报告了同一问题——实际受影响的用户远不止这些，因为”静默丢包”根本不会产生明确的错误信号。

这就是你要做的”换代验证”——替云厂商测试他们自己都没文档化的行为变更。

自建机房为什么不需要这种验证

“买新物理机不也要验证吗？”——不需要，或者说简单到可以忽略。

原因很直接：

物理机是干净的。 一台戴尔/联想的服务器，装完 OS 就能用。服务器厂商在出厂前已经做过 OS 兼容性测试。你的业务直接跑在裸金属上，中间没有任何隐藏层。

ECS/EC2 不是干净的。 云厂商在你的 VM 和物理硬件之间塞了一堆自己的服务：

你以为的结构：          实际的结构：

┌─────────────┐        ┌─────────────┐
│   你的应用   │        │   你的应用   │
├─────────────┤        ├─────────────┤
│     OS      │        │     OS      │
├─────────────┤        ├─────────────┤
│   硬件      │        │  虚拟化层    │  ← 你看不到、控制不了
└─────────────┘        ├─────────────┤
                       │  ENI 连接跟踪│  ← 默认参数随代际变
                       ├─────────────┤
                       │  云盘 IO 调度│  ← 性能特征随代际变
                       ├─────────────┤
                       │  管控面代理  │  ← 占 CPU/内存
                       ├─────────────┤
                       │  Nitro/神龙卡│  ← 固件行为不透明
                       ├─────────────┤
                       │   物理硬件   │
                       └─────────────┘

每换一代实例，这些隐藏层的行为都可能变化。而且云厂商不会事先告诉你变了什么——因为这些是他们的”内部实现细节”。

物理机换代： 装 OS → 简单压测 → 上线。一个运维花半天搞定。不需要惊动业务研发。

ECS 换代： 申请新代际实例 → 部署全套应用 → 回归测试 → 性能对比 → 连接行为验证 → 灰度切流 → 观察一周。一个团队花两周，业务研发全部停下来配合。

你花钱买了”弹性”，结果每两年要停下来做一次全量迁移验证。这不是弹性，这是供着一个祖宗。

库存问题无解

有人说：”跟云厂商提前报备，让他们预留库存。”

想想这意味着什么：

• 你要提前规划未来的扩容需求（那还要弹性干什么？）
• 你要信任云厂商的库存承诺（今天有库存明天就没了）
• 你要绑定特定代际（否则哪天被迫换代又要全量验证）

按需、弹性、免规划——卖点一个都兑现不了。

结论

云计算的”极致弹性”是一个营销概念，不是工程事实。

真实的云计算体验是：

• 扩容要看库存脸色——紧急时刻扩不动
• 换代要做全量验证——业务研发替云厂商测试
• 默认参数会变——不通知、不文档化、出了问题你自己查
• 中间层行为不透明——静默丢包连错误信号都没有

如果你的业务对可用性有要求，在做架构决策时，请把这些成本算进去。不要被”秒级弹性”的 PPT 忽悠了。

5 个小时了，我只是想给一台 ECS 加点配置而已。