2. Nexus仓库基础架构：仓库类型、存储后端与组件资产模型
在规划代理缓存容量之前，必须深入理解Nexus仓库的三种核心仓库类型、底层存储抽象层（Blob Store）以及组件与资产的数据模型。这三者共同决定了制品在仓库中的生命周期、存储位置与访问路径，是误差预算台账计算的基础。
2.1 仓库类型：Hosted / Proxy / Group
Nexus Repository Manager 将仓库分为三种逻辑类型，每种类型承担不同的职责，直接影响缓存策略与容量消耗。
| 仓库类型 | 职责 | 数据来源 | 缓存行为 | 容量规划关注点 |
|---|---|---|---|---|
| Hosted（托管） | 存储组织内部发布的制品 | CI/CD 流水线、开发者手动上传 | 无缓存，数据永久保留 | 存储容量按发布频率与制品大小线性增长 |
| Proxy（代理） | 代理远程公共仓库（如 Maven Central、Docker Hub） | 远程源站 | 按需拉取并缓存到本地 Blob Store | 缓存命中率、过期策略、磁盘水位 |
| Group（组合） | 将多个 Hosted 和 Proxy 仓库聚合为单一访问端点 | 成员仓库 | 无独立存储，路由请求到成员仓库 | 路由顺序、成员仓库的容量叠加 |
容量规划要点： Proxy 仓库是缓存容量规划的核心对象。Hosted 仓库的容量通常由组织内部发布速率决定，而 Group 仓库本身不消耗额外存储，但需要关注其成员仓库的容量总和。
2.2 存储后端：Blob Store 架构
Blob Store 是 Nexus 的物理存储抽象层，它将制品的二进制内容与元数据分离存储。所有仓库类型（Hosted、Proxy、Group）最终都将制品内容写入 Blob Store。
- 文件系统 Blob Store（默认）：将制品以文件形式存储在操作系统的文件系统中，支持软链接与硬链接优化。
- S3 Blob Store：将制品存储在 AWS S3 或兼容 S3 的对象存储中，适合大规模、高可用场景。
- Azure Blob Store：将制品存储在 Azure Blob Storage 中，适用于 Azure 云环境。
- Google Cloud Storage Blob Store：将制品存储在 GCS 中，适用于 GCP 环境。
最佳实践： 对于代理缓存场景，推荐使用文件系统 Blob Store 并启用硬链接去重（Deduplication），可显著降低重复制品的存储开销。S3 或云 Blob Store 适合需要跨区域复制或弹性扩展的场景，但需注意网络延迟对缓存命中响应时间的影响。
每个 Blob Store 由以下核心属性构成：
| 属性 | 说明 | 容量规划影响 |
|---|---|---|
| Blob Store 名称 | 唯一标识，关联到仓库 | 命名规范影响运维可观测性 |
| 存储路径 | 文件系统或云存储的根目录 | 磁盘挂载点或 Bucket 的配额限制 |
| 软配额（Soft Quota） | 达到阈值时触发告警 | 建议设置为总容量的 80% |
| 硬限制（Hard Limit） | 达到后拒绝写入 | 必须预留 10-15% 余量防止写入失败 |
2.3 组件与资产模型
Nexus 使用“组件（Component）”与“资产（Asset）”两层模型来管理制品。理解这一模型对于计算缓存命中率、存储占用以及误差预算至关重要。
- 组件（Component）：制品的逻辑实体，包含坐标信息（如 groupId、artifactId、version）、元数据（如 POM 文件、标签）。一个组件可以包含多个资产。
- 资产（Asset）：组件的物理文件实体，是实际存储在 Blob Store 中的二进制内容。每个资产有唯一的路径和校验和。
常见误区： 在容量规划时，仅统计组件数量会严重低估存储消耗。一个组件（如一个 Docker 镜像）可能包含多个资产（多个层文件 + 清单文件）。必须按资产的实际大小和数量进行预算。
组件与资产的典型关系示例（以 Maven 制品为例）：
| 组件坐标 | 资产路径 | 资产类型 | 大小 |
|---|---|---|---|
| com.example:my-lib:1.0.0 | /com/example/my-lib/1.0.0/my-lib-1.0.0.jar | 主 Jar | 2.3 MB |
| /com/example/my-lib/1.0.0/my-lib-1.0.0.pom | POM 文件 | 4 KB | |
| /com/example/my-lib/1.0.0/my-lib-1.0.0-sources.jar | 源码 Jar | 1.1 MB |
在 Proxy 仓库中，组件与资产的缓存状态由以下属性决定：
- last_downloaded：资产最后一次被请求的时间，用于判断冷数据。
- last_verified：组件元数据最后一次与远程源站校验的时间，影响缓存一致性。
- blob_ref：资产在 Blob Store 中的物理引用，用于硬链接去重。
- content_type：资产的 MIME 类型，影响压缩与传输策略。
2.4 仓库类型与 Blob Store 的映射策略
在实际部署中，建议按以下策略映射仓库与 Blob Store，以优化缓存容量管理：
| 场景 | 推荐 Blob Store 类型 | 原因 |
|---|---|---|
| 高频访问的 Proxy 仓库（如 Maven Central） | 文件系统（SSD） | 低延迟、高 IOPS，适合频繁的缓存命中读取 |
| 大规模冷数据 Proxy 仓库（如 Docker Hub） | S3 / 对象存储 | 低成本、弹性扩展，适合不常访问的层文件 |
| 内部 Hosted 仓库（发布频繁） | 文件系统（HDD） | 顺序写入为主，HDD 性价比高 |
| Group 仓库 | 不直接关联 Blob Store | 路由到成员仓库，成员仓库各自关联 Blob Store |