/tags/scalability/ Recent content in scalability on Hugo -- gohugo.io en Mon, 01 Jun 2026 09:00:00 +0800 /reading/queue-it/autoscaling-in-production/ Mon, 01 Jun 2026 09:00:00 +0800 /reading/queue-it/autoscaling-in-production/ 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（预扩容）流程，核心思路是把流量分成两类：