2. IDP 自助门户架构概览：蓝图、组件与灰度发布位置
在深入灰度发布准入检查之前，必须先理解 IDP 自助门户的核心架构。本章从蓝图（Blueprint）的定义出发，拆解门户的组件与工作流，并明确灰度发布在整体架构中的锚点位置。
2.1 蓝图（Blueprint）的定义与结构
Blueprint 是 IDP 中描述“环境应该如何被构建”的声明式模板。它定义了基础设施、中间件、应用部署和监控指标的完整拓扑。一个典型的 Blueprint 包含以下关键字段：
| 字段 | 类型 | 说明 |
|---|---|---|
name |
string | 蓝图唯一标识，如 microservice-canary |
version |
semver | 蓝图版本，用于灰度发布时的版本比对 |
components |
list | 包含的组件列表（K8s Deployment、Service、Ingress、PrometheusRule 等） |
dependencies |
map | 组件间的依赖关系（如：Service A 依赖 Redis） |
observability |
map | 预定义的 Prometheus 指标、告警规则、SLO 目标 |
policies |
list | 准入策略引用（如：必须通过灰度检查才能进入生产） |
实践要点：Blueprint 应存储在 Git 仓库中，通过 CI/CD 流水线进行版本管理。每次修改 Blueprint 都会触发新的版本号，灰度发布正是基于版本号差异进行流量切换。
2.2 自助门户的核心组件与工作流
IDP 自助门户由以下组件构成，它们协同完成从“开发者请求”到“环境就绪”的端到端流程：
- 门户前端（Portal UI）：开发者自助申请环境、选择 Blueprint 版本、查看发布状态。
- 编排引擎（Orchestrator）：接收请求，解析 Blueprint，调用底层基础设施 API 进行资源创建。
- 策略引擎（Policy Engine）：在资源创建/更新前执行准入检查，包括灰度发布准入检查。
- 监控适配层（Monitoring Adapter）：对接 Prometheus，实时拉取指标数据，供策略引擎决策。
- 状态存储（State Store）：记录所有环境、发布、策略执行的历史状态。
工作流如下：
- 开发者通过 Portal UI 选择 Blueprint 和版本，发起“创建环境”或“灰度发布”请求。
- Orchestrator 接收请求，将请求上下文（Blueprint 版本、目标集群、标签）传递给 Policy Engine。
- Policy Engine 根据预定义的准入规则（如：灰度发布必须满足 Prometheus 指标阈值）执行检查。
- 检查通过后，Orchestrator 调用基础设施 API 部署资源，并将结果写入 State Store。
- Monitoring Adapter 持续监控新环境的指标，反馈给 Portal UI 展示。
2.3 灰度发布在门户中的位置
灰度发布不是独立的功能模块，而是嵌入在策略引擎（Policy Engine）中的一个准入检查阶段。它在门户架构中的具体位置如下：
- 触发时机：当开发者通过 Portal UI 发起“灰度发布”请求时，Orchestrator 将请求路由到 Policy Engine。
- 执行阶段：Policy Engine 在资源创建/更新之前，调用灰度发布准入检查插件。
- 数据依赖：灰度检查需要从 Monitoring Adapter 获取当前环境的 Prometheus 指标（如错误率、延迟、CPU 使用率）。
- 决策输出：检查通过则继续部署；不通过则拒绝请求并返回详细原因（如“错误率超过 5% 阈值”）。
关键设计原则：灰度发布准入检查必须是无状态的、幂等的，且每次检查都基于最新的 Prometheus 指标数据。这保证了检查结果的可重复性和公平性。
2.4 灰度发布准入检查的输入与输出
灰度发布准入检查作为一个策略插件，其接口定义清晰：
| 维度 | 内容 |
|---|---|
| 输入 | Blueprint 版本号、目标环境标签、Prometheus 指标查询结果（如 http_requests_total、error_rate） |
| 检查规则 | 预定义的阈值（如：新版本错误率 ≤ 旧版本错误率的 1.2 倍）、持续时间（如：持续 5 分钟） |
| 输出 | 通过（允许部署）/ 拒绝（返回失败原因和指标快照） |
| 审计日志 | 每次检查的输入、规则、输出、时间戳均写入 State Store |
常见误区：灰度发布准入检查不应直接修改基础设施资源。它只做“检查”和“决策”，实际的资源创建/更新由 Orchestrator 执行。将检查与执行分离，是保持架构清晰和可扩展的关键。