4. 弹性伸缩核心概念:伸缩组、伸缩策略、冷却时间、期望实例数、健康检查
在深入 Terraform 模块化封装之前,必须透彻理解弹性伸缩的五大核心概念。它们是构建自动化运维体系的基石,直接决定了伸缩行为的正确性、安全性与成本效益。本章将逐一拆解这些概念,并揭示它们之间的协作关系。
4.1 核心概念全景图
下图展示了五大核心概念在弹性伸缩生命周期中的位置与交互关系:
4.2 伸缩组 (Auto Scaling Group)
伸缩组是弹性伸缩的核心容器,它定义了被管理实例的边界和基础配置。所有伸缩动作都在伸缩组范围内执行。
| 属性 | 说明 | 典型配置 |
|---|---|---|
| 名称 | 伸缩组的唯一标识 | prod-web-asg |
| 最小实例数 | 伸缩组内实例数量的下限 | 2(保障高可用) |
| 最大实例数 | 伸缩组内实例数量的上限 | 10(控制成本) |
| 启动配置/模板 | 定义实例的规格、镜像、密钥等 | ami-xxxxx, t3.medium |
| 可用区列表 | 实例分布的目标可用区 | ["us-east-1a", "us-east-1b"] |
| 负载均衡器 | 关联的 ALB/NLB,用于流量分发 | arn:aws:elasticloadbalancing:... |
最佳实践:在 Terraform 中,伸缩组通常与启动模板(
aws_launch_template)配合使用,而非已弃用的启动配置(aws_autoscaling_group 的 launch_configuration 参数)。启动模板支持版本控制,更利于基础设施即代码的管理。
4.3 伸缩策略 (Scaling Policy)
伸缩策略定义了何时以及如何调整伸缩组内的实例数量。根据触发方式,主要分为以下三类:
- 计划伸缩 (Scheduled Scaling): 基于时间预测,在固定时间点执行伸缩。适用于已知的流量高峰,如“每天 20:00 增加 5 台实例”。
- 动态伸缩 (Dynamic Scaling): 基于实时监控指标(如 CPU 利用率、请求数)自动调整。包括简单伸缩、步进伸缩和目标追踪伸缩。
- 预测伸缩 (Predictive Scaling): 利用机器学习分析历史负载,提前进行伸缩。适用于周期性明显的业务。
| 策略类型 | 触发条件 | 调整方式 | 适用场景 |
|---|---|---|---|
| 计划伸缩 | 时间表达式 (Cron) | 指定实例数增减 | 固定促销、工作日/非工作日切换 |
| 目标追踪伸缩 | 指标阈值(如 CPU > 60%) | 自动调整至目标值 | 通用 Web 服务、微服务 |
| 步进伸缩 | 指标偏离程度(如 CPU > 80%) | 按阶梯增减实例数 | 突发流量、需要精细控制 |
| 预测伸缩 | 历史负载数据 | 提前预置实例 | 电商、视频直播等周期性业务 |
实战要点:在 Terraform 中,
aws_autoscaling_policy 资源用于定义伸缩策略。对于目标追踪策略,只需指定 target_tracking_configuration 块,AWS 会自动创建所需的 CloudWatch 告警,极大简化了配置复杂度。
4.4 冷却时间 (Cool-Down Time)
冷却时间是伸缩组在执行一次伸缩活动后,强制等待的一段时间。其核心目的是防止因指标抖动导致频繁伸缩(即“振荡”或“毛刺”效应)。
- 默认值: 通常为 300 秒(5 分钟)。
- 作用范围: 冷却时间作用于整个伸缩组。在冷却期内,即使监控指标再次触发告警,伸缩组也不会执行新的伸缩动作。
- 特殊策略冷却: 可以为特定伸缩策略设置独立的冷却时间,覆盖组级别的冷却时间,实现更精细的控制。
常见陷阱:冷却时间设置过短(如 30 秒)可能导致伸缩振荡,实例频繁创建和销毁,增加成本并影响服务稳定性。设置过长(如 1800 秒)则可能导致伸缩组响应不及时,无法应对快速变化的负载。建议根据业务指标的变化周期进行调优,通常 120-300 秒是一个合理的起始范围。
4.5 期望实例数 (Desired Capacity)
期望实例数是伸缩组当前期望维持的运行实例数量。它是伸缩组状态的核心指标,伸缩组的所有动作都围绕它展开。
- 初始值: 创建伸缩组时指定,通常介于最小值和最大值之间。
- 动态调整: 伸缩策略执行时,会修改期望实例数。例如,CPU 过高时,期望实例数从 3 增加到 5。
- 手动调整: 运维人员可以直接修改期望实例数,用于紧急扩容或缩容。
- 与最小/最大值的关系: 期望实例数始终受
min_size和max_size约束。如果手动设置的值超出范围,伸缩组会自动将其修正到边界值。
# Terraform 中伸缩组与期望实例数的关系示例
resource "aws_autoscaling_group" "web_asg" {
name = "web-asg"
min_size = 2
max_size = 10
desired_capacity = 3 # 初始期望实例数为 3
launch_template {
id = aws_launch_template.web_template.id
version = "$Latest"
}
# ... 其他配置
}
# 手动更新期望实例数(例如在运维窗口期)
# terraform apply 时修改 desired_capacity = 5
4.6 健康检查 (Health Check)
健康检查是伸缩组自我修复的保障机制。它持续监测组内实例的运行状态,自动替换不健康的实例,确保服务的高可用性。
伸缩组支持两种健康检查类型:
| 检查类型 | 检查方式 | 判定标准 | 响应动作 |
|---|---|---|---|
| EC2 状态检查 | AWS 底层系统自动检测 | 实例系统状态(如系统宕机、网络故障) | 标记为不健康,触发替换 |
| ELB 健康检查 | 通过关联的负载均衡器发送探测请求 | 应用层状态(如 HTTP 200、响应时间) | 标记为不健康,触发替换 |
推荐配置:在生产环境中,建议同时启用 EC2 状态检查和 ELB 健康检查。EC2 检查保障底层基础设施的可用性,ELB 检查保障应用服务的可用性。两者结合,可以更全面地覆盖故障场景。在 Terraform 中,通过
health_check_type 参数指定,可选值为 "EC2" 或 "ELB"。
4.7 概念协同:一个完整的伸缩周期
下图展示了上述五个概念如何协同工作,完成一次完整的伸缩周期:
关键总结:伸缩组是容器,伸缩策略是触发器,期望实例数是目标值,健康检查是质量门禁,冷却时间是稳定器。在 Terraform 模块化封装中,这五个概念将作为模块的输入变量和内部资源进行抽象,实现可复用的弹性伸缩基础设施。