Nginx负载均衡健康检查机制与主动探测配置实战

Nginx负载均衡健康检查的工作原理

Nginx作为最广泛使用的反向代理和负载均衡器，其后端健康检查直接影响服务可用性。Nginx开源版默认采用被动健康检查，仅在实际请求失败时才将后端标记为不可用。这种方式在流量低峰期存在故障发现延迟问题——如果没有请求到达某个后端，该后端即使已经宕机也不会被感知。

健康检查分为两种模式：被动检查（开源版内置）和主动检查（需nginx_upstream_check_module或商业版）。被动检查通过max_fails和fail_timeout参数控制，当连续失败次数达到max_fails后，Nginx在fail_timeout时间内不再向该后端转发请求。

被动健康检查的配置与陷阱

被动检查的配置简单但细节多：

upstream backend {
    server 10.0.1.1:8080 max_fails=3 fail_timeout=30s;
    server 10.0.1.2:8080 max_fails=3 fail_timeout=30s;
    server 10.0.1.3:8080 max_fails=2 fail_timeout=60s;
}

server {
    location / {
        proxy_pass http://backend;
        proxy_connect_timeout 5s;
        proxy_read_timeout 10s;
        proxy_next_upstream error timeout http_502 http_503 http_504;
        proxy_next_upstream_timeout 15s;
        proxy_next_upstream_tries 3;
    }
}

几个常见陷阱：max_fails=0意味着永远不标记后端不可用，这在某些场景下是需要的，但大多数情况是误配；fail_timeout结束后后端自动恢复，如果后端仍未修复则又会产生失败请求，形成抖动；proxy_next_upstream配合被动检查使用时，注意proxy_next_upstream_tries限制总尝试次数，避免所有后端都被尝试一遍后才返回错误。

主动健康检查模块的编译与配置

nginx_upstream_check_module是淘宝开源的主动健康检查模块，需要在编译Nginx时打补丁集成：

# 下载Nginx源码和补丁
wget http://nginx.org/download/nginx-1.26.2.tar.gz
tar xzf nginx-1.26.2.tar.gz
cd nginx-1.26.2

# 打补丁（根据Nginx版本选择补丁文件）
patch -p1 < /path/to/nginx_upstream_check_module/check_1.26.2+.patch

# 编译
./configure --add-module=/path/to/nginx_upstream_check_module \
    --with-http_ssl_module \
    --with-http_realip_module
make && make install

编译完成后，在upstream块中配置主动检查：

upstream backend {
    server 10.0.1.1:8080;
    server 10.0.1.2:8080;
    server 10.0.1.3:8080;

    # 主动健康检查配置
    check interval=5000 rise=2 fall=3 timeout=3000 type=http;
    check_http_send 'GET /health HTTP/1.0\r\nHost: backend\r\n\r\n';
    check_http_expect_alive http_2xx http_3xx;
}

# 状态页面
server {
    listen 8888;
    location /status {
        check_status;
        access_log off;
    }
}

参数含义：interval=5000表示每5秒探测一次；rise=2表示连续2次探测成功后标记为健康；fall=3表示连续3次探测失败后标记为不可用；timeout=3000为单次探测超时3秒。type=http表示使用HTTP协议探测，还可选tcp、ssl_hello、ajp等。

健康检查接口的设计原则

后端/health接口的设计直接影响检查效果。一个合格的实现应包含多层检测：

@app.route('/health')
def health_check():
    checks = {}
    
    # 应用层存活
    checks['app'] = 'ok'
    
    # 数据库连接
    try:
        db.session.execute('SELECT 1')
        checks['db'] = 'ok'
    except Exception as e:
        checks['db'] = f'error: {str(e)[:50]}'
    
    # 缓存连接
    try:
        redis.ping()
        checks['redis'] = 'ok'
    except Exception as e:
        checks['redis'] = f'error: {str(e)[:50]}'
    
    all_ok = all(v == 'ok' for v in checks.values())
    status_code = 200 if all_ok else 503
    return jsonify(checks), status_code

关键设计原则：/health接口本身不能依赖外部服务调用，否则外部服务故障会导致健康检查也失败；响应时间应控制在500ms以内，避免影响探测频率；深层依赖检测放在/ready或/detailed-health接口，与存活探针分开。

大规模集群的检查优化

当后端节点超过50个时，健康检查本身会产生可观的请求量。优化手段包括：延长低优先级节点的检查间隔（interval=10000）；对非关键后端使用TCP探针替代HTTP探针，减少开销；根据业务高峰低谷动态调整检查频率，通过Nginx的API动态修改upstream参数。

另一个常见问题是健康检查风暴：Nginx重启时所有upstream同时发起检查，瞬间产生大量请求。解决方法是给不同upstream设置不同的interval偏移，或者在应用层实现启动延迟，让健康检查接口在服务完全就绪后才返回200。