第 4 章 · 多台服务器第 5 页,共 5 页
人多时加机器、人少时减机器,能自动完成吗?
按高峰备的机器,大半天都闲着。台数能不能跟着访问量自动增减?突然涌来的人,新机器来得及接住吗?
为什么需要
第 1 页算过:按平均算,百家菜 2 台就够;按晚饭高峰留了余量,要 6 台。一整天开着 6 台,夜里大部分闲着,照样要付钱;只开 2 台,晚饭前就。让站长每天守着加加减减,又慢又容易出错。
(autoscaling)就是按访问量自动增加或减少机器的台数:人多时多开几台,人少时关掉一些。第 2 章讲过,上的机器用多少付多少,关掉就不再付钱,所以这样做能省钱。
怎样做
它按一套事先定好的(scaling policy)来增减。下图用的规则是:
- 每分钟看一次全组的平均:超过 70% 加一台,低于 30% 减一台,最少留 2 台,坏了一台还有一台。
- 新机器要开机、装好程序、通过,才能接请求,这里假设要 2 分钟;它准备好以前,不再加下一台。
- 减一台时,先让不再给它分新请求,等它手上的请求做完,再关机;直接关掉,正在处理的请求就失败了。
关掉哪一台都不能把读者退出登录,所以这样增减要求服务器是的(第 3 页)。下图是百家菜的一天:每天 17:30,百家菜给订阅的读者发一条「今晚做什么菜」的提醒,两分钟里涌来很多人。这一天平均每秒约 69 个请求,最忙时约 208 个,与第 1 页估出的数相同。
跟着曲线增减:百家菜的一天
先看这里先直接看全天:这是一直开着 6 台的一天;再换成「按负载自动增减」,看台数怎样跟着曲线走,放大图里 17:30 那一段为什么变红;最后换成「再按时间提前加机器」。
自动扩缩容的示意图:横轴是一天的时间,纵轴是每秒请求数。实线是访问量,阶梯线是能接请求的服务器加起来的容量,虚线把还在启动的也算上;访问量高过容量的地方涂成红色。下面一张把 17:15 到 18:00 放大。具体的台数写在图下的读数和变化清单里。
全天:0:00 到 24:00
播放到 17:15 以后,这里放大显示 17:15 到 18:00。
此刻的服务器
- 服务器甲关着
- 服务器乙关着
- 服务器丙关着
- 服务器丁关着
- 服务器戊关着
- 服务器己关着
格子里的条是此刻的平均:绿色有空,橙色超过七成,红色满了。
还没开始。按「下一步」半小时半小时地看,也可以直接看全天。
台数的变化(到此刻为止)
到此刻为止,台数没有变过。
一天的曲线、规则里的数和 2 分钟的启动时间都是演示值。容量不够时,每秒处理完的约等于容量,多出来的失败。平均台数把启动中的也算在内,它们同样要付钱。
按负载增减以后,夜里只开 2 台,晚饭前后开到 6 台,这一天平均只开着约 3.3 台(推算)。可 17:30 那一阵来得太急:负载超过 70% 才去开新机器,新机器要 2 分钟才准备好,又是一台接一台地加,这几分钟里请求比容量多,多出来的就失败了。
能预见的高峰,可以提前加机器。17:30 的提醒天天都发,规则里就多写一条「17:20 先开到 6 台」,提醒发出时,机器已经等在那里了。云服务也提供按时间表,或者按过去几周的规律提前开机的功能。预见不到的高峰,就只能靠平时多留一些。
代价是什么
自动扩缩容省钱,但反应总是慢半拍:负载要先涨上去,规则才发现;新机器还要时间准备。规则也不能太灵敏,否则台数来回跳,刚减完又要加。出大事时,新机器还可能根本开不起来:2025 年 10 月 20 日 AWS 的那次故障里,新机器的启动从美国太平洋时间凌晨 2:25 到上午 10:36 一直失败。
这一章的做法,是让几台电脑靠网络配合、在用户看来像一个整体,这样的系统叫(distributed system)。它能做到一台做不到的规模,坏了一台还有别的;出错的方式也多了,负载均衡器、这些新加的组件,自己也要可靠。
回顾:多台服务器这一章
- 要几台:从每天的人数、每人的请求数和高峰倍数算出高峰时每秒的请求数,除以一台的容量,再留出余量(第 1 页)。
- 请求交给谁:负载均衡器站在服务器前面分请求;轮流分配和按用户算号不看忙闲,交给手上活最少的一台会少分给慢的那台(第 2 页)。
- 为什么被退出登录:会话只记在一台上,换一台就认不出你;放进会话存储,服务器无状态,哪一台都认得出你(第 3 页)。
- 坏了一台:健康检查连续几次没通过,就把它移出名单;发现之前送到它那里的请求照样失败(第 4 页)。
- 自动加减:按规则跟着负载增减台数;新机器要时间准备,能预见的高峰就提前加机器(第 5 页)。
每天下班的时候,许多人在差不多同一时刻打开地图导航,App 照样很快给出路线。你看不到另一端,但按这一章的画法,那里多半是一大群服务器在一起分担:负载均衡器把请求分开,坏了的那台被检查出来、移出名单,人多的时候还会多开几台。
资料来源
以下资料均于 2026-10-22 至 2026-10-23 访问。
- Target tracking scaling policies for Amazon EC2 Auto Scaling
- Horizontal Pod Autoscaling
- Connection draining
- Edit target group attributes for your Application Load Balancer
- The Twelve-Factor App: VI. Processes
- Autoscaling groups of instances
- Predictive scaling for Amazon EC2 Auto Scaling
- Summary of the Amazon DynamoDB Service Disruption in the Northern Virginia (US-EAST-1) Region
- What is Distributed Computing?