Kong负载均衡中未配置健康检查导致请求异常的分析与解决

问题背景

在使用Kong 3.4.0版本作为API网关时，开发人员发现当上游服务(upstream)中的某个目标(target)下线后，通过Kong发起的请求偶尔会被转发到已下线的目标，导致返回502错误。日志中显示请求被连续尝试发送到同一个不可用的目标多次，最终导致请求失败。

问题现象分析

从日志中可以观察到两种典型情况：

1. 异常情况：请求被连续三次转发到同一个不可用的目标(10.10.52.141:20080)，最终返回状态码499，上游状态显示为"502, 502, -"。

2. 正常情况：请求先被转发到不可用目标(返回502)，然后被正确转发到可用目标(返回200)，最终请求成功。

根本原因

通过分析Kong的配置和运行机制，发现问题的根本原因在于未正确配置健康检查机制。Kong的负载均衡模块在没有主动健康检查配置的情况下，会采用被动健康检查机制，即：

1. 初始状态下，Kong并不知道哪些后端目标是可用的
2. 当请求到来时，Kong会尝试将请求转发到选定的目标
3. 如果目标不可用，Kong会记录这次失败
4. 在后续请求中，Kong可能会继续尝试该目标，直到达到一定的失败阈值

这种机制导致了以下问题：

• 在目标刚下线时，Kong仍会尝试将请求转发给它
• 需要多次失败后，Kong才会将该目标标记为不可用
• 在此期间，部分请求会被错误地路由到不可用目标

解决方案

要解决这个问题，最有效的方法是配置主动健康检查。Kong提供了完善的健康检查机制，包括：

1. 主动健康检查：定期向后端目标发送探测请求，提前发现不可用目标
2. 被动健康检查：基于实际请求的响应情况来标记目标状态

配置示例（通过Kong Admin API）：

curl -X PATCH http://localhost:8001/upstreams/rest-service-upstream \
  --data "healthchecks.active.type=http" \
  --data "healthchecks.active.http_path=/" \
  --data "healthchecks.active.timeout=1" \
  --data "healthchecks.active.concurrency=10" \
  --data "healthchecks.active.healthy.interval=5" \
  --data "healthchecks.active.healthy.successes=1" \
  --data "healthchecks.active.healthy.http_statuses=200,302" \
  --data "healthchecks.active.unhealthy.interval=5" \
  --data "healthchecks.active.unhealthy.http_failures=1" \
  --data "healthchecks.active.unhealthy.http_statuses=429,500,503"

最佳实践建议

1. 始终配置健康检查：即使是简单的服务，也应该配置基本的健康检查
2. 合理设置检查参数：根据后端服务的特性调整检查间隔、超时时间等参数
3. 监控健康状态：通过Kong的Admin API定期检查上游目标的健康状态
4. 考虑故障转移策略：对于关键服务，可以配置多个目标并设置不同的权重

总结

Kong的负载均衡功能非常强大，但需要正确配置健康检查机制才能发挥最佳效果。未配置健康检查可能导致请求被错误路由到不可用目标，影响服务可靠性。通过合理配置主动和被动健康检查，可以显著提高API网关的稳定性和可用性。

对于生产环境，建议在部署前充分测试健康检查配置，确保在各种故障场景下都能正确工作，为业务提供稳定的服务保障。