2. Harbor 架构解析：核心组件与整体架构

Harbor 采用微服务架构设计，将制品管理、安全扫描、复制、认证等能力拆分为独立的组件，通过 API 网关统一对外暴露服务。理解每个组件的职责与交互关系，是制定保留策略和清理窗口的前提——因为策略的执行引擎（Jobservice）与制品存储（Registry）之间的协作方式，直接决定了清理任务的调度粒度与执行效率。

2.1 整体架构图

下图展示了 Harbor 各组件之间的核心交互关系。用户请求首先到达 Nginx 反向代理，由 Core 服务进行认证与路由，Registry 负责制品存储，Jobservice 执行异步任务（包括清理与复制），ChartMuseum 管理 Helm Chart，Trivy 提供漏洞扫描能力。

2.2 核心组件详解

组件	职责	与保留策略/清理窗口的关系
Core 服务	认证、授权、项目管理、API 路由、Webhook 触发	提供保留策略的配置 API，存储策略规则到数据库
Registry	Docker V2 / OCI 制品存储，支持清单、层、标签	清理操作的目标组件，Jobservice 通过 Registry API 删除制品
Jobservice	异步任务调度与执行，支持重试、超时、并发控制	保留策略的执行引擎，负责调度清理任务和 GC
ChartMuseum	Helm Chart 的存储、版本管理、上传/下载	保留策略可针对 Chart 版本进行清理
Trivy 扫描器	容器镜像漏洞扫描，生成 CVE 报告	扫描结果可作为保留策略的过滤条件（如“保留无高危漏洞的镜像”）
PostgreSQL / Redis	元数据存储、任务队列、缓存	存储策略规则、任务状态、制品元数据
Nginx 反向代理	请求路由、TLS 终止、速率限制	不直接参与清理，但影响清理 API 的访问控制

2.3 组件交互流程（以保留策略执行为例）

1. 策略配置：管理员通过 Harbor UI 或 API 在 Core 服务中创建保留策略（如“保留最近 30 天的镜像”）。
2. 策略存储：Core 将策略规则写入 PostgreSQL 数据库。
3. 任务调度：Core 根据策略的定时规则（cron）或手动触发，向 Jobservice 提交清理任务。
4. 任务执行：Jobservice 从数据库读取策略规则，调用 Registry API 查询制品列表，筛选出符合清理条件的制品。
5. 制品删除：Jobservice 调用 Registry 的删除 API（DELETE /v2/<name>/manifests/<reference>）移除清单和层。
6. 垃圾回收（GC）：清理任务完成后，Jobservice 触发 Registry 的 GC 流程，回收未被引用的存储层。
7. 状态更新：Jobservice 将执行结果写回数据库，Core 服务通过 API 返回给用户。

2.4 组件部署拓扑

Harbor 支持多种部署模式，不同模式下组件的分布方式会影响清理任务的执行路径：

部署模式	组件分布	对清理的影响
单节点（默认）	所有组件运行在同一 Docker 主机上	清理任务本地执行，延迟最低
高可用（HA）	Core / Jobservice 多副本，Registry 共享存储	Jobservice 多实例需协调清理任务，避免重复删除
分布式（跨地域）	每个地域独立部署，通过复制同步制品	保留策略需在每个地域单独配置，清理窗口需考虑网络延迟

2.5 组件间通信协议

• Core ↔ Registry：通过 Registry 的 REST API（HTTP/HTTPS），使用 JWT 认证。
• Core ↔ Jobservice：通过内部 gRPC 或 HTTP API，传递任务定义和状态。
• Jobservice ↔ Registry：直接调用 Registry API，无需经过 Core。
• Core ↔ Database：通过 GORM（Go ORM）操作 PostgreSQL。
• Jobservice ↔ Redis：使用 Redis 作为任务队列（如 redis:// 协议）。

2.6 组件配置关键参数（与清理相关）

# harbor.yml 中与清理相关的配置片段

# Jobservice 配置
jobservice:
  max_job_workers: 10          # 最大并发清理任务数
  job_logger_severity: INFO    # 任务日志级别，调试时可改为 DEBUG

# Registry 配置
registry:
  storage:
    delete:
      enabled: true            # 必须为 true，否则无法删除制品
    maintenance:
      uploadpurging:
        enabled: true          # 自动清理未完成的上传
  gc:
    enabled: true              # 启用垃圾回收
    interval: 24h              # GC 执行间隔

# 数据库连接
database:
  type: postgresql
  max_idle_conns: 50
  max_open_conns: 100