1.1 Nexus 制品库简介
Nexus Repository（通常简称 Nexus）是由 Sonatype 公司开发的企业级制品管理平台，是 DevOps 工具链中存储、管理、分发二进制制品（如 JAR、WAR、Docker 镜像、npm 包、PyPI 包、NuGet 包等）的核心组件。它充当了“制品中央仓库”的角色，连接持续集成（CI）与持续部署（CD）流程，确保制品从构建到交付的完整可追溯性。
核心定位：Nexus 不是代码仓库（如 GitLab），也不是 CI/CD 引擎（如 Jenkins），而是专注于二进制制品的存储、版本管理、安全扫描与分发。它是 DevOps 中“构建产物”的唯一可信源。
1.1.1 核心功能矩阵
| 功能域 | 具体能力 | 说明 |
|---|---|---|
| 制品存储 | 多格式支持 | Maven/Gradle、npm、Docker、PyPI、NuGet、Raw、Yum、APT、Helm 等 30+ 格式 |
| 代理缓存 | 远程仓库代理 | 代理 Maven Central、npmjs.org、Docker Hub 等，缓存制品到本地，加速构建并减少外网依赖 |
| 仓库组 | 统一聚合入口 | 将多个 hosted（宿主）和 proxy（代理）仓库聚合成一个 group 仓库，客户端只需配置一个 URL |
| 安全与合规 | 漏洞扫描 + 策略 | 集成 Sonatype IQ Server，对制品进行已知漏洞（CVE）检测，支持自定义安全策略 |
| 高可用 | 集群部署 | 支持 Active/Active 或 Active/Standby 集群模式，通过共享 Blob Store（如 S3、NFS）实现数据一致性 |
| 审计与追溯 | 完整操作日志 | 记录所有制品的上传、下载、删除、覆盖操作，满足合规审计要求 |
1.1.2 在 DevOps 中的定位与价值
Nexus 在 DevOps 流水线中处于“承上启下”的关键位置。下图展示了 Nexus 在典型 DevOps 工具链中的核心定位：
1.1.3 仓库类型与使用场景
Nexus 提供三种核心仓库类型，理解它们的区别是配置高可用架构的基础：
| 仓库类型 | 用途 | 典型场景 | 高可用注意事项 |
|---|---|---|---|
| Hosted（宿主） | 存储组织内部发布的私有制品 | 团队内部 JAR 包、Docker 镜像、npm 私有包 | 需共享 Blob Store，确保集群节点数据一致 |
| Proxy（代理） | 代理并缓存远程公共仓库 | Maven Central、Docker Hub、PyPI 等 | 缓存数据存储在本地 Blob Store，集群节点共享 |
| Group（组） | 将多个 Hosted + Proxy 聚合成单一入口 | 开发者只需配置一个仓库 URL，Nexus 自动路由 | Group 本身无数据存储，依赖成员仓库的高可用 |
高可用关键认知：Nexus 高可用的核心挑战在于Blob Store 的共享与一致性。Hosted 仓库的写入操作必须同步到所有集群节点，而 Proxy 仓库的缓存数据也需要在节点间保持一致。本课程后续章节将深入讲解如何通过 S3、NFS 或数据库共享实现这一目标。
1.1.4 为什么选择 Nexus 作为高可用课程载体
- 市场占有率最高：Nexus 是企业级制品管理的事实标准，超过 70% 的 Fortune 500 公司使用 Nexus。
- 高可用架构成熟：支持 Active/Active 和 Active/Standby 两种模式，有完善的官方文档和社区实践。
- 故障场景丰富：从单节点宕机、Blob Store 损坏、数据库连接失败到网络分区，Nexus 的故障模式覆盖了分布式系统的大部分典型问题。
- 与 DevOps 工具链深度集成：Nexus 与 Jenkins、Kubernetes、Docker、Helm 等工具无缝对接，高可用切换直接影响整个交付流水线。
常见误区：很多团队认为 Nexus 高可用只需要“多部署几个实例”即可。实际上，Nexus 的集群模式对 Blob Store 的 I/O 性能、网络延迟、数据库事务一致性有严格要求。错误的配置可能导致数据损坏或制品丢失。本课程将逐一拆解这些陷阱。