动态伸缩核心是云平台基于负载自动触发伸缩组动作，关键在指标组合（如requestcountpertarget+cpu）、健康检查就绪信号、生命周期挂钩优雅缩容及配额/网络配置排查。
动态增减服务器不是靠手动加机器或删实例实现的，核心是让云平台根据负载自动触发伸缩组（Auto Scaling Group）的扩缩容动作。关键不在“怎么点按钮”，而在于指标选择、冷却时间、实例启动模板是否真正就绪。
伸缩策略里用 CPU 利用率还是请求量做触发条件？
单纯看 CPUUtilization 容易误判：比如 Java 应用刚启动时 GC 频繁拉高 CPU，但实际没流量；或 I/O 密集型服务 CPU 低却已打满磁盘带宽。更稳的做法是组合指标：
- Web 层优先用
RequestCountPerTarget（ALB/NLB 指标）或自定义上报的 QPS - 后台任务队列用 SQS 的
ApproximateNumberOfMessagesVisible - 必须配一个兜底指标，比如
CPUUtilization > 70%持续 5 分钟，防突发长连接占满内存
注意：不同云厂商指标命名和延迟不同，AWS CloudWatch 默认 1 分钟粒度，阿里云监控可能有 2–3 分钟延迟，策略里的「持续周期」得留出缓冲。
为什么新实例启动后立刻被标记为 Unhealthy？
常见原因是健康检查（Health Check）在实例还没完成应用部署时就发起了探测。典型表现是伸缩组反复创建销毁同一台实例。
- 确保启动模板中
UserData脚本末尾有明确的「就绪信号」，比如 AWS 上用cfn-signal，阿里云用ecs-sync - 把 ELB/ALB 的健康检查路径设为
/healthz，并在应用里实现该接口——只在依赖服务（DB、Redis）连通且主逻辑加载完成后才返回 200 - 伸缩组的
HealthCheckGracePeriod至少设为 300 秒（5 分钟），给初始化留足时间
缩容时老实例被直接终止，用户请求中断怎么办？
默认行为就是立即终止，但你可以控制生命周期：
- 在伸缩组启用
Termination Policy并设为OldestInstance或Default，避免随机杀掉正在处理长请求的实例 - 更可靠的是结合生命周期挂钩（Lifecycle Hook）：设置
Terminating:Wait，让实例进入等待状态，此时可调用 API 触发drain操作（如从注册中心下线、关闭新连接、等待活跃请求结束） - Nginx 或 Envoy 前端需配置
proxy_next_upstream或重试策略，容忍后端短暂不可用
别忘了：缩容前务必确认所有实例都通过了应用层健康检查，否则生命周期挂钩可能等不到你预期的信号就超时强制终止。
伸缩组扩到 100 台却卡在 20 台不动？
这不是策略问题，是账户配额或资源不足卡住的。先查三处：
- AWS：检查
ec2:RunInstances权限是否允许指定的InstanceType和Subnet组合；再看On-Demand Instance Limit是否触及上限（尤其新账号默认只有 20 vCPU） - 阿里云：确认目标可用区是否有库存，
DescribeZones返回的AvailableResourceList里InstanceType状态是否为Available - 所有平台都要检查启动模板引用的
SecurityGroup和KeyPair是否在目标 VPC 内存在且可访问
最常被忽略的是子网路由表没配好，导致新实例获取不到元数据服务（169.254.169.254），UserData 根本不执行，整条链路就断在第一步。
