4. 扫描队列概念：为什么需要扫描队列、队列模型（FIFO/优先级）、队列在CI/CD中的位置
在镜像供应链安全体系中，扫描队列是连接镜像构建与安全检测的流量缓冲层。当容器镜像以每分钟数百甚至数千个的速度涌入时，如果没有队列机制，Trivy 等扫描引擎将直接面临请求洪峰，导致服务雪崩、扫描结果丢失或数据库连接耗尽。本节从必要性、模型分类和 CI/CD 集成位置三个维度，系统阐述扫描队列的核心设计。
4.1 为什么需要扫描队列
扫描队列并非可有可无的中间件，而是保障扫描服务稳定性与可观测性的关键组件。以下四个场景直接说明其必要性：
| 场景 | 无队列时的问题 | 有队列时的效果 |
|---|---|---|
| 突发流量（CI 批量触发、夜间构建高峰） | 扫描引擎 CPU/内存瞬间飙高，请求超时或 OOM | 请求被平滑缓冲，引擎按自身吞吐量消费 |
| 扫描引擎故障（Trivy 服务重启、数据库连接中断） | 请求直接失败，丢失扫描任务 | 任务保留在队列中，引擎恢复后自动重试 |
| 资源配额控制（仓库配额已满、并发数超限） | 扫描请求被拒绝，用户无感知 | 队列返回排队状态，前端可展示等待位置 |
| 审计与回溯（需要排查某次扫描为何延迟） | 无历史记录，无法定位瓶颈 | 队列持久化任务日志，支持全链路追踪 |
容量水位视角： 扫描队列的长度和消费速率是衡量“扫描容量水位”的核心指标。当队列深度持续超过阈值（例如 > 1000），意味着扫描引擎的吞吐能力已无法匹配镜像生产速度，需要触发扩容或限流策略。
4.2 队列模型：FIFO 与优先级
扫描队列通常采用两种基础模型，实际生产环境常使用混合模型来平衡公平性与紧急度。
4.2.1 FIFO（先进先出）模型
严格按任务到达时间排序，先到先扫。适用于普通开发分支的镜像扫描，保证公平性，避免某个团队长期被插队。
- 优点： 实现简单，行为可预测，适合批量基线扫描。
- 缺点： 紧急漏洞（如 0-day）无法优先处理，可能被大量低优先级任务阻塞。
4.2.2 优先级模型
为每个扫描任务分配优先级标签（P0/P1/P2/P3），队列按优先级降序消费。适用于生产环境镜像或关键安全补丁的扫描。
- 优点： 紧急任务可跳过排队，快速获得扫描结果。
- 缺点： 低优先级任务可能长期饥饿，需要配合老化机制（Aging）。
4.2.3 混合模型（推荐）
结合 FIFO 与优先级，内部维护多个子队列，通过加权轮询或优先级配额调度。
| 优先级 | 典型场景 | 队列配额（示例） | 老化时间 |
|---|---|---|---|
| P0（紧急） | 生产环境镜像、CVE 严重漏洞修复 | 预留 20% 并发槽位 | 无老化，立即消费 |
| P1（高） | 预发布环境、合规扫描 | 占用 40% 槽位 | 超过 5 分钟提升至 P0 |
| P2（中） | 开发分支、非关键镜像 | 占用 30% 槽位 | 超过 15 分钟提升至 P1 |
| P3（低） | 历史镜像重扫、批量基线扫描 | 占用 10% 槽位 | 超过 30 分钟提升至 P2 |
避坑提示： 不要将优先级模型与 FIFO 模型完全隔离。如果 P0 队列持续有任务，P3 队列可能永远得不到服务。必须引入老化提升机制，确保低优先级任务在等待一定时间后自动升级。
4.3 队列在 CI/CD 中的位置
扫描队列通常部署在镜像推送完成之后、扫描结果入库之前，作为异步解耦的中间层。以下 SVG 图展示了队列在典型 CI/CD 流水线中的精确位置：
4.4 队列在 CI/CD 中的集成方式
根据团队规模和平台成熟度，扫描队列有三种常见的集成模式：
- 内嵌模式（小团队）： 队列直接运行在 CI Runner 节点上，使用内存队列（如 Go Channel 或 Python Queue）。适合每日镜像量 < 500 的场景。
- 中间件模式（中型团队）： 使用 Redis Streams 或 RabbitMQ 作为独立队列服务，CI 仅负责推送任务 ID，扫描 Worker 独立部署。适合每日镜像量 500~5000 的场景。
- 平台模式（大型团队）： 队列作为容器安全平台的内置模块，支持多租户隔离、优先级配额、老化策略和容量水位告警。适合每日镜像量 > 5000 的场景。
容量水位巡检集成： 在平台模式下，扫描队列的深度、消费速率、等待时间会作为“容量水位”指标，定期巡检并生成报告。当队列深度超过预设阈值（例如 2000）时，自动触发 Trivy Worker 扩容或向运维团队发送告警。
4.5 队列状态与监控指标
为了有效管理扫描队列，需要暴露以下关键指标到监控系统（Prometheus / Grafana）：
| 指标名称 | 类型 | 说明 | 告警阈值（示例） |
|---|---|---|---|
scan_queue_depth |
Gauge | 当前队列中等待扫描的任务数 | > 1000 触发 Warning |
scan_queue_latency_seconds |
Histogram | 任务从入队到开始扫描的等待时间 | P99 > 300s 触发 Critical |
scan_queue_priority_ratio |
Gauge | 各优先级任务占比（P0/P1/P2/P3） | P0 占比 > 50% 需扩容 |
scan_worker_utilization |
Gauge | Trivy Worker 的 CPU/内存使用率 | > 80% 触发扩容 |
通过上述指标，团队可以实时掌握扫描系统的健康状态和容量余量，在镜像供应链出现瓶颈前主动干预。