SST项目中负载均衡器健康检查路径配置问题解析

在基于SST框架的云应用部署过程中，开发团队遇到了一个典型的负载均衡器健康检查异常问题。该问题表现为：在四个相同代码版本的环境部署中，两个环境运行正常，而另外两个环境则持续出现健康检查失败，导致容器不断被重新调度。

问题现象

当使用SST的Cluster和Service组件部署服务时，开发人员发现：

1. 四个环境使用完全相同的Dockerfile和代码提交
2. 两个较早创建的环境保持稳定运行
3. 两个新创建的环境出现周期性(约10分钟)的容器重建
4. 所有环境共享相同的负载均衡器配置模板

根本原因分析

经过深入排查，发现问题的根源在于健康检查路径的隐式配置差异：

1. 历史配置遗留
   最早创建的两个环境在初始部署时，代码中显式设置了健康检查路径为/v1/health。这个配置被AWS负载均衡器持久化保存。

2. 后续配置变更
   在后续代码迭代中，开发团队移除了显式的健康检查路径配置，期望系统采用默认值。然而SST框架中负载均衡器的健康检查是强制性的。

3. 配置更新机制
   AWS负载均衡器对于已有环境的健康检查路径不会自动重置为默认值，而是保留历史配置。新建环境则会采用框架的默认路径/。

解决方案

1. 显式声明健康检查路径
   在Service配置中明确指定健康检查路径，确保所有环境一致性：

loadBalancer: {
  healthCheck: {
    path: "/v1/health"
  }
}

2. 环境配置标准化
   对已有环境进行统一化处理，通过SST的更新机制强制同步配置。

经验总结

1. 基础设施即代码的幂等性
   云资源配置的变更需要考虑历史环境的处理方式，不能假设所有环境都会同步更新。

2. 健康检查最佳实践

• 始终显式声明健康检查路径
• 确保健康检查端点与业务逻辑解耦
• 在生产环境部署前验证健康检查机制

3. SST框架使用建议
   对于关键的基础设施配置，建议在代码中保持显式声明，避免依赖框架默认值，特别是在多环境部署场景下。

该案例展示了云原生应用中配置管理的重要性，提醒开发者在基础设施即代码实践中需要关注配置的完整性和环境一致性。