二、门禁机制详解：什么是发布门禁、门禁的触发条件、门禁在CI/CD流水线中的位置
2.1 什么是发布门禁
发布门禁（Deployment Gate）是 CI/CD 流水线中一道自动化的质量关卡。它像一扇智能锁——只有满足预设的健康条件，锁才会打开，允许新版本流量进入生产环境；否则流水线被阻塞，触发告警并阻止发布继续。
核心定义：门禁是一段可编程的检查逻辑，通常以脚本或 API 调用的形式嵌入流水线，在蓝绿发布、金丝雀发布等场景中充当“安全阀门”。
| 维度 | 说明 |
|---|---|
| 目的 | 防止有缺陷的版本被全量暴露给用户，降低故障半径 |
| 检查对象 | 新版本实例的 HTTP 状态码、响应体、延迟、资源指标、依赖服务可达性 |
| 执行时机 | 新版本部署完成但尚未切换流量，或切换流量后灰度验证阶段 |
| 输出结果 | PASS（放行）/ FAIL（阻断 + 回滚或告警） |
2.2 门禁的触发条件
门禁并非每时每刻都在运行，它由明确的事件或状态触发。在蓝绿发布场景中，常见的触发条件包括：
- 新版本就绪事件：Kubernetes Deployment 的 Pod 全部 Running & Ready，或传统 VM 部署的进程启动完成。
- 负载均衡器注册完成：新版本实例已加入后端服务器组，但尚未接收生产流量。
- 人工确认信号：部分流水线在自动检查前，先等待运维人员点击“确认开始健康检查”。
- 定时/轮询策略：门禁脚本以固定间隔（如每 10 秒）主动探测，直到超时或通过。
- 流水线阶段完成回调：前序步骤（如镜像扫描、单元测试）全部通过后，自动触发门禁阶段。
最佳实践：门禁触发条件应尽量自动化，减少人工介入。推荐使用“新版本就绪事件 + 轮询探测”的组合，既保证时机准确，又避免单点失败。
2.3 门禁在CI/CD流水线中的位置
门禁通常位于部署阶段之后、流量切换之前，是蓝绿发布流程中的“最后一道防线”。下面用一张流程图展示其典型位置：
2.4 门禁在流水线中的详细阶段划分
为了更精确地理解门禁的职责边界，可以将蓝绿发布流水线拆解为以下阶段：
| 阶段 | 主要动作 | 门禁是否介入 |
|---|---|---|
| 1. 前置检查 | 代码静态检查、单元测试、安全扫描 | ❌ 否（属于质量门禁前置） |
| 2. 构建与制品 | 编译、打包 Docker 镜像、推送仓库 | ❌ 否 |
| 3. 部署新版本 | K8s apply / Ansible 部署 / 蓝环境启动 | ❌ 否 |
| 4. 门禁检查 | Health Check 脚本执行：HTTP 探测、响应验证、延迟检查、依赖健康 | ✅ 是（核心门禁） |
| 5. 流量切换 | 负载均衡器切换权重 / DNS 切换 / 网关路由更新 | ❌ 否（门禁通过后自动执行） |
| 6. 后置验证 | 短时间持续监控新版本错误率、延迟、业务指标 | ⚠️ 部分团队在此也设门禁（灰度门禁） |
常见误区：门禁不是“部署完成后的简单 curl 检查”。它应该包含重试逻辑、超时控制、多维度指标验证，并且能根据检查结果自动决定放行或阻断。一个只检查 200 状态码的门禁，远不足以保障发布安全。
2.5 门禁在蓝绿发布中的两种典型模式
根据门禁检查的时机和粒度，可以将其分为两种模式：
- 全量门禁（All-or-Nothing）：新版本所有实例都通过健康检查后，一次性切换全部流量。适合风险较低、版本变更较小的场景。
- 灰度门禁（Canary Gate）：先切换小比例流量（如 5%），门禁持续监控一段时间，确认无误后再逐步增加权重。适合高风险变更或大版本发布。