4. 门禁机制概述：发布门禁的定义、常见门禁类型
在蓝绿发布流程中，门禁（Gate） 是部署管道中预设的自动化检查点，用于在环境切换前拦截不符合质量、安全或合规要求的版本。门禁机制的核心目标是：只有通过所有门禁的版本，才允许执行流量切换。门禁不是可选的“建议”，而是阻断性的“强制规则”。
关键原则：门禁一旦失败，发布流水线自动中止，并触发告警通知到对应责任团队。人工跳过门禁必须经过审批并记录原因。
4.1 发布门禁的定义
发布门禁是部署管道中一个可编程的、自动化的质量/安全/合规检查节点。它通常位于蓝绿环境切换之前，作为最后一道防线。门禁的输入是当前版本的部署元数据、测试报告、扫描结果等；输出是 Pass（允许切换）或 Fail（阻断切换）。
| 维度 | 说明 |
|---|---|
| 触发时机 | 蓝环境部署完成、绿环境就绪后，流量切换前 |
| 检查方式 | 自动调用 API、查询数据库、解析报告文件 |
| 结果处理 | Pass → 继续发布；Fail → 回滚或阻塞 |
| 超时策略 | 超过设定时间未返回结果，默认视为 Fail |
4.2 常见门禁类型
根据检查目标的不同，门禁可分为三大类：质量门禁、安全门禁、合规门禁。每一类在蓝绿发布场景下都有特定的检查项和阈值。
4.2.1 质量门禁
质量门禁关注版本的功能正确性、性能稳定性和可靠性。它是发布门禁中最基础、最核心的一类。
- 自动化测试通过率：单元测试、集成测试、端到端测试通过率必须 ≥ 99.5%（或自定义阈值）。
- 性能回归检查：P99 延迟、吞吐量、错误率与基线版本对比，劣化不超过 5%。
- 代码覆盖率：新增代码的行覆盖率 ≥ 80%，分支覆盖率 ≥ 70%。
- 冒烟测试：蓝环境部署后，自动执行冒烟用例，全部通过。
实践建议：质量门禁的阈值应基于历史数据动态调整，避免因测试环境不稳定导致频繁误阻断。建议使用“最近 7 天基线”而非固定值。
4.2.2 安全门禁
安全门禁在蓝绿发布中尤为重要，因为流量切换后，有问题的版本会直接暴露给生产用户。安全门禁主要检查以下方面：
| 检查项 | 典型规则 |
|---|---|
| 漏洞扫描 | 无 Critical / High 级别漏洞；Medium 级别漏洞数 ≤ 5 |
| 依赖库检查 | 所有第三方依赖无已知 CVE；许可证合规 |
| 密钥泄露检测 | 代码中无硬编码密钥、、证书 |
| 容器镜像扫描 | 基础镜像无高危漏洞；非 root 用户运行 |
4.2.3 合规门禁
合规门禁确保发布版本满足企业内部的运维规范、审计要求和行业法规。这类门禁通常与 服务目录 中的元数据强关联。
- 标签合规：服务实例必须包含 owner、environment、cost-center 等强制标签。
- 日志与监控：必须接入统一日志平台，且关键指标已配置告警。
- 变更审批：对于 P0/P1 级服务，必须有至少 2 人审批通过。
- 数据分类：涉及敏感数据的服务，必须启用数据脱敏或加密。
注意：合规门禁的规则通常由平台工程团队与安全、法务、运维共同制定，并固化在服务目录模板中。服务上线时即完成合规预检，发布阶段仅做增量检查。
4.3 门禁机制流程概览
下图展示了蓝绿发布过程中，门禁机制如何串联质量、安全、合规三类检查，并最终决定是否允许流量切换。
4.4 门禁与服务目录的关联
在平台工程视角下，门禁规则不应硬编码在流水线中，而应通过 服务目录 进行声明式管理。每个服务在目录中定义自己的门禁配置，包括：
- 门禁模板：选择预定义的质量/安全/合规模板。
- 阈值覆盖：允许服务 owner 根据业务特性调整阈值。
- 豁免策略：特定条件下可跳过某些门禁（需审批）。
- 门禁版本：门禁规则本身也纳入版本管理，随服务目录一起变更。
平台工程最佳实践：将门禁配置作为服务目录的“契约”一部分，实现“配置即策略”。流水线运行时，从服务目录动态拉取门禁规则，而非在 Jenkinsfile 或 GitLab CI 中写死。
通过这种设计，平台团队可以统一管控门禁标准，同时赋予服务团队灵活的定制能力，真正实现 标准化与灵活性的平衡。