聊到 Nexus3我猜国内不少团队第一反应还是“Maven 私服”。这想法没错但有点浪费。Nexus3 远不止是个 Java 仓库npm、Docker、PyPI、NuGet、Go 模块、Raw 格式都能管一个服务把整个研发团队的制品资产全收进来这才是它真正的价值。这两年国产化替代、信创项目扎堆我身边越来越多的团队开始把 Nexus3 部署到麒麟、统信这些系统上给内网做统一的制品源配合龙芯、飞腾这些硬件平台跑得也挺稳。这篇东西我不会讲太多官方文档里已有的废话重点放在三件事第一国内网络环境下怎么快速拿到 Nexus3 并完成部署少走弯路第二多版本、多实例的正确玩法包括和 CUDA 多版本、Flutter 多版本管理的思路类比第三全平台适配的实际经验x86、ARM、国产化平台都怎么落地。建议刚接触 Nexus3 的运维、准备搭制品仓库的研发负责人、正在做国产化工控平台的架构师都花十分钟过一遍基本能把坑提前踩平。1. Nexus3 到底是什么为什么国内团队绕不开它1.1 从 Maven 私服说起Nexus3 解决的核心场景先捋一个最基础的问题。Nexus3 是 Sonatype 出品的仓库管理器核心功能概括起来就三个词托管、代理、聚合。托管是指你能把自己产出的制品包放到 Nexus3 上长期保存代理是指它能帮你缓存远程仓库的制品比如 Maven 中央仓库、npm 官方源团队拉依赖时先走本地 Nexus3命中缓存就不用每次都跨网去拉聚合则是把多个仓库组合成一个 group 仓库对外暴露开发者只需要配一个地址就能同时从好几个仓库里拿东西。这三个能力放在国内网络环境下尤其重要。Maven 中央仓库、npm 源这些国外服务直连时快时慢我不展开说原因懂的都懂而一旦团队超过十个人每个人都直接连外网拉依赖既慢又浪费带宽。架一台 Nexus3 做代理缓存第一次拉包慢点之后全走内网速度能提升一个数量级。我见过不少团队上了 Nexus3 之后构建时间直接从十几分钟降到一两分钟就是这个缓存机制的功劳。1.2 不止是私服Nexus3 支持的仓库类型全景很多人对 Nexus3 的理解停留在 Maven 私服这是个很普遍的误区。我整理一下 Nexus3 目前支持的仓库格式仓库格式典型用途版本管理方式MavenJava 构建依赖与制品坐标 版本号npmNode.js 依赖包语义化版本 tagDocker容器镜像仓库tag digestPyPIPython 依赖版本号NuGet.NET 包版本号GoGo 模块代理语义化版本Raw任意文件托管目录结构自定义Yum / AptLinux 软件包仓库RPM / DEB 版本HelmKubernetes 应用包Chart 版本这个表看起来简单实际影响很大。比如说 Docker 镜像很多团队为了保证产线环境稳定不允许直接拉外网镜像而是要求所有镜像必须过内网仓库。Nexus3 的 Docker 托管仓库就能干这件事而且支持镜像代理和镜像分组配合 Harbor 用也不冲突。再比如 Helm ChartK8s 部署文件散落在 Git 里其实挺难管的统一推到 Nexus3 的 Helm 仓库之后发布和回滚都变得很干净。1.3 适用范围与角色定位从适用人群上说Nexus3 适合的团队规模跨度很大。三五人的小团队可以拿它当个简单的依赖缓存来用上百人的研发中心Nexus3 可以作为制品管理的核心基础设施承担二进制资产的全生命周期管理。对于正在做国产化改造的团队Nexus3 还有一个特别的优势——它就是一个 Java 应用只要目标平台上有对应的 JDK 就能跑不需要依赖任何特定操作系统 API所以不管是 x86 的 CentOS还是 ARM 架构的麒麟系统部署方式几乎完全一致。2. Nexus3 多版本管理从单实例到多版本共存的实战思路2.1 版本混乱的痛点为什么“多版本”是个真问题先说个实际场景。一个中型团队一年下来Maven 制品可能有上千个版本npm 包也有几百个。如果没有一个统一的仓库来规范版本管理开发人员常用的做法就是往共享目录丢 zip 包或者传到聊天工具的群文件里。这么做一两次还能忍次数多了绝对出乱子——你根本不知道哪个包是哪个构建产物想回滚却发现之前的版本被覆盖了。Nexus3 解决这个问题的方式很朴素就是“一个制品 多个版本 完整的生命周期”。每个制品存在仓库里版本号是唯一的不能被覆盖删除和更新都有权限控制。这样一来任何历史版本都能找回发布和回滚都有据可查。这不是什么高深的技术但就是这种“笨办法”在工程上最可靠。2.2 多版本共存的几种落地方式Nexus3 本身并不限制同一个制品只能存在一个版本默认就支持多版本共存。你可以在同一个仓库里看到 com.demo:demo-api:1.0.0、1.0.1、2.0.0 这些版本同时存在互不干扰。实践中“多版本管理”的需求通常分两种对应的解法也不一样同一个仓库内多版本共存。这个 Nexus3 原生支持开发时通过坐标或包名指定版本号即可。常见于 Java 项目里依赖不同版本的内部公共库比如一个服务用 common-utils:1.0.0另一个服务用 common-utils:1.1.0两个版本都在仓库里各取所需。多套环境隔离。这种场景更复杂比如开发环境、测试环境、产线环境要用不同目录、不同权限、甚至不同 Nexus3 实例来隔离。这时候只靠一个仓库就不好使了需要规划多实例部署。我在实际项目里比较推荐“单实例多仓库 必要时多实例”的组合。默认的 blob store 按仓库粒度分配存储空间你可以把开发相关的仓库放在 dev store正式发布的仓库放在 release store互不干扰。如果团队很大不同事业部之间还有严格的权限隔离要求那就用多实例方案——每个实例绑定不同的端口和存储目录当成独立的仓库管理系统来用。多个 Nexus3 实例之间不需要额外同步部署在同一台服务器上只占 JVM 内存资源开销完全可控。2.3 与 CUDA 多版本、Flutter 多版本管理的横向类比我发现一个挺有意思的现象不同技术领域都在面对“多版本共存”这个同样的课题。比如 GPU 服务器上装 CUDA 多版本社区通用的解法是“安装多个版本 用环境变量或软链接切换”Flutter 多版本管理社区工具 FVM 的思路也是“下载多个 SDK 版本 按项目目录切换”。这跟 Nexus3 的多仓库、多实例方案本质上是一个套路。场景多版本方案切换机制CUDA多个 CUDA Toolkit 共存修改 PATH / LD_LIBRARY_PATHFlutterFVM 管理多个 SDK 版本项目级配置 fvm useNexus3多仓库 / 多实例隔离修改仓库地址 / 端口我拿这个对比出来是想说明所谓的“多版本管理”从来不是某个工具自带的一个开关而是一套配套的规范。在 Nexus3 里光有版本共存还不够你还要定好命名规范、仓库划分规则、版本淘汰策略。不然时间一长仓库里的版本堆积如山又变成了另一种杂乱。2.4 版本继承与升级策略Nexus3 本身不提供“版本继承”的概念但你在组织制品存储结构时可以有意识地做规划。比如 Maven 仓库里把 API 模块、业务模块、公共工具模块分成不同的 group每个 group 内部再按版本演进。发布新版本时建议遵循语义化版本规范——主版本号、次版本号、修订号各表其意这样下游依赖方一看版本号就知道升级风险是大还是小。升级 Nexus3 服务本身也是一门学问。我踩过一次坑直接从旧版本跳到新版本结果由于数据模型变更启动直接失败花了大半天才恢复。稳妥的做法是升级前先备份整个 sonatype-work 目录然后按官方升级路径逐级升级别跳版本升级后先检查所有 blob store 是否 online再确认各仓库的请求是否正常。这条经验适用于所有有状态服务不只 Nexus3。3. 国内下载与高速部署一台服务器半小时跑起来3.1 下载安装包哪条渠道靠谱我先回答标题里最直接的诉求国内从哪下载 Nexus3 比较快。官方在 GitHub 上有 Release 页面提供各版本的 tar.gz、zip 和 rpm 包。但国内直连 GitHub 下载大文件时速度波动很大这个不用我多说。我这边实测过几条路径清华大学开源软件镜像站mirrors.tuna.tsinghua.edu.cn有 Nexus3 的二进制包速度稳定推荐。阿里云镜像站主要在 Maven 仓库这一层做加速Nexus3 安装包本身镜像得不多。华为云镜像站部分版本有收录可以作为备选。GitHub Release 直连没得选的时候用但建议用 curl -L 带断点续传参数。我自己最常用的命令是wget -c https://mirrors.tuna.tsinghua.edu.cn/nexus/nexus-3/nexus-3.xx.x-unix.tar.gz这里补充一点Nexus3 版本号看起来很密集但并不是所有版本都值得追。一般建议选择当前 3.x 版本线的较新稳定版比如 3.49、3.63 这种小版本比较新的版本避开刚发布的 .0 版本。对于有国产化要求的团队更要提前确认所选版本在对应 JDK 版本上的兼容性。3.2 安装部署三步走JDK、解压、启动Nexus3 是个 Java 应用所以安装前提是先有 JDK。官方要求 JDK 8 或 JDK 11较新版本推荐 JDK 11。国内服务器常见的是 OpenJDK这点比较好办直接用包管理器装即可yum install -y java-11-openjdk-devel装完 JDK 之后解压安装包。官方发布包是一个压缩文件解压后有两个目录一个叫 nexus-3.x.x程序本体另一个叫 sonatype-work数据目录包括元数据、日志、上传的制品等。这才是需要重点保护的目录备份和迁移都针对它。tar -zxvf nexus-3.63.0-unix.tar.gz -C /opt/ cd /opt/nexus-3.63.0/bin ./nexus start启动后默认端口是 8081浏览器访问 http://服务器IP:8081 就能打开管理界面。首次启动会创建一个 admin 用户初始密码在 sonatype-work/nexus3/admin.password 文件里第一次登录会强制改密码。这个细节很多人忽略其实命令行也能直接读到cat /opt/sonatype-work/nexus3/admin.password启动过程慢不要慌Nexus3 启动通常需要 1 到 2 分钟因为它要加载一堆插件、检查 blob store 状态尤其是第一次启动还会创建内置数据库。这段时间多看看日志tail -f /opt/sonatype-work/nexus3/log/nexus.log看到 “Started Sonatype Nexus OSS” 这一行才说明服务起来了。3.3 三个关键配置端口、JVM 内存、开机自启部署完能跑不代表就配置好了我每次搭 Nexus3 都会顺手做三件事改端口、调内存、配自启。端口修改在 etc/nexus-default.properties 里把默认 8081 换掉比如换成 8085避免和服务器上其他 web 服务冲突application-port8085 application-host0.0.0.0JVM 内存是另一个重点。Nexus3 默认会吃很大内存如果服务器资源有限不调会非常卡。Nexus3 的启动脚本在 bin/nexus 里可以通过环境变量控制内存上限export INSTALL4J_ADD_VM_PARAMS-Xms512m -Xmx1024m -XX:MaxDirectMemorySize512m这只是一种临时方式更推荐直接修改 bin/nexus.vmoptions 文件我一般改成-Xms512m -Xmx1024m -XX:MaxDirectMemorySize512m内存大小没有统一标准我个人的参考值是一千个制品以下 512m 够用五千个制品左右建议 1g上万制品再往上加到 2g。注意不要一下子给到 4gNexus3 的堆外内存元空间、直接内存也要算进去给满容易触发系统 OOM。开机自启这块最简单的做法是用 systemd 写一个服务文件。在 /etc/systemd/system/nexus.service 里写入[Unit] DescriptionNexus Repository Manager Afternetwork.target [Service] Typeforking ExecStart/opt/nexus-3.63.0/bin/nexus start ExecStop/opt/nexus-3.63.0/bin/nexus stop Usernexus Restarton-abort LimitNOFILE65536 [Install] WantedBymulti-user.target这里特别提醒一下Nexus3 官方不推荐用 root 用户跑因为安全问题比较多。建议单独建一个系统用户 nexus然后把 /opt/nexus-3.x.x 和 /opt/sonatype-work 的属主改成 nexus。这个习惯还能避免一个坑如果你用 root 启动过一次数据目录的文件属主会变成 root后续切换用户启动时可能因为权限不够而失败。3.4 仓库代理加速让国内拉包不再卡壳Nexus3 架好之后接下来要做的不是马上用而是配置仓库。真正的“国内加速”价值其实体现在仓库这一层。以 Maven 仓库为例。默认 Nexus3 自带一个 maven-central 代理仓库但它指着的是 repo.maven.apache.org国内访问不算快。我建议的做法是修改 maven-central 的 Remote Storage把上游换成阿里云 Maven 镜像https://maven.aliyun.com/repository/central在 Nexus3 的 UI 里找到 maven-central 仓库把 Remote Storage 地址改掉然后 Refresh 一下缓存。这样团队所有走 Nexus3 拉取中央仓库依赖的请求实际都落到阿里云节点上速度快很多。npm、PyPI、Go 模块同理都有国内镜像可以配。Docker 镜像这块Nexus3 可以配置 Docker Proxy 仓库指向 Docker Hub但 Docker Hub 在国内的访问状况也不太稳定。我见过不少团队直接用 Nexus3 的 Raw 仓库托管离线镜像包或者从镜像站下载完再导入到 Nexus3 的 Docker 仓库里这两种方式都能实现内网镜像的分发。重点是无论哪种方式最终目的都是让生产环境不要直接依赖外网。4. 全平台支持从 x86 到 ARM 再到国产化平台4.1 Nexus3 在 Windows、Linux、macOS 上的表现差异Nexus3 官方提供的安装包分三类Unix 版tar.gz、Windows 版zip、还有 RPM 版适用于 RHEL/CentOS。macOS 上我只推荐用 Docker 方式跑因为直接在 macOS 上装 Java 服务挺闹心的文件权限和开机自启都不如 Linux 省事。Windows 上部署 Nexus3 是很多初学者的首选毕竟图形界面和操作习惯都熟悉。但我要泼盆冷水Nexus3 在 Windows 上可以作为开发环境临时用生产环境我劝你别这么干。原因有三第一Windows 下文件锁机制容易出问题制品文件被占用是常事第二性能上不如 Linux第三systemd 在 Windows 上不存在自启和守护都要靠计划任务管理麻烦。小团队图省事用 Windows 机器跑个 Nexus3 我觉得没问题但规模一上来就要考虑迁移到 Linux。Linux 上我用过的发行版包括 CentOS 7、CentOS 8、Ubuntu 20.04、Debian 11部署方式几乎一致就是“JDK 解压 启动脚本”。唯一要注意的是防火墙。CentOS 得显式放行 8081firewall-cmd --permanent --add-port8081/tcp firewall-cmd --reloadUbuntu 一般是 ufw同理操作。很多新手搭完 Nexus3 发现外网访问不了十有八九是防火墙没放行。macOS 上如果你的笔记本只是想本地起个环境测测配置直接 docker run 最快docker run -d -p 8081:8081 --name nexus sonatype/nexus3这种容器方式对 ARM 芯片的 Mac 也通用只要 Docker Desktop 的 API 支持镜像会直接拉取对应架构的版本不需要额外处理。4.2 ARM 架构支持情况与容器化方案接下来说 ARM 架构。Nexus3 官方对 ARM 的支持其实比较暧昧官方二进制包主要面向 x86_64你在 Sonatype 的下载页面上看 unix 包通常只有 x86_64 的份。但 Nexus3 本质是 Java 应用只要 ARM 平台上有对应的 JDK比如 OpenJDK 11 for ARM64理论上就能跑。实际测试下来树莓派 4BARM64上跑 Nexus3 是可行的性能虽然不突出但支撑一个小团队十人左右的制品缓存完全够用。换成国产的飞腾 FT-2000、鲲鹏 920 这些 ARM 芯片同样是配套 ARM64 版 OpenJDKNexus3 能正常启动、正常服务。容器化是另一种更省心的方式。sonatype/nexus3 官方镜像会出多架构版本在 ARM64 服务器上直接拉取即可docker pull sonatype/nexus3:3.63.0用镜像跑[Nexus3](数据目录要挂载出来这是我一直强调的点docker run -d \ -p 8081:8081 \ --name nexus \ -v /opt/nexus-data:/nexus-data \ --restartalways \ sonatype/nexus3:3.63.0容器方式的好处是隔离性强、迁移方便但要注意容器内的 Nexus3 默认以 nexus 用户运行宿主机挂载目录的属主要给对不然容器起不来会报权限错误这个坑在我第一次容器化部署时就踩过。4.3 国产化平台实战从工控领域看落地价值这两年国产化平台的项目越来越多我接触到的需求主要有两类一类是信创替代把原本跑在国外的商业软件栈迁移到国产 CPU、国产操作系统上另一类是轨道交通、能源、电力等工控领域的 AFC 系统、SCADA 系统它们要求从硬件到软件尽可能国产化降低供应链风险。Nexus3 在国产化平台上的价值在于它是一个纯 Java 应用不依赖特定的 CPU 指令集或操作系统 API这意味着你可以在龙芯LoongArch、飞腾、鲲鹏、海光这些平台上用统一的部署脚本把它跑起来。我把这个过程总结成一个清单确认 CPU 架构uname -m决定下载哪个 JDK 版本。从信创适配的 JDK 发行版如龙芯 LoongWare JDK、华为毕昇 JDK安装 Java 11。解压 Nexus3 官方 tar.gz 包目录结构和 x86 平台完全一致。启动后检查日志有无 JNI 相关错误确认数据库初始化正常。在实际的轨道交通 AFC 系统场景里Nexus3 通常部署在车站级或线路级的国产化服务器上配合国产数据库、国产中间件一起工作。它管理的制品也不局限于 Java 包还包括工控软件的安装包、配置文件模板、固件升级包等这些都可以作为 Raw 仓库来托管。这个用法让我意识到一件事在国产化替代的过程中“制品仓库”这个角色被低估了——它不只是给研发用的对整个系统的交付、升级、运维都有支撑作用。国产化平台有一个现实问题外网访问受限。在内网部署 Nexus3 之后你完全可以在初始化时把外网仓库的制品缓存好然后在离线环境里供研发和运维使用。这样一来即使内网环境和外网物理隔离团队仍然可以享受“中央仓库 本地缓存”的便利。4.4 多平台统一部署的一个实用建议如果你所在团队同时有 x86 服务器、ARM 服务器、纯内网机器我给一个建议不要每台机器都单独装 Nexus3而是选定一台“主实例”来承担制品存储和仓库代理其他机器通过 group 仓库或者 HTTP 代理方式来访问主实例。这样既减少了维护成本又保证了制品的一致性。主实例推荐放在高性能 x86 服务器上如果不是为了信创合规要求没必要在每一台国产化服务器上都部署一个完整 Nexus3。但在信创验证环境中为了证明整个技术栈在国产化平台上完整可用Nexus3 在麒麟、统信等系统上的独立部署又是一道必答题。两个方向不矛盾按实际的验收要求来定即可。5. 常见问题与排查技巧实录5.1 安装启动阶段的坑这一节我记录几个高频问题都是我或者身边人实际踩过的。第一个是启动卡死或者极慢。Nexus3 启动本来就要 1 到 2 分钟但如果超过 5 分钟还在 Starting 状态我会先去查 sonatype-work/nexus3/log/nexus.log看日志停在哪一步。比较常见的原因有两个一是 JVM 内存配得太小堆内存一直触发 GC导致启动线程被反复暂停二是 blob store 对应的存储目录不可写比如权限不对或者磁盘满了。第二个是端口被占用。启动日志会明确告诉你 “address already in use”这时候别急着换端口先搞清楚谁占了端口。在 Linux 上ss -lntp | grep 8081如果是之前残留的 Nexus3 进程直接 kill 掉再重启。第三个是忘记 admin 密码。如果你改了密码又忘了官方有个“取巧”的办法停掉 Nexus3然后删除 sonatype-work/nexus3/ 下用于保存用户数据的相关数据库文件具体文件在不同版本有差异通常在 db 目录下重启后 Nexus3 会重新初始化admin 密码就重新生成了。这个操作会丢失所有用户配置但制品数据还在算是一个恢复手段。5.2 仓库使用与权限排查仓库配置完连不上是使用阶段最常出现的问题。我从客户端视角列一个速查表报错现象常见原因排查思路401 Unauthorized账号密码错误或权限不足检查用户权限、仓库权限502 Bad Gateway代理仓库的上游不可达检查 Remote Storage 地址和网络504 Timeout上游仓库响应超时加大 HTTP 超时配置或换国内镜像Connection refusedNexus3 服务未启动或端口不通检查进程和防火墙Maven 客户端报 401 时大都是因为 settings.xml 里配的 server 用户名密码和 Nexus3 实际账号不一致。另外如果你建了 group 仓库要记得把对应的具体仓库添加到 group 成员里很多人建完 group 忘了添加成员客户端拉依赖时自然报 404。npm 客户端有个独特的问题Nexus3 的 npm 仓库要求客户端使用 Nexus3 生成的 auth token而不是简单用用户名密码。如果你拿用户名密码直接配 npm login会一直认证失败。解决方案是在 Nexus3 的 npm 仓库页面里找到 “npm-config” 的推荐配置片段直接复制到 .npmrc 里。5.3 性能与存储优化Nexus3 用久了最明显的问题是磁盘空间膨胀。这主要有两个来源一个是代理仓库的缓存另一个是日志文件。代理缓存的清理不能直接删文件要在 Nexus3 的 Maintenance 里做 Cleanup Policies设置按天数或策略清理旧制品。日志文件则要配置 logback 的滚动策略否则 nexus.log 能涨到几个 GB。上传大文件时如果出现文件损坏或者上传失败通常是默认的 HTTP 请求体大小限制导致的。可以在 etc/nexus.properties 里加上nexus.upload.maxSize-1意思是取消上传大小限制。不过生产环境我不建议设成无限大设置一个大一些的固定值更稳。对于存储布局如果数据量特别大可以使用多个 blob store。比如把 Docker 镜像和 Maven 制品分别存到不同的磁盘目录防止某个仓库增长过快把整块盘占满。创建 blob store 时要给它留出足够的空间这个在 Nexus3 UI 的 Blob Stores 菜单里配置即可。提示Nexus3 的磁盘空间管理是数据安全的底线。如果数据目录所在的磁盘满了不仅上传会失败严重时可能导致数据库损坏。生产环境务必配置磁盘空间监控建议在整块磁盘使用率达到 80% 时提前告警。5.4 备份与迁移的正确姿势最后聊聊备份和迁移。Nexus3 的备份从来不是备份一个目录那么简单但也没那么复杂。需要备份的内容主要有两块sonatype-work/nexus3 下的数据库文件里面有用户、仓库、权限等元数据以及各 blob store 目录下的二进制制品文件。我的备份策略是每天凌晨用 rsync 把 sonatype-work 整个目录同步到另一台机器或者挂载的远程存储上。这个做法虽然有些“暴力”但对 Nexus3 这种有状态服务来说最可靠rsync -avz --delete /opt/sonatype-work/ backup-server:/backup/nexus/在迁移场景下只要目标机器的 Nexus3 版本和源机器一致或者大版本一致直接把 sonatype-work 目录复制过去然后启动新实例所有仓库和制品就都过去了。这里注意复制前源实例要停掉否则文件还在写入复制出来的备份可能数据不一致。还有一点很多人不清楚sonatype-work/nexus3 下有个名为 keystore 的目录里面保存着用于加密敏感配置的密钥。如果你的 Nexus3 里配置了带有密码的连接比如 ldap、docker 仓库的认证信息迁移时这个目录也必须一起复制否则新实例上无法解密这些密码你会看到各种诡异的认证报错。写在最后的经验我实际操作下来的体会是Nexus3 的学习成本并不高真正难的是在一开始就规划好仓库结构、权限模型、备份策略和升级路径而不是等到制品堆积如山再来补救。很多团队搭好 Nexus3 之后把它扔在角落里不管等到某天磁盘满了、admin 密码忘了、要迁移服务器了才手忙脚乱地翻文档那就很被动了。最后再分享一个小技巧如果你刚接触 Nexus3可以先在本地用 Docker 起一个实例把 Maven 中央仓库、npm 官方源、PyPI 这几个代理仓库配好然后用自己的项目实际拉几次依赖。等熟练了再上生产环境心里就有底了。毕竟制品仓库这玩意儿配置看起来都是点点鼠标的事实际上每一个选择都关系到后面上百人团队的使用体验。