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 提供的能力
稳定性	本地缓存，避免公网波动
性能	内网高速拉取
安全	权限控制、依赖来源可控
合规	版本不可变、可追溯
工程化	CI/CD 标准化

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

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

技术栈	仓库格式
Java	Maven
.NET	NuGet
前端	npm
Python	PyPI
Go	Go Modules
容器	Docker Registry
通用	Raw（任意文件）

👉 一个 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

项目	Git	Nexus
存储对象	源码	制品
是否可变	可	不可
面向	人	系统
用途	开发	构建 / 部署

Nexus vs Artifactory

对比项	Nexus	Artifactory
开源友好度	高	低
成本	较低	昂贵
功能深度	足够	极强
适用规模	中大型	超大型

Nexus vs Harbor

项目	Nexus	Harbor
管理对象	各类制品	Docker 镜像
Docker 支持	有	专精
通用性	高	低

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

九、Nexus 的典型部署形态

1️⃣ 单节点（最常见）

中小团队
内网环境
Docker 部署

2️⃣ 高可用（企业级）

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