4. HTTP 健康检查协议：探针工作原理与状态码判断

HTTP/HTTPS 探针是蓝绿发布门禁中最常用的健康检查方式。它通过模拟客户端向目标服务发送 HTTP 请求，并根据响应状态码、响应体或响应头来判断服务是否可用。本节将深入解析探针的工作原理、状态码判断逻辑以及超时与重试机制。

4.1 HTTP/HTTPS 探针工作原理

探针本质上是一个轻量级的 HTTP 客户端，按照固定的时间间隔向目标端点发起请求。其核心工作流程如下：

1. 构造请求：探针根据配置生成 HTTP 请求，包括 URL、方法（GET/POST）、Headers、Body 等。
2. 发起连接：建立 TCP 连接（HTTPS 还需完成 TLS 握手）。
3. 发送请求：将构造好的 HTTP 请求发送至目标服务。
4. 等待响应：在超时时间内等待服务端返回 HTTP 响应。
5. 状态码判断：根据返回的状态码判定健康状态。
6. 可选校验：部分高级探针还会校验响应体内容或响应头字段。

4.2 状态码判断：200 与 503 的核心逻辑

在蓝绿发布门禁中，状态码是判断服务健康最直接的依据。通常将 2xx 和 3xx 视为健康，4xx 和 5xx 视为不健康。其中 200 OK 和 503 Service Unavailable 是最具代表性的两个状态码。

4.3 超时与重试机制

超时和重试是健康检查可靠性的关键保障。合理的配置可以避免因网络抖动导致的误判，同时防止探针本身成为系统的瓶颈。

4.3.1 超时机制

超时定义了探针等待服务响应的最长时间。超过该时间未收到完整响应，探针将判定本次检查失败。

4.3.2 重试机制

重试机制允许探针在首次检查失败后，再次尝试检查，以区分瞬时故障和永久故障。

• 重试次数：通常设置为 1-3 次。过多重试会延迟故障发现时间。
• 重试间隔：两次重试之间的等待时间，建议 500ms-2s。
• 退避策略：固定间隔、线性退避或指数退避。推荐使用指数退避避免重试风暴。
• 失败阈值：连续失败次数达到阈值（如 3 次）才判定服务不健康，避免单次超时导致误判。

4.4 配置示例

以下是一个典型的 Nginx 健康检查配置示例，展示了超时、重试和状态码判断的具体实现：

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

    # 健康检查配置
    health_check interval=5s fails=3 passes=2 uri=/health;
    
    # 超时配置
    keepalive_timeout 3s;
    proxy_connect_timeout 2s;
    proxy_read_timeout 3s;
}

# 健康检查端点
location /health {
    proxy_pass http://backend;
    health_check interval=5s;
    health_check_timeout 3s;
    
    # 状态码判断：只接受 200 和 302
    health_check_status 200 302;
}

4.5 HTTPS 探针的特殊考量

当使用 HTTPS 协议进行健康检查时，除了 HTTP 探针的所有机制外，还需额外关注以下问题：

• TLS 握手开销：每次健康检查都需要完成 TLS 握手，会增加延迟和 CPU 消耗。建议启用会话复用（Session Resumption）减少握手次数。
• 证书验证：探针需要验证服务端证书的有效性。在内部环境中，可以使用自签名证书并配置探针信任该 CA。
• SNI 支持：如果多个服务共用同一 IP，探针必须在 ClientHello 中携带 SNI 字段，否则可能无法正确路由。
• TLS 版本与密码套件：确保探针与服务端支持的 TLS 版本和密码套件兼容，避免因协议不匹配导致连接失败。