技术探索与实践：从考研失败到线上救火，我的资源调度优化之路
去年三月查完成绩那一刻，我盯着电脑屏幕上的“未通过”三个字发了十分钟呆。脑子里只有一个想法：完了，三年备考全白费了，简历上连个硕士学历都没有。但房租不会等我emo，第二天我就把“备战考研”的日程表撕了，开始疯狂投简历。好在本科那会儿没光刷题，还折腾了不少开源项目，加上之前实习的公司愿意收留我这个“落榜生”，总算在六月入职了一家电商中台团队。
现在回头看，考研失败反而让我提前三年进入工业界——这三年里，我从一个只会 console.log 的菜鸟，变成了能在大促前夜淡定改配置的“老油条”。今天这篇总结，就是想聊聊最近半年我在资源调度优化这件事上踩过的坑、熬过的夜，以及那些在技术分享会上被前辈点醒的关键瞬间。
事情的起因：双11前夜的CPU告警
去年双11前两周，运维兄弟突然在群里@所有人：“订单服务集群 CPU 使用率持续飙到 95%+，再不降下来明天大促直接崩！” 我心里一紧——这服务可是我主 R 的，要是挂了，年终奖怕是要变成“负数”。
打开监控一看，好家伙，Pod 的 CPU request 设的是 2 核，limit 是 4 核，但实际使用峰值才 1.8 核。也就是说，我们白白浪费了接近一半的计算资源！更离谱的是，整个集群有 200 多个实例，按云厂商的计费标准，每月光这一项就多烧了十几万。
产品经理还在旁边幽幽补刀：“能不能省点钱？老板说今年要‘精细化运营’……”
我心想：你管这叫运营？这明明是技术债！但吐槽归吐槽，问题得解决。于是，我开始了这场关于资源、效率与生存的探索。
初步尝试：调低 request？Too young！
第一反应很简单：既然实际用不到 2 核，那就把 request 降到 1.5 核呗？结果刚上线，K8s 调度器直接给我表演了个“驱逐秀”——因为节点资源紧张，低 request 的 Pod 被优先 evict（驱逐），服务稳定性反而更差了。
这时候我才意识到：request 不只是资源申请，更是调度权重和 QoS 保障的基石。盲目下调，等于自断经脉。
后来在一次内部技术分享会上，后端架构组的老张提到一句：“你们有没有试过用 VPA（Vertical Pod Autoscaler）？” 我当场愣住——这玩意儿我只在文档里见过，从来没敢在线上用，毕竟“自动调资源”听起来就很玄学。
但死马当活马医吧。反正再这样下去，我可能要在工位上过年了。
深入原理：VPA 真的靠谱吗？
我花了一个周末啃完 VPA 的官方设计文档，又扒了它的源码（主要是 recommender 和 updater 两个组件）。核心逻辑其实不复杂：
- History Processor 收集过去 8 天的资源使用数据（CPU/Memory）
- Admission Controller 在 Pod 创建时注入推荐值
- Updater 负责滚动重启 Pod 应用新配置
但问题来了：VPA 默认会强制重启 Pod！对于我们这种 7x24 小时不间断的订单服务，这意味着每次调整都会引发短暂的服务抖动——用户下单卡一下，客服电话立马爆掉。
怎么办？不能为了省资源牺牲体验啊。
灵光一闪：能不能只让 VPA 推荐，但由我们自己控制何时应用？
于是，我魔改了 VPA 的 updater 组件，加了个开关：autoUpdate: false。这样它只输出建议值，不自动操作。我们可以在凌晨低峰期，配合发布系统手动灰度更新。
apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
name: order-service-vpa
spec:
targetRef:
apiVersion: "apps/v1"
kind: Deployment
name: order-service
updatePolicy:
updateMode: "Off" # 关键！关闭自动更新
resourcePolicy:
containerPolicies:
- containerName: order-app
minAllowed:
cpu: "1"
memory: "1Gi"
maxAllowed:
cpu: "3"
memory: "4Gi"
部署之后，VPA 开始默默收集数据。三天后，它给出的建议是：CPU request 1.2 核，limit 2.5 核；内存 request 1.5Gi，limit 3Gi。
对比我们原来的配置（2C/4G request），CPU 资源可节省 40%，内存节省 25%。
实战落地：从理论到生产
有了数据支撑，我拉上运维和 SRE 开了个小会。一开始他们很警惕：“VPA 这东西我们没在线上用过，万一推荐错了呢？”
我理解他们的顾虑。于是我们定了个分阶段方案：
| 阶段 | 目标 | 风控措施 |
|---|---|---|
| Phase 1 | 灰度 5% 流量 | 手动触发更新，监控 2 小时 |
| Phase 2 | 扩展到 30% | 加入自动回滚条件（错误率 > 0.1%） |
| Phase 3 | 全量上线 | 结合 HPA 做联动调优 |
上线那天是周五晚上 10 点（程序员的黄金时间）。我一边执行 rollout，一边盯着 Grafana 面板。当看到 CPU 使用曲线平稳下降，而错误率始终为 0 时，我长舒一口气——终于不用在双11当天睡机房了。
最终效果？双11当天，订单服务集群稳定扛住 3 倍流量峰值，整体资源成本下降 35%，省下的钱够我们团队吃半年下午茶（虽然老板只批了两顿）。
更深一层：资源 ≠ 成本，而是系统弹性的基石
这次经历让我彻底明白：资源管理不是简单的“省”，而是“精准匹配业务需求”。以前总觉得“多申请点资源保险”，结果造成大量闲置，反而拖累整体调度效率。
后来我又研究了 K8s 的 Resource Quota 和 LimitRange，在命名空间层面做了硬性约束，防止新人乱设 request/limit。还写了个小工具，自动扫描集群里“request 远高于 usage”的服务，每周生成报告发给各 team 负责人——美其名曰“资源健康度体检”，其实就是变相催他们优化（笑）。
另外，运营团队也找上门来：“你们这个省成本的方法，能不能推广到营销活动服务？” 当然可以！但前提是——你们的产品需求别再临时改了！上次大促前一天加个“红包雨”功能，差点把我送走。
技术分享的价值：站在巨人的肩膀上少踩坑
说实话，要不是那场技术分享会，我可能还在手动调配置。公司虽然不大，但每季度都有内部 Tech Talk，鼓励大家讲实战经验。我后来也上去讲了一次《如何用 VPA 优雅省钱》，结果被隔壁组的测试同学提问：“你们考虑过 JVM 内存 Overhead 吗？”
我当场懵了。回去一查，果然！Java 应用的实际内存 = Heap + Metaspace + Direct Buffer + Native Memory…… 而我们只监控了 Heap。如果 VPA 只看容器内存 usage，可能会低估真实需求，导致 OOMKill。
于是我又加了 JVM Native Memory Tracking (NMT)，把 native 内存也纳入监控维度：
# 启动参数加入
-XX:NativeMemoryTracking=summary
# 运行时查看
jcmd <pid> VM.native_memory summary
再结合 cgroup 的 memory.usage_in_bytes，终于得到了更真实的内存画像。
你看，这就是技术分享的魅力——一个人踩的坑，变成一群人的经验。哪怕只是随口一问，也可能帮你避开一场线上事故。
总结：失败是另一种起点
回想起考研失败那天的绝望，现在觉得有点好笑。如果当时上岸了，可能还在实验室调参，而不是在生产环境里真刀真枪地解决资源调度问题。工业界的复杂性，远超任何一道考研题。
这三年，我学会了：
- 资源不是越多越好，而是“刚刚好”最香；
- 运营要懂技术边界，技术也要理解业务目标；
- 技术分享不是秀肌肉，而是共建知识护城河。
最近在看新机会，面试官问我：“你最大的技术亮点是什么？” 我没说微服务、没提高并发，而是讲了这个 VPA 优化的故事。因为真正有价值的，从来不是炫技，而是用合适的技术，解决真实的问题，并让更多人受益。
对了，上周五晚上又加班了——不过这次是因为在搞新的 eBPF 资源追踪方案。听说能实现秒级粒度的 CPU attribution…… 啧，又是熟悉的配方，熟悉的味道。
但没关系，反正我已经习惯了。毕竟，程序员的浪漫，就是在报错日志里寻找星辰大海。
（完）
后记：如果你也在做资源优化，欢迎交流！但别在半夜 2 点钉钉我，除非你请我喝瑞幸。
评论 0