3. Health Check 基础：健康检查的定义、分类与检查维度
在蓝绿发布流程中，Health Check（健康检查）是门禁系统的核心决策依据。它决定了新版本实例是否具备接管流量的资格，以及是否需要触发回滚。一个不准确的健康检查可能导致全量流量被导向一个实际上不可用的服务，造成生产事故。
3.1 健康检查的定义
健康检查是一种自动化的探测机制，通过定期向目标实例发送探测信号（如 TCP 连接、HTTP 请求、进程状态查询），并根据返回结果判断该实例是否处于预期的正常工作状态。在蓝绿发布场景下，健康检查的结果直接驱动门禁的“通过/拒绝”决策。
核心原则：健康检查必须反映业务可用性，而不仅仅是进程存活。一个进程在运行但无法处理请求（如数据库连接池耗尽）的实例，应被判定为不健康。
3.2 健康检查的分类
Kubernetes 及大多数编排系统将健康检查分为两类：存活检查（Liveness Probe）和就绪检查（Readiness Probe）。两者在蓝绿发布中的职责截然不同。
| 分类 | 英文名称 | 核心目的 | 失败后果 | 蓝绿发布中的角色 |
|---|---|---|---|---|
| 存活检查 | Liveness Probe | 判断进程是否“活着”，是否处于死锁或崩溃状态 | 重启容器/实例 | 保障实例基础运行，防止“僵尸进程”占用资源 |
| 就绪检查 | Readiness Probe | 判断实例是否“准备好”接收流量，依赖项是否就绪 | 从 Service 端点中移除，不接收流量 | 门禁核心依据：决定是否将新版本加入负载均衡池 |
关键区别：存活检查解决“实例是否在运行”的问题；就绪检查解决“实例是否可用”的问题。在蓝绿发布门禁脚本中，就绪检查的通过率是决定是否切换流量的硬性指标。
3.3 检查维度
健康检查的实现方式决定了探测的深度和准确性。以下是四种常见的检查维度，按从浅到深的顺序排列：
- 端口检查（Port Check）：检测目标端口是否处于监听状态。这是最基础的检查，只能确认进程绑定了端口，无法判断进程是否正常工作。
- 进程检查（Process Check）：通过操作系统命令（如
ps aux | grep）确认进程是否存在。比端口检查稍深，但仍无法感知业务状态。 - HTTP 检查（HTTP Probe）：向指定 URL 发送 HTTP GET 请求，根据状态码（如 200 OK）或响应体内容判断健康状态。这是微服务中最常用的检查方式。
- 自定义脚本检查（Custom Script）：执行用户编写的脚本（Shell、Python 等），脚本内部可包含复杂的业务逻辑，如数据库连接测试、缓存预热验证、上游依赖可达性检查等。
| 检查维度 | 探测深度 | 典型实现 | 适用场景 | 蓝绿发布中的权重 |
|---|---|---|---|---|
| 端口检查 | 浅 | nc -zv 127.0.0.1 8080 |
静态服务、TCP 协议服务 | 低（仅作为前置条件） |
| 进程检查 | 浅 | pgrep -f myapp.jar |
单体应用、后台守护进程 | 低（仅作为存活兜底） |
| HTTP 检查 | 中 | curl -f http://localhost/health |
REST API、Web 服务 | 高（门禁主要依据） |
| 自定义脚本 | 深 | python health_check.py |
有状态服务、依赖复杂链路的服务 | 最高（门禁最终裁决） |
避坑提示：不要在生产环境中仅依赖端口检查作为就绪判断。一个端口在监听但内部线程池已满的服务，会立即拒绝新连接，导致流量雪崩。至少应使用 HTTP 检查，并返回业务层面的健康状态。
3.4 检查维度的选择策略
在实际的蓝绿发布门禁脚本中，通常采用组合检查策略：
- 存活检查：使用端口检查或进程检查，快速发现实例崩溃，触发自动恢复。
- 就绪检查：使用 HTTP 检查或自定义脚本，深度验证业务可用性，决定是否将实例加入负载均衡池。
- 门禁最终裁决：在流量切换前，门禁脚本会执行一次全量就绪检查，要求新版本所有实例的自定义脚本检查通过率 ≥ 100%（或配置的阈值），否则拒绝切换。
最佳实践：自定义脚本应设计为幂等且轻量，避免在检查过程中产生副作用（如写入数据库）。检查超时时间建议控制在 2-5 秒，防止检查本身成为性能瓶颈。