云盘从“机械”到“全闪”，背后到底换了什么底牌

在腾讯云的一个群里，产品提提了一句：

“早期高性能云盘之所以快，是因为底层加了SSD做缓存。后来SSD价格下来了，产品线才慢慢变成现在的全闪存。”

这句话听着平常，但细细一想，其实把过去十年云计算底层存储的演变路径，说得明明白白。

当年为什么非要“HDD + SSD缓存”？

2015年前后企业刚开始大规模上云，大部分架构师对存储的认知还停留在“容量够用就行”。那时候云厂商最基础的就是机械硬盘（HDD）云盘，成本低、容量大，但随机读写IOPS通常只有几百，延迟动不动就十几毫秒。跑个静态网站、存备份日志完全没问题，可一旦挂上MySQL或者业务系统，查询卡顿、连接池爆满就成了家常便饭。

怎么破局？当时的技术路线很务实：底层继续用HDD保底容量，但在控制层叠一层SSD做缓存。读写频繁的数据自动预热留在SSD里，冷数据沉降回机械盘。这套“混合加速”方案当时非常有效，IOPS直接翻了几倍，延迟压到两三毫秒。业内后来管它叫“高效云盘”或“混合盘”，本质是用架构换性能，属于那个年代的性价比最优解。

但混合架构始终有个隐忧：数据在HDD和SSD之间频繁搬运，本身就有延迟和一致性开销；存储控制层越复杂，故障排查越麻烦。很多团队后期为了压延迟，不得不手动做数据热区规划，运维成本反而上去了。

成本曲线下来的那一刻，产品逻辑变了

转机出现在SSD价格断崖式下跌。2018年前后，随着3D NAND堆叠技术成熟和产能放开，企业级SSD的单价终于降到了当年“混合方案”的边际区间。云厂商算了一笔很现实的账：既然全闪的硬件成本已经追平，为什么不直接上纯SSD/NVMe架构？

去掉缓存分层后，IO路径变短，调度逻辑变简单，延迟更稳定，排错也更干净。于是产品线开始转向“全闪存”，控制台里的命名也从“高效”“增强型”变成了直白的“SSD云盘”“极速型”。这不是营销话术，而是底层架构已经能稳定支撑高并发业务，没必要再用混合方案做技术妥协。

为什么后来都不强调“介质”了？

细心的同学会发现，现在去各大云厂商控制台选盘，基本都按IOPS或延迟分级，而不是再纠结底层是机械还是固态。这不是说SSD不重要了，而是介质已经成了行业标配。

全闪云盘现在也被拆成了PL1/PL2/PL3，或者按场景打包（数据库专享、高吞吐、通用型）。命名从“用了什么材料”变成了“能扛多大负载”。背后的逻辑很直接：客户不再需要自己懂存储分层调度，只需要知道自己跑什么业务、要多少性能SLA。当技术足够成熟，产品就该退后一步，把复杂度交给平台，把选择权还给业务。

感慨万千

回看这几年的演进，技术路线永远跟着成本曲线和业务诉求走。早期用SSD缓存是妥协，现在上全闪是顺势。如果你在负责上云或重构存储架构，有几个经验可以避坑：

• 别迷信“全闪一定快”。关键看集群调度协议和网络架构。早期没做并发优化和预读策略的全闪存，延迟波动可能反而不如调优好的混合盘。
• 数据库上云，盯紧P99延迟。IOPS峰值再高，如果尾部延迟偶尔飙到几十毫秒，业务层照样会超时。优先选支持NVMe直连和本地缓存的盘型。
• 成本优化别只堆高性能块盘。很多场景适合“块存储+对象存储”混合架构：热数据走全闪，日志/备份走低频存储，整体TCO能降一大截。

备注：本文75%内容由AI完成

存储介质的迭代从来不是单纯的技术升级，而是云计算走向成熟的过程中，一次又一次在性能、成本和复杂度之间的重新平衡。下次在控制台勾选云盘规格时，不妨多看两眼背后的SLA定义。那些冷冰冰的参数，其实就是过去十年架构师们在机房里熬出来的经验。