📚 课程目录第4章蓝绿发布门禁概念

4. 蓝绿发布门禁概念：门禁定义、发布流程中的检查点、门禁触发条件与阻断机制

蓝绿发布门禁是部署流水线中用于控制流量切换风险的自动化决策节点。它通过预定义的检查规则，在蓝绿环境切换前对目标环境进行验证，确保只有满足条件的版本才能进入生产流量。门禁的核心目标是防止有缺陷或配置不一致的版本影响用户。

4.1 门禁定义与核心要素

门禁（Gate）本质是一个布尔表达式：当所有检查点（Checkpoint）通过时，门禁放行；任一检查点失败，门禁阻断。门禁通常包含以下核心要素：

要素	说明	示例
检查点	具体的验证项，如健康检查、配置比对、测试结果	Green 环境 /health 返回 200
触发条件	门禁开始评估的时机	Green 环境部署完成、配置同步完成
阻断机制	检查点失败后的处理动作	自动回滚、发送告警、锁定流水线
超时策略	门禁等待检查结果的最长时间	5 分钟未通过则自动阻断
重试策略	检查点失败后的重试次数与间隔	最多重试 3 次，每次间隔 30 秒

实践建议：门禁应设计为“默认阻断”模式，即除非所有检查点明确通过，否则不允许切换。这可以避免因检查点超时或配置缺失导致的误放行。

4.2 发布流程中的检查点

在蓝绿发布的标准流程中，门禁检查点分布在三个关键阶段：部署后、配置同步后、流量切换前。每个阶段都有特定的验证目标。

4.3 门禁触发条件

门禁的触发条件决定了何时开始执行检查。错误的触发时机可能导致检查过早（环境未就绪）或过晚（流量已受损）。常见的触发条件包括：

事件驱动触发：当特定事件发生时触发门禁，如：
- Green 环境所有 Pod 进入 Ready 状态
- 配置同步任务完成（ConfigMap / Secret 更新成功）
- CI/CD 流水线中某个 Job 执行完毕
时间驱动触发：在指定时间窗口内触发门禁，适用于：
- 业务低峰期（如凌晨 2:00-4:00）自动执行
- 固定发布窗口（如每周四 10:00）
手动触发：由运维人员或审批者手动启动门禁检查，适用于：
- 高风险发布需要人工确认
- 紧急热修复需要跳过部分自动检查

  关键原则：触发条件应设置为“环境完全就绪后”再启动门禁，而非“部署开始后”立即启动。建议在部署脚本末尾显式发送门禁触发信号，避免因部署延迟导致门禁误判。

4.4 阻断机制与处理策略

当门禁检查点失败时，系统需要执行预定义的阻断动作。不同的失败类型应匹配不同的处理策略：

失败类型	阻断动作	恢复方式	告警级别
健康检查失败	立即阻断，禁止流量切换	修复后重新触发门禁	P0 紧急
配置参数不一致	阻断并锁定流水线	重新同步配置后重试	P1 严重
冒烟测试失败	阻断并自动回滚至 Blue 环境	修复代码后重新发布	P0 紧急
超时未响应	默认阻断，视为失败	检查门禁服务状态后重试	P2 警告
人工审批超时	默认阻断，等待审批	审批通过后继续	P2 警告

4.5 门禁配置示例（YAML）

以下是一个基于 GitOps 工具的蓝绿发布门禁配置片段，展示了检查点、触发条件和阻断机制的定义方式：

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: blue-green-gate
spec:
  strategy:
    blueGreen:
      activeService: service-blue
      previewService: service-green
      prePromotionAnalysis:
        templates:
          - templateName: gate-check
        args:
          - name: service-name
            value: "myapp-green"
      postPromotionAnalysis:
        templates:
          - templateName: smoke-test
  analysis:
    templates:
      - name: gate-check
        spec:
          metrics:
            - name: health-check
              successCondition: result == 200
              provider:
                http:
                  url: "http://myapp-green:8080/health"
                  interval: 10s
                  count: 3
            - name: config-sync
              successCondition: result == "synced"
              provider:
                job:
                  spec:
                    template:
                      spec:
                        containers:
                          - name: config-validator
                            image: config-checker:1.0
                            command: ["./check-config.sh"]
                        restartPolicy: Never
      - name: smoke-test
        spec:
          metrics:
            - name: e2e-test
              successCondition: result == "pass"
              provider:
                job:
                  spec:
                    template:
                      spec:
                        containers:
                          - name: smoke-tester
                            image: smoke-test:1.0
                            command: ["./run-smoke.sh"]
                        restartPolicy: Never
  # 阻断机制：失败时自动回滚
  revisionHistoryLimit: 3
  failedRevisionHistoryLimit: 1

注意：门禁配置中的 successCondition 表达式必须严格匹配预期结果。建议在测试环境中先验证门禁逻辑，避免因表达式语法错误导致门禁永远无法通过或永远无法阻断。

4.6 门禁设计最佳实践

检查点分层：将检查点分为“快速检查”（如健康检查）和“深度检查”（如端到端测试），快速检查失败时立即阻断，减少资源浪费。
幂等性设计：门禁检查应支持重复执行，多次执行同一检查点应得到相同结果，避免因状态残留导致误判。
可观测性：每个检查点的执行结果、耗时、失败原因都应记录到日志和监控系统，便于事后分析。
渐进式阻断：对于非关键检查点（如性能基线），可设置为“警告但不阻断”，允许人工判断是否继续发布。
门禁超时兜底：设置全局超时时间，防止门禁因外部服务不可用而无限等待，超时后默认执行阻断动作。