2. 环境总览：基线核验环境的整体架构图、核心组件介绍
基线核验环境是平台门户下 Template 生成引擎上线前的关键验证环节。本章从整体架构出发，梳理 Portal、Template Engine、Verification Service 三大核心组件的职责与交互关系，为后续环境配置提供全局视角。
2.1 整体架构图
下图展示了基线核验环境的逻辑部署结构。用户请求经 Portal 进入，由 Template Engine 完成模板渲染与生成，最终由 Verification Service 执行基线比对与结果判定。三个组件通过内部 API 网关串联，数据流向清晰，便于故障定位与性能观测。
2.2 核心组件介绍
三个组件各司其职，共同构成基线核验的闭环。下表从职责、关键能力、依赖关系三个维度进行对比。
| 组件 | 核心职责 | 关键能力 | 主要依赖 |
|---|---|---|---|
| Portal | 用户交互入口，任务提交与结果展示 | 模板上传、参数配置、任务状态跟踪、报告下载 | 内部 API 网关、用户认证服务 |
| Template Engine | 模板解析与渲染，生成待核验产物 | 多模板格式支持（Jinja2 / FreeMarker）、数据绑定、渲染缓存 | 配置中心、模板存储（MinIO / Git） |
| Verification Service | 基线比对与核验判定 | 基线版本管理、差异计算、通过/失败判定、报告生成 | 基线库（MySQL / 对象存储）、消息队列 |
2.3 组件交互流程
一次完整的基线核验任务包含以下步骤，每个步骤对应一个组件的主要操作：
- 任务提交：用户在 Portal 中选择模板版本、输入参数，提交核验请求。
- 模板渲染：Template Engine 接收请求，加载模板文件，绑定参数，生成渲染产物（如 YAML / JSON / 配置文件）。
- 产物传递：渲染产物通过内部 API 网关转发至 Verification Service，同时附带任务 ID 与基线版本号。
- 基线比对：Verification Service 根据基线版本号加载对应基线文件，执行逐字段或结构化比对。
- 结果回写：比对完成后，Verification Service 将结果（通过 / 失败 / 差异详情）写入数据库，并通过回调通知 Portal。
- 报告展示：Portal 轮询或接收回调后，展示核验报告，支持差异高亮与导出。
实践建议：在环境配置阶段，建议先启动 Verification Service 并初始化基线库，再启动 Template Engine，最后启动 Portal。这样可以避免组件启动顺序不当导致的任务积压或回调丢失。
2.4 组件通信与数据流
下图聚焦组件间的数据流与通信协议，帮助理解各接口的输入输出格式。
2.5 组件配置清单
在环境配置阶段，需要为每个组件准备以下核心配置项。建议使用配置中心（如 Nacos / Consul）统一管理，避免硬编码。
| 组件 | 配置项 | 示例值 | 说明 |
|---|---|---|---|
| Portal | server.port | 8080 | HTTP 服务端口 |
| gateway.endpoint | http://api-gateway:8081 | 内部 API 网关地址 | |
| auth.service.url | http://auth-service:8082 | 用户认证服务地址 | |
| Template Engine | template.storage.type | minio | 模板存储类型（minio / git） |
| template.storage.bucket | templates | MinIO Bucket 名称 | |
| engine.cache.ttl | 300 | 渲染缓存过期时间（秒） | |
| Verification Service | baseline.db.url | jdbc:mysql://baseline-db:3306/verify | 基线数据库连接 |
| baseline.version.retention | 10 | 保留的基线版本数量 | |
| report.output.path | /data/reports | 核验报告输出目录 |
注意：在配置共享存储层时，请确保 MinIO 或 MySQL 的访问凭证（accessKey / secretKey / 用户名密码）通过 Kubernetes Secret 或 Vault 注入，不要明文写在配置文件中。