Google Cloud Autoscaling 怎么工作，什么时候应该让虚拟机自动增加实例

一台服务器什么时候应该增加第二台、第三台甚至几十台服务器？在传统机房里，这通常意味着管理员提前购买硬件、安装系统、配置应用，然后等待流量到来。云计算改变了这个逻辑。Google Cloud 的 Autoscaling 可以根据工作负载变化，自动调整虚拟机实例数量，让计算资源随着业务需求增加或者减少。

但自动扩容并不是简单的“CPU超过75%，马上开一台新机器”。如果把Autoscaling理解成一个只看CPU温度的自动开关，很容易在实际部署中产生错误配置。

Google Cloud Compute Engine中的自动扩展主要建立在Managed Instance Group，也就是MIG之上。MIG可以把一组配置一致的虚拟机作为一个整体管理，而Autoscaler则根据预先设定的扩展策略决定这个实例组应该维持多大规模。负载增加时扩容，需求下降时缩容。

最容易理解的方式，是把Autoscaler想象成一个不断回答问题的控制系统：按照现在的负载，这个实例组还够不够用？

最常见的信号是CPU利用率。

假设一个MIG设置目标CPU利用率为60%。随着用户请求增加，实例组平均CPU利用率不断高于目标值，Autoscaler可能增加实例，让更多VM分担工作。反过来，当负载长期下降，实例数量又可能减少。

这里有一个重要区别：这个60%或者75%不是“超过以后立即执行”的硬性报警线。它更接近Autoscaler希望维持的目标利用率。系统会根据当前实例组的负载和配置，计算需要多少实例，而不是机械地看到一台机器超过75%就增加一台。

而且，Google Cloud并不要求Autoscaling只看CPU。

目前的MIG Autoscaling可以使用平均CPU利用率、负载均衡服务能力、Cloud Monitoring指标以及计划任务等信号。在某些工作负载中，还可以根据队列等业务指标进行扩展。

这非常重要，因为CPU高并不一定意味着用户体验变差，CPU低也不一定意味着服务很健康。

比如一个Web API服务器的CPU只有40%，但是数据库查询延迟已经从50毫秒增加到800毫秒。此时继续增加Web服务器可能没有多大帮助，因为真正的瓶颈在数据库。

反过来，一台服务器CPU可能长期只有50%，但它承担的是大量网络连接或者请求分发任务，真正限制性能的可能是负载均衡服务能力、网络吞吐或者其他指标。

因此，选择Autoscaling信号时，应该尽可能选择能够反映“业务容量”的指标，而不是随手选择一个看起来容易理解的硬件指标。

Google Cloud还允许同时设置多个Autoscaling信号。当多个信号同时存在时，Autoscaler会分别计算每个信号所需要的实例数量，然后采用其中最大的建议规模。这样做的逻辑很简单：如果CPU认为需要10台机器，而负载均衡服务能力认为需要14台，那么系统不能只增加到10台，因为14台才是当前策略中更高的容量需求。

这也是自动扩容真正有价值的地方：它不是简单地根据一个数字开关服务器，而是在多个资源信号之间寻找满足当前需求的容量。

当然，Autoscaling也可以提前扩容。

对于每天上午固定出现流量高峰的网站，如果每天早上9点才开始看到CPU上升，然后才创建VM，新的实例可能来不及在流量高峰之前完成初始化。Google Cloud提供了schedule-based autoscaling，可以提前规定某个时间段至少需要多少台VM。

例如一个在线教育平台每天晚上7点都会出现大量用户同时进入课程。如果一台VM从创建到应用真正能够处理请求需要几分钟，那么7点才开始扩容显然太晚。计划扩容可以提前准备容量。

对于具有明显周期性负载的MIG，还可以使用predictive autoscaling。它利用历史负载预测未来需求，并提前扩容，使新VM能够在负载到来之前准备好。Google特别指出，这种方式更适合具有稳定日周期或周周期，而且实例初始化时间比较长的工作负载。

不过，预测并不是Autoscaling的唯一依据。

如果突然发生一条新闻导致网站访问量暴涨，而这种流量历史上从未出现过，预测模型当然不可能提前准确知道。Google的文档说明，预测Autoscaling仍会受到实时负载信号影响；如果实时负载高于预测值，实时信号会优先发挥作用。

这意味着预测扩容和实时扩容并不是二选一。一个负责提前准备，一个负责应对突然发生的变化。

自动扩容还有一个非常容易被忽略的问题：新实例不是凭空出现以后就马上成为一台“成熟服务器”。

VM需要启动操作系统，运行初始化脚本，启动应用程序，建立连接，并加载必要的数据。Google Cloud允许配置initialization period，用来告诉Autoscaler新实例大约需要多久才能进入稳定工作状态。Autoscaler在扩容判断中会考虑这个初始化阶段，因为刚刚启动的VM产生的资源利用率可能还不能代表正常运行状态。默认初始化时间为60秒，但实际应该根据应用启动过程进行测试和设置。

因此，一个启动需要30秒的Node.js API服务器，与一个需要5分钟加载模型的AI推理服务器，不能使用完全相同的Autoscaling思路。

缩容同样不能理解成“CPU下降就马上删除服务器”。

如果网站刚刚经历一次高峰，流量下降几分钟，Autoscaler如果立即删除大量VM，下一波请求又来了，就可能再次扩容。结果就是实例数量不断增加、减少，系统出现所谓的“抖动”。

Google Cloud为此使用stabilization机制。默认情况下，Autoscaler在缩容时会考虑近期观察到的峰值负载，而不是看到当前负载下降就立即把实例删除。默认的stabilization period为600秒，也就是10分钟。

对于某些业务，还可以使用scale-in controls进一步限制缩容速度。例如一个网站预计流量下降后很快又会迎来第二波高峰，就没有必要在第一波高峰刚结束时迅速删除大量VM。scale-in controls可以限制实例减少的速度。

这说明Autoscaling真正解决的是“容量弹性”，而不是“所有性能问题”。

如果数据库已经达到连接数上限，Web服务器从10台增加到50台可能只会让数据库死得更快。

如果应用使用共享文件系统，而存储IOPS已经达到上限，增加计算实例同样不会自动解决问题。

如果应用内部存在全局锁、单线程任务或者某个只能运行在单节点上的核心组件，那么增加VM也可能无法提高吞吐量。

如果应用需要大量实例之间互相通信，规模继续扩大以后，网络通信成本甚至可能成为新的瓶颈。

因此，配置Autoscaling之前，最好先回答一个非常现实的问题：这个应用的性能到底能不能随着实例数量增加而近似线性增长？

如果增加一台服务器能够多处理一部分请求，增加到10台以后仍然能够继续提高吞吐量，那么Autoscaling非常适合。

如果所有服务器最终都必须等待同一个数据库、同一个磁盘、同一个锁或者同一个外部API，那么Autoscaling的价值就会迅速下降。

成本也是Autoscaling必须考虑的问题。

自动扩容的优势之一就是低负载时可以减少闲置VM，从而降低成本。但自动扩容并不会自动帮企业控制预算。如果一次突发流量让实例组从5台扩大到50台，计算资源产生的费用同样会快速增加。

因此实际生产环境通常应该设置合理的最小实例数和最大实例数。Google Cloud的Autoscaling策略允许配置实例数量上下限，最大实例数尤其重要，因为它可以防止某些异常负载或者错误配置导致实例无限增加。

对于面向公众的网站，一个比较合理的思考方式是把Autoscaling看成一个弹性水库。

正常情况下，只保留满足基本业务所需要的容量；流量增加时释放更多计算资源；高峰过去以后，再逐步收回多余容量。但水库的大小仍然有限，进水管和出水管也有极限。如果数据库、网络或者存储已经堵住，继续增加水库里的水并不能解决问题。

所以，什么时候应该让虚拟机自动增加实例？

答案不是“CPU超过某个数字的时候”，而是当应用的实际容量需求正在增加，而且增加更多实例能够有效分担工作负载的时候。

对于普通Web应用，可以从CPU、请求量或者负载均衡服务能力入手；对于后台任务，可以考虑队列长度或者自定义Cloud Monitoring指标；对于每天规律出现的流量，可以使用计划扩容；对于有明显历史周期且启动时间较长的应用，可以考虑预测扩容。

而对于一个真正成熟的云架构，Autoscaling从来不是单独工作的魔法按钮。它需要和负载均衡、健康检查、数据库扩展、缓存、消息队列、存储以及应用本身的无状态设计配合起来。

最终，Autoscaling的价值也不是让服务器数量变得越多越好，而是在用户真正需要计算能力的时候及时提供，在需求下降以后及时释放。对企业，这意味着少一点闲置资源；对用户，则意味着在流量高峰到来时，后台还有足够的计算能力接住请求。

云计算最有意思的地方就在这里：真正先进的系统，并不是永远拥有最多的服务器，而是能够知道什么时候需要更多服务器，以及什么时候已经不需要了。