2. Harbor 架构解析：组件、数据流向与高可用设计
在生产环境中运行 Harbor 镜像仓库，理解其内部组件协作关系、数据流向以及高可用部署模式是实施自动归档与清理工程的前提。本章从组件职责、请求路径、存储交互三个维度拆解 Harbor 架构，并给出高可用设计的核心要点。
2.1 核心组件与职责
Harbor 采用微服务架构，主要包含以下 6 个核心组件，它们以 Docker Compose 或 Kubernetes Pod 的形式运行：
| 组件名称 | 容器/进程名 | 核心职责 | 依赖关系 |
|---|---|---|---|
| Core | harbor-core | API 网关、认证鉴权、项目管理、RBAC、Webhook 触发 | 依赖 Database、Redis |
| Registry | registry | Docker 镜像存储与分发（基于 OCI Distribution Spec） | 依赖存储后端（S3/NFS/MinIO） |
| Jobservice | harbor-jobservice | 异步任务调度：镜像复制、GC 清理、扫描、标签清理 | 依赖 Core、Redis、Database |
| Portal | harbor-portal | Web UI 前端，提供用户操作界面 | 依赖 Core（API 调用） |
| Database | harbor-db | PostgreSQL，存储元数据：项目、用户、标签、策略、审计日志 | — |
| Redis | redis | 缓存会话、任务队列、Webhook 事件暂存 | — |
工程提示： 在自动归档与清理场景中，Jobservice 是最关键的组件。所有定时清理策略、镜像复制任务、标签保留规则均由 Jobservice 调度执行。若 Jobservice 异常，清理任务将停止，存储可能持续膨胀。
2.2 组件协作与数据流向
下图展示了 Harbor 内部一次完整的镜像推送与清理触发流程，包含控制流与数据流两条路径：
数据流向关键路径：
- 推送路径： 客户端 → Core（认证） → Registry（存储 Blob） → Database（记录元数据）。
- 清理路径： Core（策略触发） → Jobservice（调度） → Registry（删除 Blob） → Database（更新元数据） → 存储后端（释放空间）。
- Webhook 路径： Registry 事件 → Core → Jobservice → 外部系统（如通知、自动归档触发）。
2.3 高可用设计要点
生产环境必须消除单点故障。Harbor 官方支持两种高可用模式：多实例主备（基于外部数据库与共享存储）和 Kubernetes 原生部署（Operator）。以下为关键设计原则：
| 层级 | 组件 | 高可用策略 | 注意事项 |
|---|---|---|---|
| 接入层 | Core / Portal | 多副本 + 负载均衡（Nginx/HAProxy） | Session 需共享 Redis；CSRF 需一致 |
| 任务层 | Jobservice | 多副本 + Redis 任务队列 | 同一任务仅被一个 Worker 消费；需幂等设计 |
| 存储层 | Registry | 共享存储后端（S3/MinIO/NFS） | 避免使用本地文件系统；S3 需开启版本控制防误删 |
| 数据层 | Database | PostgreSQL 主从复制或云托管 RDS | 自动故障切换；连接池配置合理 |
| 缓存层 | Redis | Redis Sentinel 或 Cluster | 持久化策略 RDB + AOF；避免大 Key |
常见陷阱：
- 多 Core 实例共用同一 Redis 时，若 Redis 未配置密码或网络隔离不足，可能导致会话串号。
- Jobservice 多副本下，清理任务可能重复执行。需在清理脚本中实现幂等性（如先检查 Blob 是否已被删除）。
- 共享存储使用 NFS 时，需注意 NFS 锁与并发写入问题，建议切换为 S3 兼容对象存储。
2.4 高可用部署架构示意
以下为基于 Kubernetes 的 Harbor 高可用部署逻辑架构，展示组件副本与外部依赖关系：
工程建议： 在自动归档场景中，建议将 Jobservice 的副本数设置为 2 以上，并配置独立的 Redis 队列。这样即使一个 Worker 正在执行长时间的大镜像清理任务，另一个 Worker 仍可响应新的归档请求，避免任务积压。
2.5 架构对自动归档与清理的影响
理解架构后，可以明确以下设计约束：
- 清理任务必须通过 Jobservice 调度，不能直接操作 Registry 或存储后端，否则会导致元数据不一致。
- 高可用环境下，清理策略配置（如标签保留规则）存储在 Database 中，所有 Core 实例共享同一份配置，无需重复设置。
- 存储后端必须支持并发读写，否则多 Registry 副本同时执行 GC 时可能产生冲突。推荐使用 S3 兼容对象存储，并开启
--delete-untagged选项。 - Webhook 通知 可用于触发外部归档流程：当镜像被删除或标签变更时，Core 通过 Webhook 通知归档服务将镜像备份到冷存储。
架构决策清单（自动归档与清理场景）：
| 决策项 | 推荐方案 | 理由 |
|---|---|---|
| 存储后端 | S3 / MinIO | 支持并发、版本控制、生命周期管理 |
| 清理触发方式 | Harbor 内置标签保留规则 + Webhook | 避免外部脚本直接操作 API 导致竞态 |
| Jobservice 副本数 | ≥2 | 保证清理任务不因单点故障中断 |
| 数据库 | 托管 RDS 或 PostgreSQL 主从 | 自动备份、故障切换、读写分离 |