弹性伸缩:被云厂商吹了十年的“万能解药”,为什么还有一半企业用不明白?

上周帮一个做电商的朋友复盘618的故障。 他说去年大促提前3周按预估峰值备了3倍的服务器,结果当天实际流量只到预估的7成,光闲置的云资源就花了12万。更气人的是,零点那10分钟还是崩了——弹性伸缩的阈值设错了,等CPU爬过80%的线再启动新实例,机器刚完成健康检查,早高峰的用户已经退出去刷竞品的直播间了。 说实话,刚入行的时候我也把弹性伸缩当云时代的终极生产力。不用提前囤机器,流量来了自动加,流量走了自动放,成本直接砍半。踩了三年坑才发现,这东西的边界比宣传册上窄太多。

别被“自动扩缩容”的宣传骗了:弹性伸缩的真实技术边界

它不是魔法。 本质上就是一套嵌在云资源调度层的规则引擎,你得提前把“什么时候扩、扩多少、什么时候缩、缩到什么程度、新启动的实例要加载哪些配置、接进来的流量怎么分流”这些所有变量全给它定死,它才会按照你写的剧本走,半分人情都不讲。你写的规则错了,它能给你捅天大的娄子。
云平台弹性伸缩触发阈值配置界面截图
云平台弹性伸缩触发阈值配置界面截图
现在很多云厂商的宣传把弹性伸缩吹成了能应对所有突发流量的万能工具,真用起来才会发现,它的能力边界清晰得很。 第一个绕不开的边界是扩容延迟。哪怕是官方标注的“秒级扩容”,那也只是虚拟机或者容器实例从镜像仓库拉取完成的时间,你还要等应用进程启动、数据库连接池建立、本地缓存预热、负载均衡的健康检查通过,整个流程快则30秒,慢则两三分钟。这种延迟根本扛不住“流量1分钟翻10倍”的极端场景——比如突然上了热搜的小商家,或者直播抽奖环节的瞬时峰值,等扩容完成,流量峰值早就过去了。 第二个边界是缩容的坑比扩容大得多。很多团队只想着靠缩容压成本,把缩容阈值设得极低,结果流量稍微回落一点,系统就把正在处理用户请求的实例直接踢掉,用户那边直接卡转圈。这种故障我见过不下十次,本质上是没搞懂:弹性伸缩的核心是“不影响业务”,不是“把成本压到最低”。 第三个边界是状态类应用根本没法直接套用。你总不能把存着用户登录态、正在跑订单结算的内存数据库,随便加机器减机器吧?现在很多团队的弹性伸缩只做了无状态的应用层,后面的有状态组件全是固定容量,看起来前面弹性拉满,其实整个系统的瓶颈还卡在后面的数据库、缓存上,扩容加再多应用实例也没用。

从“凑数功能”到“生产刚需”:这十年弹性伸缩到底进化到哪一步了

最早的弹性伸缩是什么样?2010年AWS刚推出Auto Scaling的时候,功能简陋到离谱——只能按CPU利用率的固定阈值调容量,规则写死,根本没法匹配业务的真实波峰波谷。那时候这功能就是个凑数的卖点,没几个企业敢真的在生产环境用。 真正的拐点是2018年前后。国内云厂商开始推预测式弹性能力,拿过去3个月的历史流量数据训练轻量模型,提前预判接下来1小时的流量变化,在峰值来之前就把资源备好,不用等CPU爬过阈值再反应。某头部电商的技术团队算过,用了预测式弹性之后,大促当天的扩容提前量从10分钟缩到了15秒,因为弹性伸缩配置错误导致的故障直接少了7成。
预测式弹性伸缩的流量曲线与资源容量匹配示意图
预测式弹性伸缩的流量曲线与资源容量匹配示意图
到现在,弹性伸缩的覆盖范围早就不止虚拟机了。从K8s集群里的水平Pod自动伸缩,到函数计算的事件驱动弹性,甚至连GPU资源都能做动态调整。之前接触过一个做AI智能客服的团队,为了应对白天的咨询高峰,之前要备一堆闲置的GPU服务器,晚上没流量的时候全空着,GPU利用率常年不到20%。现在用GPU弹性伸缩能力,白天咨询高峰自动把GPU实例拉到匹配容量,晚上自动缩到只够跑离线模型训练的规模,一年算下来能省大几百万的硬件成本。 不过话说回来,现在市面上吹的“全栈弹性”,大部分还是半吊子。我见过太多团队,前面的应用入口做了弹性,后面的数据库连接池没做动态限制,结果扩容加了100台应用实例,数据库直接因为连接数打满崩了,前面的弹性操作全是无用功。说白了,现在的弹性伸缩还停留在“单组件自动调整”的阶段,离真正的全链路协同还差得远。

别把弹性伸缩当纯成本工具:它正在改写整个云资源的定价逻辑

之前大家买云资源的逻辑很简单:包年包月买固定容量,剩下的突发流量用按量付费补,本质还是静态的资源采购思路。现在弹性伸缩成熟之后,整个云资源的定价体系都在变。 现在主流的云厂商都在推“预留实例兜底+弹性按量补位”的混合模式:你日常稳定的流量需求,就买折扣力度大的预留实例,把基础成本压到最低;剩下的波动流量部分,全靠弹性伸缩动态调整容量,不用提前预留。算下来整体的云成本,比之前固定买峰值容量要低40%左右。 这种模式落地之后,很多之前算不过账的场景都跑通了。比如做在线教育的团队,白天上课的时候流量是平时的5倍,晚上十点之后流量直接掉90%,靠弹性伸缩白天自动把实例拉到能承载直播的容量,晚上自动缩到只够跑消息推送的规模,每个月的云成本直接砍了60%。还有做独立游戏的小团队,新服开服的前3天流量是平时的5倍,之后慢慢回落到稳定水平,根本不用一开始就按峰值买机器,跟着流量弹性调整就行。 但这里面藏着一个很多人不愿意提的风险。 去年有个做社区团购的团队,为了压成本,把弹性伸缩的缩容阈值设到了CPU5%,结果某天下午系统跑批把CPU拉到了6%,系统误以为流量暴涨,一下子自动扩了200台实例,等运维人员发现的时候已经跑了3个小时,光超支的账单就有20万。还有更隐蔽的问题:很多企业把弹性伸缩的容量阈值设到了刚好能承载90%的日常流量,稍微有点波动就出现卡顿,本质上是把资源不足的风险,从“固定成本”转嫁给了用户的体验。毕竟用户不会管你是不是为了省成本才少留资源,卡了就是卡了,下次就不用你的产品了,对吧? 聊点实在的,未来3到5年弹性伸缩的走向,其实不用看厂商的发布会,从现在的技术落地节奏就能猜个大概。 第一,3年内弹性伸缩的核心竞争会从“单组件扩容速度”,转到“跨资源类型的协同能力”。现在的弹性伸缩都是各管各的,应用是应用的,数据库是数据库的,缓存是缓存的,以后能做到流量上涨的时候,应用自动加实例,数据库连接池自动扩容,缓存容量自动补,CDN带宽自动提,全链路跟着流量动态匹配,不用人写几十条复杂的规则。 第二,5年内GPU弹性伸缩会成为整个AI产业链的成本拐点。现在AI应用的推理成本居高不下,核心原因就是GPU资源的利用率太低,大部分团队为了应对高峰,备了一堆闲置的GPU。等GPU的弹性伸缩能力成熟了,整个AI推理的成本能降70%以上,很多之前算不过账的应用,比如实时的AI视频剪辑、实时的数字人客服,就能真正落地到普通用户的日常场景里。 第三,别指望弹性伸缩能做到100%无人值守。不管技术怎么进化,只要是人写的规则,就会有出错的可能。未来的弹性伸缩系统一定会内置人工兜底的机制,比如连续扩容超过预设上限的时候自动触发告警,让运维人员介入,不会再出现那种一下子超几十万账单的乌龙。 上周那个电商朋友现在改了规则。 扩容阈值从80%降到了40%,缩容的时候加了30分钟的优雅等待期,还设了个单月账单超支的告警线。 他说之前总觉得弹性伸缩是帮他省钱的,现在才明白,这东西本质是帮他把之前“靠人盯资源”的活儿,换成了“靠规则盯资源”。 省不省钱是其次,别再半夜被告警喊起来改配置就行。

作者|大讲堂

排版|大讲堂

审核|小准

免责声明:市场有风险,选择需谨慎!此文仅供参考,不作买卖依据。如有侵权请联系删除。
文章名称:弹性伸缩:被云厂商吹了十年的“万能解药”,为什么还有一半企业用不明白?
文章链接:https://lfdjt.com/info_23_28544.html