Sonatype Nexus Repository Manager —— 详细、系统性介绍

一、Nexus 的本质定位（先给结论）

Nexus 是企业级“制品仓库（Artifact Repository）与依赖治理平台”。

它处在源码管理（Git）与运行环境（服务器 / K8s / Docker）之间，负责：

• 统一管理构建产物
• 统一代理第三方依赖
• 保证构建可复现、可追溯、可审计
• 为CI/CD提供稳定、高性能的依赖与制品来源

一句话总结：

Git 管源码，Nexus 管“编译后的结果”和“依赖”。

二、为什么“必须”要有 Nexus（工程视角）

1️⃣ 没有 Nexus 时的真实问题

在中大型团队或内网环境中，常见痛点包括：

• Maven / npm / NuGet 每次从公网拉依赖
• 构建速度慢、失败率高
• 公网仓库不可控（被删包、被污染）
• 私有包只能靠手动拷贝
• Docker 镜像分散在各台机器
• 历史版本不可回溯，无法审计

2️⃣ Nexus 的根本价值

三、Nexus 支持的仓库格式（技术全景）

Nexus 是多生态统一制品仓库，常见支持包括：

👉一个 Nexus，覆盖你 90% 的工程依赖管理需求。

四、三种核心仓库类型（必须理解）

1️⃣ Proxy Repository（代理仓库）

作用：代理公网仓库 + 本地缓存

• Maven Central
• npmjs.org
• NuGet.org
• Docker Hub

机制：

第一次请求 → 访问公网 → 缓存到 Nexus 后续请求 → 直接走 Nexus

价值：

• 提速
• 断网可构建
• 防止依赖“消失”

2️⃣ Hosted Repository（私有仓库）

作用：存你们“自己发布”的包

典型用途：

• 内部 Java SDK
• 私有 NuGet 包
• 公司 npm 组件库
• 内部 Docker 镜像

特征：

• 只允许内部发布
• 版本应不可覆盖
• 是企业知识资产的一部分

3️⃣ Group Repository（聚合仓库）

作用：把多个仓库合并成一个入口

例如 Maven：

maven-group ├─ maven-central-proxy ├─ maven-private-hosted └─ maven-thirdparty-proxy

开发者只需要配置一个地址。

五、Nexus 在 CI/CD 中的核心位置

标准流水线架构

开发者 ↓ Git（源码） ↓ CI（Jenkins / GitLab CI） ↓ 构建 ├─ 依赖拉取 ← Nexus └─ 构建产物 → Nexus ↓ 部署（Docker / K8s / 服务器）

Nexus 是“构建的输入源 + 输出仓库”。

六、Nexus 的权限与安全模型

1️⃣ 权限控制

• 用户（User）
• 角色（Role）
• 权限（Privilege）

可以精细到：

• 仓库级
• 读 / 写 / 删除
• 发布权限

2️⃣ 企业常见策略

• 开发：只读
• CI：发布权限
• 管理员：仓库配置

七、版本治理与不可变性（工程纪律）

Nexus 强调：

• 版本一旦发布，不可修改
• 同一版本不能被覆盖
• 强制语义化版本（推荐）

为什么？

• 构建可复现
• 事故可回溯
• 合规审计可追责

八、Nexus 与 Git / Artifactory / Harbor 的区别

Nexus vs Git

Nexus vs Artifactory

Nexus vs Harbor

👉Harbor 管镜像，Nexus 管“全部制品”。

九、Nexus 的典型部署形态

1️⃣ 单节点（最常见）

• 中小团队
• 内网环境
• Docker 部署

2️⃣ 高可用（企业级）

• 外置对象存储
• 多实例
• 前置负载均衡