简介面向 64 位 Windows 环境的 Nexus 3.30.0-01 安装包适用于需要在本机或内网搭建 Maven 仓库的 Java 开发与运维人员可提供完整的仓库管理核心能力。该版本具备代理仓库、存储库聚合、组件发布、权限控制、构件质量检查及可视化搜索等功能可统一管理多种组件格式并与常见持续集成工具协同通过缓存中央仓库依赖来加速构建、降低公网访问同时支持快照版本与正式版本的分级管理。压缩包约 212.01MB内含数据目录与程序目录分别存放运行配置、日志文件以及启动脚本、可执行文件和核心配置解压后配置好 Java 环境即可独立启动服务整体目录结构清晰便于备份与迁移。已有 1787 人学习下载适合需要建立私有依赖源、规范制品发布流程的团队也是学习企业级制品库搭建与 Maven 仓库管理、构建高可用制品库的实用资源。 如果你维护过任何一套内部依赖管理体系大概率听过 Nexus 这个名字。我第一次拿到 nexus-3.30.0-01-win64.zip 这个包时项目要求是在一台 Windows Server 上搭一套完全离线的依赖仓库npm 和 pypi 都要管起来还得能区分不同团队的读写权限。搜了一圈教程要么只讲 Linux要么跳过 Windows 特有的坑最后几乎是一边试错一边才把流程理顺。这篇就把我当时走过的过程、调过的参数、踩过的坑都写出来给要在 Windows 上部署 Nexus 3 的人做个参考。这个 3.30.0-01 虽然不是最新版本但胜在稳定加上 zip 解压即用的特性在内网环境里反而是最省心的选择。1. 版本背后的门道3.30.0-01 与 win64 zip 的选择逻辑1.1 版本号里藏着的信息不少新手看到 nexus-3.30.0-01-win64.zip 这串字符就开始懵其实拆开看非常直观3 是大版本Nexus Repository Manager 3.x 系列30.0 是功能迭代版本01 是构建次数win64 明确表示这是 Windows 64 位系统的发行包而 zip 后缀说明它是一个免安装的压缩包。我当时选 3.30.0-01 就一个原因项目服务器是 Windows Server 2016环境里已经装好了 JDK 8而这个版本对 JDK 8 的支持非常成熟。Nexus 在高版本迭代中逐步提高了对 JDK 版本的要求新版本反而意味着要额外升级基础环境在一个追求稳定的内网项目里属于不必要的变更。如果你也是Java 8 Windows Server的经典组合3.30.0-01 这个序列是比较稳妥的选择别盲目追求最新。1.2 为什么官方用 zip 而不是 exe 安装向导用惯了 Windows 软件的人可能会奇怪为什么 Nexus 不提供一个双击安装的 exe。核心原因在于 Nexus 本质上是一个 Java 进程它要同时维护 Linux、macOS、Windows 多个平台的发布zip/tar.gz 这种解压即用的格式是跨平台成本最低的方案。官方没有给 Windows 写安装向导反而说明它希望你用服务化的方式去管理这个 Java 进程而不是把它当作桌面软件。另外一个值得注意的点是Nexus 安装包的解压目录和数据目录是分开的nexus-3.30.0-01 目录放程序文件同级的 sonatype-work 目录放所有配置、仓库数据和缓存。这种设计让你升级时只需要替换程序目录、保留数据目录后面我会细讲备份和升级。总之看到 zip 别觉得不正规这是 Nexus 特意为你省去了安装程序的依赖注册流程反而更好做自动化部署。2. 部署实录从解压到浏览器出现登录页2.1 环境准备里最容易忽略的两件事部署 Nexus 之前先确认两件事JDK 和路径。Nexus 3.30.0-01 需要 64 位 JDK 8建议 1.8.0_201 以上的版本。我记得官方要求是 JDK 8 起步但不要用 JRE 替代因为后续有些管理脚本依赖完整的 JDK 工具链。路径问题是我第二次部署时才踩到的坑。第一次我把安装包解压到了 C:\Program Files\ 下面启动直接报错排查了半天发现是目录名里的空格导致脚本解析失败。后来我统一把 Nexus 放到 D:\nexus\nexus-3.30.0-01 这类无中文、无空格的纯英文路径下一切就正常了。磁盘空间也要提前规划我建议至少预留 50GB 给 sonatype-work因为代理仓库会缓存大量依赖包这个目录的膨胀速度远超你的直觉。2.2 第一次启动与登录密码的获取环境准备好后进入解压目录下的 bin 文件夹打开命令行执行nexus.exe /run这是前台运行方式方便观察日志输出适合第一次验证安装。/run模式下命令行窗口不能关一旦关闭服务就停。确认能正常访问后建议用管理员权限重新执行nexus.exe /install nexus.exe /start将 Nexus 注册为 Windows 服务这样服务器重启后它能自动拉起不用人工登录桌面去点启动脚本。服务安装成功后浏览器访问http://localhost:8081第一次登录需要用户名 admin密码不会是你设置的任何东西它被自动生成在一个临时文件里sonatype-work/nexus3/admin.password。用记事本打开这个文件复制里面的随机密码才能完成首次登录。登录后系统会强制要求修改密码这一步别跳过后面我会讲为什么。2.3 改端口和调内存上线前一定要做的两处修改默认端口是 8081如果服务器上已经有应用占用了这个端口需要修改 etc 目录下的 nexus-default.properties 文件application-port8082 application-host0.0.0.0application-host我建议保持 0.0.0.0这样才能让局域网内的其他机器通过服务器 IP 访问仓库。只改端口不改 host 是很多人配置完发现别人访问不了的原因。内存参数在 bin 目录下的 nexus.vmoptions 文件中调整核心是-Xms和-Xmx。Nexus 是内存大户尤其是同时管理 npm 和 pypi 仓库时堆内存给太小会频繁 GC界面卡顿。我用的是-Xms1024m -Xmx2048m如果你管理的构件数量很大可以考虑给到 4096m前提是服务器物理内存足够。修改完 vmoptions 一定要重启服务才能生效别问我怎么知道的。3. 仓库规划npm、pypi、maven 三类仓库的搭建与踩坑3.1 先弄懂 proxy、hosted、group 三种类型在创建仓库之前必须理解 Nexus 的三种仓库类型否则很容易建出一堆用不上的空仓库。proxy 是代理仓库它从远程公共仓库拉取依赖并缓存到本地例如 npm 的官方源、pypi 的官方源hosted 是托管仓库存放你自己上传的私有包第三方无法访问group 是聚合仓库把多个 proxy 和 hosted 合并成一个统一地址客户端只需要配置这一个地址。以 npm 为例我通常会创建三个仓库npm-proxy代理官方源、npm-hosted存放私有包、npm-group把前两个聚合。客户端配置 npm-group 的地址后既能下载公共包又能安装私有包而且不用在发布和下载之间切换源。3.2 npm 仓库搭建与客户端的认证问题创建 proxy 仓库时要点是填对远程仓库地址proxy 类型远程地址填https://registry.npmjs.org/hosted 类型不用填远程地址直接设置部署策略为 Allow redeploygroup 类型把上面的 proxy 和 hosted 都加入成员列表然后在客户端机器上执行npm config set registry http://服务器IP:8081/repository/npm-group/这里有一个很隐蔽的坑如果关闭了匿名访问npm install 会返回 401。光配 registry 不够还需要在用户主目录下的 .npmrc 文件里加上认证信息registryhttp://服务器IP:8081/repository/npm-group/ //服务器IP:8081/repository/npm-group/:_authToken你的Nexus认证令牌这个环节最容易出问题的是 token 生成方式。Nexus 里可以通过用户菜单的 NuGet API Key 功能生成也可以直接用 base64 编码的用户名:密码。我在实际项目中推荐创建专用部署账号而不是用 admin 去配客户端后面权限章节会细说。3.3 pypi 仓库搭建与 pip 源的坑pypi 仓库的搭建逻辑和 npm 一致proxy 仓库的远程地址填https://pypi.org/simple/。但 pip 客户端的配置多一个坑如果走的是 http 而不是 httpspip 会默认拒绝不安全连接。客户端配置清华或内网源时经常看到类似报错pip install requests --index-url http://服务器IP:8081/repository/pypi-group/simple/这时候需要额外指定pip install requests --trusted-host 服务器IP --index-url http://服务器IP:8081/repository/pypi-group/simple/更好的做法是把配置写进 pip.iniWindows 下位于%APPDATA%\pip\pip.ini全局生效[global] index-url http://服务器IP:8081/repository/pypi-group/simple/ trusted-host 服务器IP上传私有 Python 包则需要先安装 twine然后执行twine upload --repository-url http://服务器IP:8081/repository/pypi-hosted/ dist/*注意 pypi-hosted 仓库要在配置里允许上传否则 twine 会返回 403。4. 局域网离线环境先缓存后断网依赖照样装4.1 为什么离线环境更需要 Nexus很多人觉得离线环境不需要仓库管理器直接用安装包拷贝就行。但在真实的项目里依赖关系是网状的一个包依赖几十个传递依赖手动拷贝根本没有可维护性。Nexus 的价值就在于你可以提前在有网络的环境里把所有依赖拉取到本地缓存然后把整个数据目录迁移到内网断网环境下客户端依然能像在线一样解析依赖。这个思路对 npm 和 pypi 都适用。实际操作逻辑也很简单先在能访问外网的机器上部署 Nexus配置好 proxy 仓库和 group 仓库让开发人员在有网阶段正常使用几天。这期间所有请求过的包都会被缓存到 blob 里数据目录 sonatype-work 会变得很大但这份膨胀是有价值的。4.2 从有网缓存到内网分发的迁移流程当我认为缓存得差不多之后开始做迁移。步骤是先把有网环境上的 Nexus 服务停掉然后整体复制 sonatype-work 目录到内网服务器的对应位置。注意这里必须整目录复制不要只拷贝部分仓库因为 Nexus 的 blob 和数据库元数据是关联的。复制完成后启动内网 Nexus用管理员账号检查 proxy 仓库的状态。如果之前配置的远程地址已经无法访问也没关系客户端在请求包时Nexus 会先查找本地 blob 缓存命中就直接返回只有未命中的包才会去尝试远程源。为了万无一失我会在正式断网前做一轮验证用 pip 安装一个之前用过但比较冷门的包确认能从内网 Nexus 成功拉取再让团队切流量。4.3 防火墙与端口的小规模排查内网机器通过 IP 访问 Nexus 时经常会卡在一个奇怪的现象上服务器本机能打开管理界面其他机器就是连不上。这个问题 90% 是 Windows 防火墙没有放行端口。在服务器上执行netsh advfirewall firewall add rule nameNexus 8081 dirin actionallow protocolTCP localport8081放行 8081 端口即可。另一类问题是服务器绑定了多个网卡Nexus 默认监听所有地址只要 application-host 是 0.0.0.0 就不需要再改。如果还是不通就在客户端先 ping 服务器 IP再用 telnet 测一下端口连通性。telnet 能通而浏览器不行那基本就是客户端代理设置的问题了。5. 权限配置与备份维护藏在操作背后的关键细节5.1 从匿名访问到精细角色控制装好 Nexus 之后默认是允许匿名读取的。在开发环境无所谓但在内网生产环境任何能访问到这个 IP 的人都能把你们的私有包拉走这就很尴尬了。我上线的第一个动作就是关闭匿名访问在管理界面的 Security Anonymous 菜单里取消勾选允许匿名用户访问保存后立即生效。关闭匿名后要立刻给团队成员创建账号和角色不然大家都无法拉取依赖了。我一般创建两类角色develop-role拥有所有仓库的 nx-repository-view-*-browse 和 nx-repository-view-*-read 权限也就是只能查看和拉取release-role额外拥有 nx-repository-view-*-add 和 nx-repository-view-*-edit 权限用于向 hosted 仓库上传发布包然后为每个开发小组创建单独的用户分配这些角色。npm 和 pip 客户端配置里使用各自的账号运维审计时能追踪到具体是谁发布了什么包。5.2 权限配置的三个高频误区第一个误区是改了 admin 密码后没有妥善备份。Nexus 的账号数据都存在 sonatype-work 里如果只备份程序目录恢复后你不仅丢了仓库配置连登录方式都会乱掉。第二个误区是关闭匿名后忘了更新 npm/pip 客户端的认证配置导致全线构建失败。建议在关闭匿名之前先在客户端把新账号配置测通再执行关闭操作。第三个误区是给了用户过大的权限比如直接把 admin 角色授给普通开发完全绕过了权限模型。我在实践中规定 admin 账号只能用于管理日常构建和发布全部走专用账号。5.3 备份的正确姿势只备份 sonatype-work 就够了Nexus 有三层数据程序目录、数据目录、blob 目录。程序目录损坏了可以从安装包重新解压但数据目录 sonatype-work 一旦丢失仓库配置、用户信息、所有缓存和私有包全部归零。因此备份的核心一定是 sonatype-work 这个目录。最安全的做法是先停止服务再备份保证数据一致。如果业务不能停可以备份过程中把 Nexus 设为只读模式避免备份期间写入新数据。恢复时先解压一个新的 Nexus 程序目录然后把备份的 sonatype-work 放到同级目录启动服务即可。这个流程我验证过多次只要版本一致恢复后所有仓库、权限、缓存的包都能原样回来。5.4 三个我亲身踩过的维护坑最后分享几个不那么明显但很实际的坑。第一个是重启机器后 Nexus 服务没自动拉起。如果你用 nexus.exe /install 注册服务默认的启动类型是自动但某些杀毒软件会拦截 Java 进程的服务注册导致启动失败。解决办法是启动前检查服务状态必要时用 Services.msc 手动启动并把恢复选项改成重新启动服务。第二个坑是磁盘写满后Nexus 不会直接崩溃而是上传包时开始出现莫名超时或 500。排查了很久才发现是磁盘空间不足。后来我养成了监视 sonatype-work 所在磁盘空间和定期清理 blob 历史版本的习惯。第三个坑是升级版本后旧的 groovy 脚本失效。3.30.0-01 以及相邻版本之间升级一般能平滑迁移但如果跳过了多个大版本一些自定义脚本和任务配置可能会报错。我的建议是先在一台测试机上完整走一遍升级流程确认数据迁移无误后再操作生产环境。毕竟在内网环境里稳定压倒一切任何一个意外都可能导致整个团队的开发阻塞。本文还有配套的精品资源点击获取