📚 课程目录第2章 Harbor架构深度解析

2. Harbor 架构深度解析：核心组件、数据流向与高可用设计

Harbor 作为企业级容器镜像仓库，其架构设计围绕多租户隔离、高并发推送/拉取以及跨站点复制三大核心需求展开。理解其内部组件协作关系，是进行灾备与加速方案设计的基础。

2.1 核心组件与职责

Harbor 采用微服务架构，主要包含以下 6 个核心组件，它们以 Docker Compose 或 Kubernetes 方式部署，协同完成镜像存储、认证、扫描与复制功能。

组件名称	容器名	核心职责	依赖关系
Proxy (Nginx)	`nginx`	统一入口，TLS 终止，路由分发，限流	所有外部请求必经
Core	`core`	API 网关、认证鉴权、RBAC、项目管理、Webhook	依赖 DB、Redis
Registry	`registry`	镜像 Blob 与 Manifest 存储（Docker Distribution）	依赖存储后端
JobService	`jobservice`	异步任务调度：复制、GC、扫描、回收	依赖 Core、Redis
Database	`database`	存储用户、项目、策略、元数据（PostgreSQL）	Core 与 JobService 共用
Redis	`redis`	缓存、任务队列、会话管理	Core 与 JobService 共用

架构要点：Registry 组件本身不感知 Harbor 的多租户策略，所有认证与鉴权由 Core 组件通过服务（基于 OAuth2）下发给 Docker 客户端，Registry 仅验证有效性。这种设计使得 Registry 可以保持与上游 Docker Distribution 兼容，降低升级风险。

2.2 数据流向：镜像推送与拉取全链路

以一次完整的 docker push 操作为例，数据流经 Proxy → Core → Registry 三个主要节点，期间涉及签发与 Blob 分片上传。

客户端发起请求：docker push myharbor.com/library/nginx:1.25 首先到达 Proxy (Nginx)。
请求：Proxy 将请求转发至 Core，Core 验证用户身份（密码或 Robot Account），生成一个临时，并附加允许的操作（push/pull）与目标项目（library）。
Blob 上传：客户端使用向 Registry 发起 Blob 分片上传（Monolithic 或 Chunked）。Registry 将数据写入后端存储（S3、GCS、NFS 或本地文件系统）。
Manifest 提交：所有 Blob 上传完成后，客户端提交 Manifest 文件（描述镜像层与配置）。Registry 验证 Manifest 完整性后存储，并返回成功。
Webhook 触发：Registry 通过 Notification 机制通知 Core 镜像推送完成。Core 可触发后续动作：更新数据库、触发镜像扫描、调用 JobService 执行复制策略。

  关键优化点：在跨地域灾备场景中，Blob 上传阶段是网络瓶颈。Harbor 支持 Proxy Cache 模式，允许远端 Registry 缓存 Blob，避免重复传输。同时，JobService 的复制任务支持 Chunked 传输与断点续传，提升跨数据中心同步效率。

2.3 高可用设计：多实例与共享存储

Harbor 的高可用架构核心原则是：无状态组件水平扩展，有状态组件共享后端。生产环境通常采用 Kubernetes 部署，利用其原生弹性伸缩能力。

2.3.1 无状态组件扩展

Proxy (Nginx)：可部署多副本，前端通过 Load Balancer（如 AWS NLB、K8s Ingress）分发流量。Nginx 配置中需开启 proxy_pass 到多个 Core 实例。
Core：无状态，多实例共享同一 PostgreSQL 与 Redis。所有实例通过相同的 core_secret 与 jobservice_secret 进行内部通信。
Registry：多实例部署，但必须共享同一存储后端（如 S3 Bucket）。Registry 实例之间通过 REGISTRY_STORAGE_DELETE_ENABLED 与 REGISTRY_STORAGE_MAINTENANCE_READONLY 等配置协调。
JobService：多实例通过 Redis 队列竞争任务，确保同一复制任务不会被重复执行。

2.3.2 有状态组件高可用

组件	高可用方案	注意事项
PostgreSQL	主从复制（Patroni/Stolon）或云托管 RDS	Harbor 配置中 `database.url` 需指向读写分离地址；Core 与 JobService 共用同一 DB
Redis	Sentinel 集群或云托管 Redis（如 AWS ElastiCache）	JobService 依赖 Redis 的 `BRPOP` 阻塞队列，需保证队列不丢失
镜像存储	S3/GCS 多区域复制（Cross-Region Replication）	Registry 配置 `REGISTRY_STORAGE_S3_REGION_ENDPOINT` 指向主区域；灾备切换时需更新配置

常见陷阱：直接对 Registry 实例做水平扩展而不共享存储，会导致客户端拉取时出现“Blob Not Found”错误，因为 Manifest 指向的 Blob 可能存储在另一个 Registry 实例的本地磁盘上。务必使用 S3/GCS 等对象存储作为统一后端。

2.4 灾备加速中的架构适配

在跨地域灾备场景中，Harbor 的架构需要额外关注以下三点：

复制策略调度：JobService 支持基于规则的定时复制或事件驱动复制。在灾备场景中，建议开启 事件驱动复制（镜像推送完成后立即触发），减少 RPO（恢复点目标）。
Proxy Cache 模式：在远端站点部署一个仅包含 Proxy 与 Registry 的轻量级实例，开启 REGISTRY_PROXY_REMOTEURL 指向主 Harbor。客户端从远端拉取时，Registry 自动从主站缓存 Blob，降低主站出口带宽压力。
存储多区域复制：如果使用 S3 作为后端，启用 S3 Cross-Region Replication（CRR），使得主站写入的 Blob 自动同步到灾备区域。Harbor 的 Registry 实例只需指向本地 S3 即可，无需跨区域读取。

  生产建议：在 AWS 环境中，推荐将 Harbor 部署在 EKS 上，使用 ElastiCache (Redis) + RDS (PostgreSQL) + S3 CRR 作为后端。JobService 的复制任务应配置为“覆盖”模式，确保灾备站点镜像与主站完全一致。同时，开启 Registry 的 REGISTRY_STORAGE_DELETE_ENABLED: true，配合 Harbor 的垃圾回收策略，避免存储空间膨胀。