3. 健康检查核心概念：健康检查的目的、存活检查与就绪检查的区别、探针机制

健康检查是蓝绿发布与门禁系统中最核心的决策依据。没有健康检查，流量切换就是盲人摸象。本节从目的出发，厘清存活检查与就绪检查的本质差异，并深入探针机制的工作原理。

3.1 健康检查的目的

健康检查的根本目标是判断服务实例是否具备处理请求的能力。在蓝绿发布场景中，健康检查直接决定门禁是否放行流量切换。具体目的包括：

• 故障检测：快速发现进程崩溃、死锁、内存溢出等致命问题。
• 流量保护：避免将用户请求路由到尚未就绪或正在退出的实例。
• 自动恢复：触发容器编排系统（如 Kubernetes）重启异常实例。
• 发布验证：在蓝绿切换前确认新版本集群全部健康，防止有损发布。

3.2 存活检查（Liveness）与就绪检查（Readiness）的区别

这两类检查是健康检查体系的两大支柱，但关注点完全不同。下表从多个维度进行对比：

3.3 探针（Probe）机制

探针是健康检查的具体执行单元。Kubernetes 定义了三种探针类型，每种探针支持多种协议实现。下图展示了探针在 Pod 生命周期中的位置：

3.4 探针支持的协议与配置

探针通过不同的协议与目标服务交互。以下是主流协议及其配置要点：

3.5 探针配置参数详解

每个探针都有一组精细的调优参数，直接影响检查的灵敏度和稳定性：

• initialDelaySeconds：容器启动后等待多久开始第一次检查，避免启动阶段误判。
• periodSeconds：两次检查之间的间隔时间，默认 10s。
• timeoutSeconds：单次检查的超时时间，超时视为失败。
• successThreshold：连续成功多少次才认为健康，默认 1。
• failureThreshold：连续失败多少次才触发动作，默认 3。

3.6 多协议健康检查的配置示例

以下是一个 Kubernetes Deployment 中同时配置 HTTP 存活检查与 TCP 就绪检查的示例：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: app
        image: my-app:1.0.0
        ports:
        - containerPort: 8080
        - containerPort: 9090
        livenessProbe:
          httpGet:
            path: /healthz
            port: 8080
            scheme: HTTP
          initialDelaySeconds: 5
          periodSeconds: 10
          timeoutSeconds: 2
          failureThreshold: 3
        readinessProbe:
          tcpSocket:
            port: 9090
          initialDelaySeconds: 3
          periodSeconds: 5
          timeoutSeconds: 1
          successThreshold: 1
          failureThreshold: 2

上述配置中，存活检查通过 HTTP 检测主端口 8080 的业务健康状态；就绪检查通过 TCP 检测辅助端口 9090 的后台服务是否就绪。两者独立运行，互不干扰。