腾讯云已实名成品号 抢占式实例使用心得

去年冬天，我盯着监控面板上那根突然归零的CPU曲线，手心冒汗——不是服务器挂了，是整整27台抢占式实例，在凌晨3:17分被云厂商‘礼貌但坚决’地回收了。

那一刻，我捧着热茶，茶凉了都没顾上喝一口。不是心疼机器，是心疼刚跑了一半的离线训练任务、没落库的埋点日志、以及那个正在做AB测试、结果一半用户看到页面加载转圈圈的前端同事发来的第7条微信语音：‘哥…咱这‘省钱方案’，是不是省得有点太彻底了？’

后来我们给这批实例起了个代号：‘云上候鸟’——来得快，去得更快，还自带迁徙预警（如果运气好，能提前2分钟收到通知）。

一、别信宣传页上的‘最高节省90%’，先算清楚你到底省了几个亿

我们最初天真地以为：‘买10台按量付费ECS要3.2万/月，换成抢占式只要3200，立省90%！’——直到财务同学拿着账单找上门：‘你漏算了自动续费失败导致的3小时空档期，补了5台按量实例，单价翻倍；还有因为实例反复起停，对象存储请求次数暴涨，OSS费用多出47%；再加上传输加速、镜像缓存重建、冷启动超时重试…最后月省6800，不是3万。’

教训：抢占式不是‘打折券’，是‘带条件的期货合约’。真实节省 = （原成本 - 抢占式成本）- （稳定性补偿成本）。我们后来建了个Excel小模型：输入实例规格、地域、时段、任务类型、重试容忍度，自动算出‘净节省率’。发现深夜批处理任务省82%，但API网关后端省不到40%——因为每秒重连、证书续签、连接池重建的成本，早把折扣吃回去了。

二、别让‘可中断’变成‘不可恢复’：容错不是口号，是代码里的if-else和retry-forever

第一版架构图上写着‘所有服务无状态’，现实啪啪打脸：有个Java服务用本地磁盘缓存了上游接口的Token，失效时间2小时。某次回收后，新实例启动，读不到缓存，疯狂调用认证接口，触发风控限流，整条链路雪崩。

现在我们的‘抢占式生存守则’第一条就是：禁止任何本地持久化，哪怕是一行log。所有临时状态必须落Redis（带TTL）、所有中间结果写OSS（路径带timestamp+uuid）、所有长任务必须支持断点续传——不是靠框架，是靠自己在业务逻辑里埋checkpoint：训练模型每100步存一次权重；数据清洗每1万行记一次offset；视频转码每5秒写一次进度帧。

K8s里我们配了两套策略：对计算密集型Job，用restartPolicy: OnFailure + backoffLimit: 5；对有状态服务（比如Flink Session集群），直接放弃抢占式，改用‘竞价+预留实例组合’——预留实例保底3台，抢占式动态扩到20台，缩容时优先杀抢占式，且缩容前调用Flink REST API触发savepoint。

腾讯云已实名成品号 三、监控不是看CPU，是盯‘死亡倒计时’和‘复活心跳’

云厂商给的2分钟回收预警？我们不信。实测过：37%的实例根本没通知，直接消失；42%的通知延迟超过15秒；只有21%准时送达。于是我们自研了一个‘濒死探测器’：每30秒curl一次云厂商元数据服务http://100.100.100.200/latest/meta-data/spot/instance-action，一旦返回terminate或stop，立刻触发三件事：1）标记该节点为‘即将退役’，拒绝新Pod调度；2）向Prometheus推送一条spot_instance_imminent_termination{instance_id="i-xxx"}指标；3）调用钉钉机器人发消息，标题加🔥emoji，正文带‘剩余预估存活时间：≤97秒’。

更绝的是‘复活心跳’：每个Pod启动时，主动上报pod_restarted_count到监控系统。我们发现，某天凌晨某可用区连续11次重启，平均间隔4分17秒——明显是厂商在滚动维护。立刻切走流量，并邮件投诉。三天后，他们悄悄把那个可用区的抢占式供应调高了30%。

四、别只盯着‘省’，要琢磨‘换’：用弹性换确定性

最值钱的不是钱，是时间。我们曾为赶一个政府项目交付，把所有GPU抢占式实例换成包年包月——结果上线后发现，因缺乏弹性，压测时扩容慢了8分钟，差点误事。后来我们搞了个‘三级弹性’：核心API用包年包月保底；流量洪峰用抢占式+自动伸缩组（ASG）；离线任务全走抢占式，但加了‘智能择时’：爬虫任务避开工作日9-18点（那时回收率飙升）；模型训练固定在凌晨1-5点（回收率最低谷，且电费便宜）。

甚至和运维同学达成默契：每月1号凌晨，所有人手机静音，等云厂商发‘本月抢占式价格走势图’邮件——我们据此调整下月预算和实例分布。他们笑称这是‘云上农民看天吃饭’，我说不对，我们是‘云上气象局+期货交易员’。

五、最后说点掏心窝子的

抢占式实例不是银弹，是双刃剑。它适合：有明确截止时间的离线任务、能容忍部分失败的AI训练、日志聚合、CI/CD构建机、灰度环境。它绝对不适合：支付网关、订单中心、实时风控、用户会话存储——哪怕你加了Redis集群，也扛不住每小时3次实例漂移带来的连接抖动。

我们团队现在的共识是：用抢占式，不是为了‘省钱’，而是为了‘把确定性成本，转化为可管理的不确定性风险’。就像买保险——你付保费不是盼着出事，是为出事时不至于倾家荡产。

所以，下次当你看到控制台里那片绿油油的‘抢占式实例’列表，请别只想着‘哇，好便宜’。停下来，问自己三个问题：

• 我的任务，能在2分钟内优雅退出并保存现场吗？
• 我的下游服务，能承受每小时一次的IP变更和证书重签吗？
• 我的老板，能接受‘这个月省了2万，但有3次线上告警源于实例回收’吗？

如果三个答案都是‘能’，恭喜，你可以放心开干了。如果有一个‘不能’，请先把那台实例，换成包年包月——然后，泡杯茶，等下个月价格更低时，再回来。

毕竟，云不是游乐场，是工地。而真正的工程师，不追求最便宜的砖，只想要砌得最稳的墙。