4. 仓库类型与格式：Proxy仓库、Hosted仓库、Group仓库的概念与适用场景，Blob Store与存储策略
Nexus Repository Manager 的核心能力建立在三种仓库类型之上：Proxy（代理）、Hosted（托管） 和 Group（组）。理解这三者的职责与协作关系，是设计高效制品分发体系的基础。同时，Blob Store 作为底层存储引擎，直接决定了制品的存取性能与容量规划。
4.1 三种仓库类型的概念与适用场景
每种仓库类型对应一种特定的制品管理职责。下表从核心功能、数据流向和典型用例三个维度进行对比：
| 仓库类型 | 核心功能 | 数据流向 | 典型适用场景 |
|---|---|---|---|
| Proxy（代理仓库） | 缓存远程仓库（如 Maven Central、npmjs.org）的制品，减少重复下载，提升本地构建速度。 | 客户端 → Nexus Proxy → 远程源（缓存后直接返回） | 隔离外网环境、加速跨地域拉取、统一管控外部依赖版本。 |
| Hosted（托管仓库） | 存储组织内部发布的私有制品（如二方库、内部工具包、Docker 镜像）。 | 客户端 → Nexus Hosted（上传/下载） | 内部制品发布、快照版本管理、合规性审批后的制品归档。 |
| Group（组仓库） | 将多个 Proxy 和 Hosted 仓库聚合为一个统一入口，客户端只需配置一个 URL。 | 客户端 → Group → 按成员顺序查找（先 Hosted 后 Proxy） | 简化客户端配置、实现多源合并、灰度切换仓库成员。 |
实践建议： 在微服务架构中，建议为每个制品格式（如 Maven、npm、Docker）至少创建一个 Group 仓库，并将对应的 Hosted 仓库和 Proxy 仓库作为其成员。这样，开发者只需配置一个 Group URL，即可同时访问内部制品和外部缓存。
4.2 仓库协作流程（SVG 架构图）
下图展示了三种仓库类型在典型 CI/CD 流水线中的协作关系：
关键流程说明：
- 客户端（如 Maven、npm、Docker 客户端）只配置 Group 仓库的 URL。
- Group 仓库按成员顺序查找：先检查 Hosted 仓库（内部制品），再检查 Proxy 仓库（外部缓存）。
- 如果 Proxy 仓库中未命中，则从远程源下载并缓存到本地，后续请求直接返回缓存。
- 整个流程对客户端透明，实现“一次配置，多源聚合”。
4.3 Blob Store 与存储策略
Blob Store 是 Nexus 的物理存储抽象层，负责将制品以二进制大对象（Blob）的形式持久化到文件系统或云存储中。每个仓库必须关联一个 Blob Store，且一个 Blob Store 可被多个仓库共享。
4.3.1 Blob Store 类型对比
| 存储类型 | 底层实现 | 适用场景 | 性能特点 |
|---|---|---|---|
| File（文件系统） | 本地磁盘目录（如 /nexus-data/blobs） | 单机部署、开发测试环境、小规模团队 | 低延迟，受磁盘 I/O 限制 |
| S3（对象存储） | AWS S3 或兼容 S3 的存储（如 MinIO） | 分布式部署、高可用架构、异地容灾 | 高吞吐，网络延迟略高于本地磁盘 |
| Azure Blob | Azure Blob Storage | Azure 云原生环境 | 与 Azure 生态深度集成 |
| Google Cloud Storage | GCS 存储桶 | GCP 云原生环境 | 与 GCP 生态深度集成 |
4.3.2 存储策略配置要点
在创建或编辑 Blob Store 时，需要关注以下关键参数：
- 路径（Path）：文件系统 Blob Store 的根目录，建议使用独立磁盘或挂载点，避免与系统盘争抢 I/O。
- 软配额（Soft Quota）：当 Blob Store 使用量达到该阈值时，Nexus 会记录警告日志，但不会阻止写入。建议设置为总容量的 80%。
- 硬配额（Hard Quota）：达到该阈值后，Nexus 将拒绝新的写入请求，直到清理空间或扩容。建议设置为总容量的 95%。
- 清理策略（Cleanup Policy）：可配置基于最后访问时间或下载次数的自动清理规则，用于回收过期快照或未使用的制品。
性能避坑： 不要将多个 Blob Store 指向同一个物理磁盘的不同子目录，这会导致 I/O 竞争。建议为高频访问的仓库（如 Docker 或 npm 的 Proxy 仓库）分配独立的 Blob Store 和物理磁盘。对于 S3 类型的 Blob Store，务必启用 多部分上传（Multipart Upload） 以提升大文件（>100MB）的写入性能。
4.4 Blob Store 与仓库的关联关系（SVG 结构图）
下图展示了 Blob Store 如何作为存储层支撑不同仓库类型：
存储策略最佳实践：
- 高频访问仓库（如 Maven Proxy、npm Proxy）→ 分配 SSD 类型的 Blob Store，降低拉取延迟。
- 大文件仓库（如 Docker Hosted、Raw Hosted）→ 分配 HDD 或 S3 类型的 Blob Store，平衡成本与容量。
- 冷数据归档→ 使用 S3 或 Azure Blob 的冷存储层，配合清理策略自动迁移不活跃制品。
- 配额监控→ 为每个 Blob Store 配置软配额和硬配额，并通过 Nexus 的 Prometheus 指标接口（/metrics）接入监控告警。
4.5 仓库格式与 Blob Store 的映射关系
Nexus 支持多种制品格式（Maven、npm、Docker、PyPI、Raw 等），每种格式的仓库在创建时必须指定其仓库类型和关联的 Blob Store。以下是一个典型的映射示例：
| 制品格式 | 仓库名称 | 仓库类型 | 关联 Blob Store | 存储策略说明 |
|---|---|---|---|---|
| Maven | maven-central-proxy | Proxy | blob-store-ssd-01 | 缓存外部依赖，SSD 加速构建 |
| Maven | maven-releases | Hosted | blob-store-hdd-01 | 存储正式发布版本，HDD 大容量 |
| Maven | maven-snapshots | Hosted | blob-store-hdd-01 | 存储快照版本，配合清理策略 |
| Maven | maven-public | Group | （无，仅聚合） | 聚合 releases、snapshots、proxy |
| Docker | docker-hub-proxy | Proxy | blob-store-ssd-02 | 缓存 Docker Hub 镜像 |
| Docker | docker-private | Hosted | blob-store-s3-01 | 存储私有镜像，S3 实现高可用 |
| npm | npmjs-proxy | Proxy | blob-store-ssd-01 | 缓存 npm 包 |
| npm | npm-private | Hosted | blob-store-hdd-02 | 存储内部 npm 包 |
核心结论：
- Proxy 仓库 解决外部依赖的缓存与加速问题，是降低出口带宽和提升构建速度的关键。
- Hosted 仓库 承载内部制品的发布与版本管理，是组织资产的核心存储。
- Group 仓库 提供统一入口，简化客户端配置，是实现多源透明合并的桥梁。
- Blob Store 是存储性能与容量的基础，合理的存储策略（SSD/HDD/S3 + 配额 + 清理）直接影响 Nexus 的整体吞吐和可用性。