2. Harbor 架构与组件：核心组件、复制策略位置与数据流向
理解 Harbor 的架构是掌握复制策略的前提。本章从核心组件、复制策略在架构中的位置以及数据流向三个维度，为你建立完整的架构认知。
2.1 Harbor 核心组件一览
Harbor 采用微服务架构，各组件以 Docker Compose 或 Helm Chart 方式部署。下表列出核心组件及其职责：
| 组件名称 | 容器名 | 核心职责 | 复制策略相关 |
|---|---|---|---|
| nginx | nginx | 反向代理、TLS 终结、请求路由 | 复制流量入口，分发到 core 或 registry |
| Harbor Core | core | API 服务、认证授权、项目管理、Webhook | 复制策略的 CRUD 入口，触发复制任务 |
| Registry | registry | 镜像存储（基于 Docker Distribution） | 复制源端和目标端的存储层 |
| Jobservice | jobservice | 异步任务调度、复制任务执行、重试与状态管理 | 复制策略的实际执行引擎 |
| Database (PostgreSQL) | database | 元数据存储：项目、用户、策略、任务记录 | 持久化复制策略配置与执行历史 |
| Redis | redis | 缓存、任务队列、会话管理 | Jobservice 的任务队列后端 |
| Trivy / Clair | trivy-adapter | 镜像漏洞扫描 | 复制时可触发扫描校验（可选） |
| Harbor Exporter | exporter | Prometheus 指标暴露 | 监控复制任务指标 |
架构要点：Jobservice 是复制策略的“心脏”，所有复制任务都在此异步执行。Core 只负责策略定义和触发，不参与实际数据传输。
2.2 复制策略在架构中的位置
复制策略并非独立服务，而是横跨多个组件的协作流程。下图展示了复制策略在 Harbor 架构中的位置与交互关系：
关键结论：复制策略的“控制面”由 Core + Database 构成，“数据面”由 Jobservice + Registry 构成。两者通过 Jobservice 的任务队列解耦，实现异步、可重试的跨环境复制。
2.3 复制策略数据流向图
当复制任务被触发后，数据在组件间的具体流向如下。我们以“从源 Harbor 实例复制到目标 Harbor 实例”为例：
2.4 组件间通信协议与端口
了解组件间的通信方式，有助于排查复制策略的网络问题：
| 源组件 | 目标组件 | 协议 | 默认端口 | 用途 |
|---|---|---|---|---|
| Client / CI | nginx | HTTPS | 443 | 外部访问入口 |
| nginx | Core | HTTP | 8080 | API 请求转发 |
| nginx | Registry | HTTP | 5000 | 镜像 push/pull 转发 |
| Core | Jobservice | HTTP | 8080 | 下发复制任务 |
| Jobservice | 源 Registry | HTTPS | 443 | 拉取镜像 Blob |
| Jobservice | 目标 Registry | HTTPS | 443 | 推送镜像 Blob |
| Jobservice | Redis | TCP | 6379 | 任务队列 |
| Core / Jobservice | PostgreSQL | TCP | 5432 | 元数据读写 |
常见陷阱：跨环境复制时，Jobservice 所在节点必须能直接访问源和目标 Registry 的 HTTPS 端口（通常 443）。如果中间有防火墙或代理，需提前开放网络策略。另外，目标 Registry 的
storage 配置必须支持并发写入，否则复制大镜像时可能超时。
2.5 复制策略的三种触发模式
Harbor 支持以下触发模式，对应不同的数据流向起点：
- 手动触发：管理员在 UI 或 API 中点击“复制”，Core 立即创建任务。
- 定时触发：基于 Cron 表达式，由 Jobservice 内部定时器触发，无需外部干预。
- 事件驱动（Webhook）：源 Harbor 的 Registry 收到新镜像 push 后，通过 Webhook 通知 Core，Core 再触发复制任务。这是最常用的“实时同步”模式。
生产建议：跨环境校验场景推荐使用“事件驱动”模式，配合目标端的镜像签名或扫描策略，实现“推完即校验”的自动化流水线。