在弹性伸缩中，实例健康检查是保证服务连续性的第一道防线。当一台实例因硬件故障、网络分区或应用崩溃而变得不健康时，弹性伸缩组需要及时识别并自动替换，否则请求会持续路由到故障节点，导致错误率上升。本文将从典型场景出发，详细讲解健康检查的工作原理、配置步骤和自动替换的触发机制，帮助您避免常见误区。
场景：电商大促期间，一台实例突然无响应
假设您运行着一个电商网站，使用弹性伸缩组管理着一组 EC2 实例。大促期间流量激增，弹性伸缩组自动扩容到 10 台实例。突然，监控告警显示一台实例的 CPU 使用率持续 100%，但 HTTP 请求超时率上升。您需要快速判断：这台实例是否健康？弹性伸缩组会自动替换它吗？
这里的关键在于健康检查的类型和阈值。默认情况下，弹性伸缩组只检查实例的底层状态（如停止、终止等），但您需要配置更深入的健康检查，例如 ELB 健康检查，来探测应用层的响应。
健康检查的类型：从系统状态到应用探测
弹性伸缩支持两种健康检查类型：
- EC2 状态检查：检查实例是否处于运行中且系统状态正常，这只能发现底层硬件或网络问题。
- ELB 健康检查：通过负载均衡器定期向实例发送请求（如 HTTP GET），验证应用是否正常响应。这能发现应用崩溃、端口未监听等问题。
在电商场景中，仅依赖 EC2 状态检查是不够的，因为实例可能运行中但应用已挂起。因此，建议为弹性伸缩组关联一个负载均衡器，并启用 ELB 健康检查。
配置健康检查：步骤与参数
以 AWS Auto Scaling 为例，配置健康检查的步骤如下：
- 在弹性伸缩组中，指定健康检查类型为 ELB（或同时使用 EC2 和 ELB）。
- 设置健康检查宽限期（Grace Period），默认 300 秒，让新启动的实例有时间初始化并通过健康检查。
- 调整负载均衡器的健康检查参数，包括检查间隔、超时时间、健康阈值和不健康阈值。
- 配置 CloudWatch 告警，当不健康实例数量超过阈值时触发扩展策略。
关键参数取舍：较短的检查间隔（如 30 秒）能更快发现故障，但会增加负载均衡器的请求量；较长的阈值（如 5 次不健康）可以避免误判，但会延长替换时间。建议根据应用启动时间和容错能力平衡。
自动替换机制：从检测到替换的流程
当实例被标记为不健康时，弹性伸缩组会执行以下操作：
- 检测到不健康实例（根据健康检查结果）。
- 立即将其标记为 不健康，并停止向其发送新请求。
- 启动替换流程：终止不健康实例，并按需启动新实例。
- 新实例通过健康检查后，开始接收流量。
这个过程是自动的，但您需要确保伸缩组具有足够的配额和子网容量，否则替换可能失败。另外，如果实例处于缩容保护状态，替换不会触发，这可能是您需要的，也可能是隐患。
常见误区与失败条件
- 误区：健康检查只检查系统状态：很多用户误以为 EC2 状态检查足够，实际上应用层故障不会被发现。
- 误区：宽限期越长越好：过长的宽限期会导致故障实例持续接收流量，影响整体可用性。
- 失败条件：安全组限制：如果负载均衡器的健康检查请求被安全组拦截，所有实例都会被标记为不健康，导致频繁替换。
- 失败条件：依赖本地存储：如果应用数据存储在实例本地（如临时磁盘），替换后数据会丢失，需要设计无状态架构。
结合成本与安全的最佳实践
在配置健康检查时，还需要考虑成本和安全。AWS 成本优化支柱建议：使用弹性伸缩按需匹配容量，避免过度配置；同时，安全支柱强调最小权限原则，确保健康检查接口不泄露敏感信息。
例如，健康检查端点应返回 200 状态码，且不包含敏感数据；同时，确保伸缩组使用的启动模板包含安全补丁，避免新实例带病上线。
总结：让健康检查成为自动化的基石
实例健康检查是弹性伸缩自动替换的核心。通过配置 ELB 健康检查、合理设置阈值和宽限期，并避免常见误区，您可以构建一个高可用的自动伸缩环境。记住，健康检查不是可选项，而是弹性伸缩的必备组件。
参考资料
延伸阅读