2. Registry 架构基础：Docker Registry 与 Harbor 的架构对比，存储后端选型

镜像拉取性能的起点在于 Registry 自身的架构设计。不同的 Registry 实现决定了并发处理能力、存储扩展性以及网络路径的优化空间。本节从 Docker Registry（开源版）与 Harbor（企业级扩展）的架构差异入手，并深入分析存储后端对拉取性能的影响。

2.1 Docker Registry 架构：轻量但功能有限

Docker Distribution（即开源 Docker Registry）采用 无状态 API 层 + 共享存储后端 的简洁架构。其核心组件包括：

• API Handler：处理 manifest、blob、tag 等 RESTful 请求，不维护本地状态。
• Authentication Middleware：可选，支持 或 Basic Auth，但无内置用户管理。
• Storage Driver：抽象层，对接本地文件系统、S3、GCS、Azure Blob 等后端。
• GC（Garbage Collection）：离线工具，需手动触发清理未引用的 blob。

2.2 Harbor 架构：企业级增强

Harbor 在 Docker Registry 之上增加了完整的权限管理、复制、漏洞扫描和审计功能。其架构分层更复杂：

• Proxy Layer（Nginx）：统一入口，TLS 终止，请求路由，限流。
• Core Service：管理项目、用户、策略、Webhook，提供 UI 和 API。
• Registry（Docker Distribution）：核心镜像存储与分发，与开源版一致。
• Database（PostgreSQL）：存储元数据、用户信息、标签、复制策略。
• Job Service：异步执行复制、GC、扫描等任务。
• Storage Backend：与 Docker Registry 共享同一存储抽象层。

2.3 架构对比：Docker Registry vs Harbor

2.4 存储后端选型：S3、GCS 与本地 FS

存储后端是镜像拉取性能的 最大瓶颈。Blob 的读取延迟、吞吐量、并发能力直接决定拉取速度。以下是三种主流后端的对比：

2.5 存储后端架构对比图

下图展示了三种存储后端在 Registry 架构中的位置与数据流差异：

2.6 存储后端选型决策流程

根据集群规模、网络环境和性能要求，可参考以下决策步骤：

1. 评估并发拉取量：如果单 Registry 实例需要支撑 100+ 节点同时拉取，优先选择 S3/GCS 对象存储。
2. 评估网络延迟：Registry 与存储后端之间的网络延迟应 < 5ms（同区域），否则考虑本地 FS 或部署边缘缓存。
3. 评估数据持久性需求：生产环境必须使用对象存储或分布式文件系统（如 Ceph），避免本地 FS 单点故障。
4. 评估成本：对象存储按请求计费，高频拉取场景下请求费用可能超过存储费用，需结合缓存策略优化。
5. 评估运维复杂度：本地 FS 最简单，但扩展和备份困难；S3/GCS 运维成本低，但需配置 IAM 权限和网络策略。

2.7 存储后端配置示例

以下展示 Docker Registry 配置文件中不同存储后端的配置片段：

# 本地文件系统
storage:
  filesystem:
    rootdirectory: /var/lib/registry

# AWS S3
storage:
  s3:
    accesskey: YOUR_ACCESS_KEY
    secretkey: YOUR_SECRET_KEY
    region: us-east-1
    bucket: my-registry-bucket
    encrypt: true
    secure: true
    v4auth: true
    rootdirectory: /registry/v2

# Google GCS
storage:
  gcs:
    bucket: my-registry-bucket
    keyfile: /path/to/service-account.json
    rootdirectory: /registry/v2
    chunksize: 5242880  # 5MB 分块大小，影响上传性能