Queue-it 做的是 virtual waiting room（虚拟等候室）——专门在抢购、票务、新品发布这类瞬时高并发场景里，把洪峰流量挡在等候室里、按可控速率放行。这期 Autoscaling in Production: When It Works and When It Doesn’t 的嘉宾是 Queue-it 的 Šimon Bučko（Senior Software Engineer）和 Zaigham Sarfaraz（Engineering Manager），主持人 José Quaresma，主题是生产环境里 autoscaling 有效和失效的边界。

一句结论：autoscaling 是必要条件，不是充分条件#

整期最值得记的一句是 “autoscaling is necessary but not sufficient”。autoscaling 擅长应对线性、渐进的流量增长——监控 CPU、内存、请求数等指标，越过阈值就加实例，load balancer 通过 health check 发现新实例并分流。这套机制对"流量缓慢爬坡"几乎是理想方案。

但它有一个关键前提：扩容本身需要时间。新实例从触发到就绪是分钟级的。一旦流量是瞬时、非线性地砸下来，autoscaling 的反应速度就跟不上了。

那次 iPhone 发布的翻车#

播客里的一个具体例子，是 2023 年一次 iPhone 发布（播客录制时大约三年前）。流量从 0 瞬间冲到上百万请求。他们当时虽然做了一些 vertical 预扩容，但主要还是指望 autoscaling 去接住尖峰——结果新服务器要 3–4 分钟才能初始化完成，对这种瞬时洪峰来说太慢了，终端用户直接看到了报错。

这个故事点出的边界很清楚：autoscaling 隐含"流量随时间平滑变化"的假设，而他们客户的流量曲线根本不平滑——用 Zaigham 的话说，大意是"零，然后瞬间一百万，然后又归零"。用一个为线性增长设计的机制去接非线性尖峰，差的那 3–4 分钟就是事故。

他们的应对：把"可预测"和"不可预测"分开处理#

翻车之后他们发展出一套 pre-scaling（预扩容）流程，核心思路是把流量分成两类：

  • 可预测的大事件（比如已知的票务开售、新品发布）：客户提前把预计的流量量级和时间点告诉 Queue-it，他们据此提前把容量铺好——以 vertical scaling（把机器换得更强）为主，配合有限的 autoscaling，而不是临场再扩。
  • 不可预测的波动：才交给 autoscaling 做兜底。

这个拆分没有否定 autoscaling，而是把它放回它擅长的位置：autoscaling 接渐进波动，预扩容接已知尖峰。

几个容易被忽略的工程前提#

这期还顺带强调了几个"你以为加了 autoscaling 就万事大吉、实际还得管"的前提：

  • 应用得是 stateless 的。horizontal scaling 要求任意实例都能处理任意请求。像 session 这类有状态的东西，如果不外置，用户的请求被打到不同实例就会掉登录态。常规解法是把会话状态放到 Redis 这类外部存储里，让实例本身保持无状态。sticky session 能绕过这个问题，但它会把流量黏在单个实例上，反而制造瓶颈。
  • load balancer 本身也可能是瓶颈。极端流量下 LB 自己也扛不住，云厂商（如 AWS）需要提前 pre-warming。
  • 指标不是只有 CPU / 内存。Simon 反复说 “there is no silver bullet”：指标要匹配应用的真实行为——内存密集型应用就该用内存触发，队列处理型系统更适合用请求数 / 队列长度。阈值得靠压测一个个试出来，不能照搬默认值。

Serverless 也不是银弹#

serverless（Lambda / Azure Functions）常被当成"自动解决扩容"的答案，这期把这个幻想按了下去：

  • serverless 有厂商侧的硬上限，函数会被 throttle，超过阈值后续请求直接被挡；
  • cold start 和 throttling 行为依然要操心，自动化并不等于没有延迟；
  • 而且会带来 vendor lock-in，迁移成本很高。

Zaigham 的说法是：完全押注 serverless，等需求撞上厂商阈值时一样会反噬。结论还是那句——它是工具之一，不是银弹。

成本：autoscaling 既能省钱也能烧钱#

autoscaling 理论上靠"按需供给"省钱，但配置不好会朝两个反方向出问题：扩得太激进会拉起一堆用不上的实例（花冤枉钱），扩得太慢又会宕机、丢服务。到底是省钱还是烧钱，取决于你对流量模式的理解，以及策略配置得是否"聪明"。这点和上面"指标 + 阈值要压测"是一回事——没有免费的自动化。

scalability 的定义#

Simon 给 scalability 下的定义，可以当作这期的收口：

The ability of a system to meet its demand, whether demand increases or decreases.

注意它把"减少"也包含进去了——scale down 同样是 scalability 的一部分，这正好呼应了成本那一节。autoscaling 是实现这个能力的手段之一，但远不是全部。

几点笔记（个人观点）#

这期对我（日常重度依赖 k8s HPA 与 cluster autoscaler）的几条直接映射：

  1. 把流量按"可预测 / 不可预测"分类。 对已知大事件走预扩容——提前拉高 minReplicas、预热节点池，autoscaling 只做兜底，别让它去接已知尖峰。HPA 扩 Pod 还要排队调度、拉镜像、等就绪探针，节点不够还要等 cluster autoscaler / Karpenter 拉新节点（动辄几分钟）；尖峰来的那一刻，这些分钟级延迟都是硬伤。这期把"对已知大促提前预扩"从一个朴素做法上升成了一条清楚的原则。
  2. 压测要常态化，不是上线时压一次就完。系统会随着新数据库、第三方集成、客户增长而演化，autoscaling 的假设也跟着变；要在"你真正需要它工作的那天"之前反复压测、做 chaos testing。
  3. 指标和阈值按工作负载选，别照搬 CPU / 内存默认值。
  4. 别忘了 LB、依赖、第三方也要一起预热 / 评估——autoscaling 只解决了"我自己的实例数量"这一层；LB 需要预热这条之前容易被忽略。
  5. Queue-it 自己的业务就是处理非线性尖峰，所以这期最有价值的地方不是泛泛解释 autoscaling，而是把"扩容动作需要时间"这个常识放回抢购、票务、新品发布这种真实洪峰里看。

参考资料#