弹性伸缩组缩容时，如果直接终止实例，正在处理请求的客户端可能会遇到连接中断，甚至导致数据不一致。如何优雅下线实例，是弹性伸缩实践中必须解决的问题。本文从一个典型场景出发，分析缩容时可能遇到的问题，并给出具体操作步骤和常见误区。
典型场景：流量下降触发缩容
假设一个Web服务运行在弹性伸缩组中，当前有10个实例，每个实例都处理着活跃的HTTP请求。某天流量下降，伸缩策略触发缩容，决定将实例数减少到8个。伸缩组会选择两个实例进行终止。如果直接终止，这两个实例上正在处理的请求会立即失败，客户端可能看到连接重置或超时。
优雅下线的核心：先摘流量，再终止
优雅下线的核心是“先摘流量，再终止”。具体来说，需要让实例停止接收新请求，同时等待已有请求处理完成，然后再终止实例。AWS EC2 提供了生命周期钩子（Lifecycle Hook）来实现这一过程，它允许在实例被终止前执行自定义操作。您可以利用它来注销实例、通知负载均衡器摘除节点、等待连接耗尽等。
操作步骤：以 AWS 为例
- 创建生命周期钩子：在伸缩组中创建一个“终止中”（terminating）类型的生命周期钩子，指定超时时间（例如300秒）。当实例被标记为终止时，会自动进入等待状态，并触发钩子通知。
- 摘除负载均衡：在钩子触发的通知中，通过脚本或Lambda函数调用负载均衡器的接口，将该实例从目标组中注销，并等待连接耗尽（deregistration delay）。
- 处理应用逻辑：如果应用有额外的清理需求（如刷新缓存、保存状态），可以在等待期间完成。
- 完成钩子：处理完毕后，调用 API 发送“继续”操作，让伸缩组继续执行终止。
连接耗尽：负载均衡器的关键设置
如果使用负载均衡器（如ALB），需要设置目标组的“取消注册延迟时间”（deregistration delay），即连接耗尽时间。在实例被注销后，负载均衡器会等待该时间让已建立的连接完成，然后才完全移除实例。这个时间应根据应用的最大请求处理时间来设置，过短会导致长请求被中断，过长会拖慢缩容速度。
常见误区与失败条件
- 误区一：直接依赖伸缩组的健康检查。健康检查只能发现“不健康”的实例，但并不能保证实例上没有正在处理的请求。缩容时，实例可能仍然健康，但已有请求在处理中。
- 误区二：忽略生命周期钩子的超时时间。如果自定义操作超过超时时间，实例会被强制终止，导致优雅下线失败。需要确保操作在超时前完成，或适当延长超时。
- 误区三：不处理长连接场景。对于WebSocket或长轮询请求，连接可能持续很久，简单的“等待连接耗尽”可能不够，需要应用层主动通知客户端重连。
成本与安全的权衡
优雅下线会增加缩容的耗时，可能影响成本优化。AWS 成本优化支柱建议，在设计工作负载时，应充分利用资源，同时实现最低成本。缩容时，如果等待时间过长，会保留不必要的实例，增加成本。因此，需要根据业务需求设定合理的超时和连接耗尽时间，在成本与可用性之间取得平衡。同时，安全支柱也提醒，确保在实例终止前清理敏感数据，避免数据泄露。
结论
优雅下线实例是弹性伸缩组缩容的关键环节，通过生命周期钩子、连接耗尽等机制，可以避免连接中断，提升用户体验。但需要根据应用类型和业务需求，合理配置相关参数，并定期测试缩容流程，确保在真实场景下可靠运行。
参考资料
延伸阅读