1. 为什么我们需要一个Maven私服做过Java项目的人大概率都经历过这样的场景团队里几个人同时开发每个人电脑上都有一个巨大的本地仓库依赖版本各不一致今天你拉下来的jar包是1.2.3明天他拉的是1.2.4结果代码合并之后编译报错排查半天发现是依赖版本冲突。更头疼的是公司内网环境下访问外部公共仓库速度慢如蜗牛有时候干脆连不上整个团队就卡在那里干等。Maven私服就是来解决这类问题的。简单说它是在局域网内部搭建的一个“依赖中转站”和“内部制品仓库”。所有外部依赖第一次从公共仓库拉取后缓存在私服上之后团队所有人再从私服获取速度快且稳定。同时团队自己开发的内部模块也可以发布到私服上供其他项目引用不再需要手动传jar包。Nexus就是目前用得最广泛的私服搭建工具之一它支持Maven、npm、Docker、PyPI等多种仓库格式管理界面清晰权限控制也做得比较细。这篇文章我会从零开始把Nexus的安装、配置、Maven集成、依赖发布、权限管理以及日常运维中踩过的坑完整地梳理一遍。不管你是刚接触私服的新手还是想优化现有私服配置的老手应该都能从中找到有用的东西。2. 环境准备与Nexus安装部署2.1 硬件与系统环境选型Nexus对硬件的要求其实不算高但有几个关键点需要注意。官方推荐最低配置是4核CPU、8GB内存但在实际使用中如果团队规模在20人以内4核8G足够跑得很稳。磁盘空间才是真正需要关注的地方因为依赖包会越积越多建议至少预留200GB以上的存储空间并且后续要能方便扩容。操作系统方面Linux发行版是首选CentOS 7或者Ubuntu 20.04以上都可以。Windows Server也能跑但生产环境不太推荐主要是文件权限管理和服务化配置比较麻烦。我个人的习惯是用Ubuntu Server包管理方便systemd配置服务也简单。Java环境是必须的。Nexus 3.x版本需要JDK 8或者JDK 11实测JDK 11性能更好一些。注意不要用JDK 17以上版本Nexus 3.x对高版本JDK的兼容性有问题启动时可能会报模块访问错误。安装JDK直接用系统包管理器就行sudo apt update sudo apt install openjdk-11-jdk -y java -version确认版本输出是11.x就OK。2.2 Nexus的下载与目录规划Nexus有两个版本Nexus Repository Manager OSS开源免费版和Nexus Repository Manager Pro商业版。OSS版本对我们来说完全够用功能上支持所有主流仓库格式没有License限制。下载地址直接从Sonatype官网获取最新稳定版。写这篇文章时最新的3.x版本是3.68左右但具体版本号大家以官网为准。下载下来是一个tar.gz压缩包解压后得到两个目录nexus-3.x.x-xx是程序目录sonatype-work是数据目录。这里有个很重要的经验不要把数据目录和程序目录放在同一个磁盘分区。程序目录升级时会被替换数据目录必须保留。我一般会这样规划# 程序目录 /opt/nexus/nexus-3.68.0-01/ # 数据目录单独挂载的大容量磁盘 /data/sonatype-work/在/opt/nexus/nexus-3.68.0-01/bin/nexus.vmoptions文件中可以调整JVM内存参数。默认配置是2703MB最大堆内存如果服务器内存充裕可以适当调大-Xms2703m -Xmx2703m -XX:MaxDirectMemorySize2703m对于50人左右的团队建议调到4G左右。修改完保存即可。2.3 启动Nexus并完成初始化Nexus不能直接用root用户启动需要创建一个专用用户。这是很多新手容易忽略的一步sudo useradd -r -m -d /opt/nexus -s /bin/bash nexus sudo chown -R nexus:nexus /opt/nexus sudo chown -R nexus:nexus /data/sonatype-work然后用nexus用户启动服务sudo -u nexus /opt/nexus/nexus-3.68.0-01/bin/nexus start启动过程大概需要30秒到1分钟可以通过日志确认是否启动成功tail -f /opt/nexus/nexus-3.68.0-01/../sonatype-work/nexus3/log/nexus.log看到“Started Sonatype Nexus OSS”字样就说明启动完成了。默认端口是8081浏览器访问http://服务器IP:8081就能看到界面。首次登录需要找到admin用户的初始密码存放在cat /data/sonatype-work/nexus3/admin.password登录后会强制要求修改密码建议设置一个强密码并妥善保存。同时会询问是否启用匿名访问生产环境建议关闭匿名访问所有操作都需要认证安全性更高。2.4 配置系统服务实现开机自启手动启动的方式在服务器重启后不会自动恢复需要配置成systemd服务。创建文件/etc/systemd/system/nexus.service[Unit] DescriptionNexus Repository Manager Afternetwork.target [Service] Typeforking LimitNOFILE65536 ExecStart/opt/nexus/nexus-3.68.0-01/bin/nexus start ExecStop/opt/nexus/nexus-3.68.0-01/bin/nexus stop Usernexus Restarton-abort [Install] WantedBymulti-user.target然后执行sudo systemctl daemon-reload sudo systemctl enable nexus sudo systemctl start nexus这样服务器重启后Nexus会自动拉起省心很多。3. 仓库类型解析与核心配置3.1 三种仓库类型的本质区别Nexus中的仓库分为三种类型理解它们的区别是配置私服的基础代理仓库Proxy Repository它本身不存储制品而是作为公共仓库的代理。当用户请求一个依赖时代理仓库先去远程仓库下载缓存到本地然后返回给用户。下次再请求同样的依赖直接从缓存返回。这解决了外网访问慢和断网的问题。宿主仓库Hosted Repository用来存放团队自己开发的制品。分为Release和Snapshot两种Release存放正式版本Snapshot存放快照版本。这个区分很重要因为Maven对两种版本的处理策略不同。仓库组Group Repository把多个仓库聚合成一个逻辑仓库用户只需要配置一个URL就能访问所有聚合的仓库。通常会把代理仓库和宿主仓库都加到一个组里这样拉取依赖时不用切换地址。这三种仓库的关系可以用一个简单的类比来理解代理仓库像是“代购”帮你从外面买东西并囤在家里宿主仓库像是“自家工厂”生产自己的产品仓库组像是“前台”你只需要找前台前台会帮你从代购或工厂拿货。3.2 创建代理仓库的关键参数登录Nexus管理界面后进入Repository - Repositories - Create repository选择maven2 (proxy)类型。几个关键参数需要仔细填写Name仓库名称建议用有意义的命名比如maven-central-proxy。Remote storage远程仓库地址填公共仓库的URL。这里注意如果公司有内部镜像源优先填内部镜像地址速度更快。Blob store存储位置默认default即可如果数据量大可以单独创建blob store。Version policy版本策略代理仓库一般选Release因为公共仓库的正式版本居多。Layout policy布局策略选Strict严格模式。一个容易踩的坑代理仓库的“HTTP request settings”中有一个“Connection timeout”和“Read timeout”默认是60秒。如果网络环境不太好建议调到120秒以上否则大文件下载容易超时失败。创建完成后可以点击仓库名称进入详情页在“Browse”标签下能看到已缓存的依赖列表。刚创建时是空的等有请求进来后才会逐渐填充。3.3 宿主仓库的Release与Snapshot策略创建宿主仓库时选择maven2 (hosted)类型。这里最重要的是Version policy的选择Release只允许部署正式版本版本号中不能包含SNAPSHOT。Snapshot只允许部署快照版本版本号中必须包含SNAPSHOT。Mixed两者都允许但不推荐容易造成管理混乱。我一般会创建两个宿主仓库maven-releases和maven-snapshots分别对应正式版本和快照版本。这样在Maven的distributionManagement中配置不同的URL部署时自动区分。宿主仓库还有一个“Deployment policy”选项控制是否允许重复部署。Release仓库建议设为“Disable redeploy”防止同版本号被覆盖Snapshot仓库设为“Allow redeploy”因为快照版本本来就需要频繁更新。3.4 仓库组的聚合逻辑与顺序仓库组是最终暴露给开发者的入口。创建maven2 (group)类型的仓库然后把之前创建的代理仓库和宿主仓库都加进来。顺序很重要Nexus会按照列表顺序依次查找依赖。一般把宿主仓库放在前面代理仓库放在后面。这样当请求一个内部模块时先从宿主仓库找找不到再去代理仓库找外部依赖。如果顺序反了每次都要先查一遍代理仓库效率会降低。配置完成后仓库组的URL就是开发者需要在settings.xml中配置的地址格式类似http://服务器IP:8081/repository/maven-group/这个URL会作为所有Maven请求的统一入口。4. Maven集成与依赖发布实操4.1 settings.xml的完整配置开发者本地需要修改Maven的settings.xml文件通常位于~/.m2/settings.xml。核心配置有两块认证信息和镜像配置。认证信息在servers标签中servers server idnexus-releases/id usernamedeploy-user/username passwordyour-password/password /server server idnexus-snapshots/id usernamedeploy-user/username passwordyour-password/password /server /servers这里的id要和后面pom.xml中distributionManagement里的id对应Nexus通过这个id来匹配认证信息。镜像配置在mirrors标签中mirrors mirror idnexus-mirror/id mirrorOf*/mirrorOf urlhttp://服务器IP:8081/repository/maven-group//url /mirror /mirrorsmirrorOf*/mirrorOf表示所有仓库请求都走这个镜像。如果只想代理特定仓库可以写成central或者*,!internal-repo这样的排除语法。注意如果公司有多个私服或者需要区分不同环境的仓库不要用*通配而是明确指定要代理的仓库id避免请求被错误路由。4.2 pom.xml中配置部署地址在需要发布制品的项目pom.xml中添加distributionManagement配置distributionManagement repository idnexus-releases/id nameRelease Repository/name urlhttp://服务器IP:8081/repository/maven-releases//url /repository snapshotRepository idnexus-snapshots/id nameSnapshot Repository/name urlhttp://服务器IP:8081/repository/maven-snapshots//url /snapshotRepository /distributionManagementMaven会根据项目版本号自动判断走哪个仓库。如果版本号是1.0.0走Release仓库如果是1.0.0-SNAPSHOT走Snapshot仓库。4.3 执行部署与验证配置完成后在项目根目录执行mvn clean deployMaven会先编译打包然后上传到对应的仓库。上传成功后在Nexus界面的Browse中就能看到对应的制品。实操心得第一次部署时很容易遇到401错误大部分情况是settings.xml中的server id和pom.xml中的repository id不一致。另外如果Nexus开启了匿名访问关闭但settings.xml中没有配置认证信息也会报401。排查时先确认这两个点。还有一个常见问题是部署到Release仓库时提示“Repository does not allow updating assets”这是因为Release仓库默认禁止重复部署。如果确实需要覆盖可以临时把Deployment policy改为Allow redeploy部署完再改回来。但更好的做法是升级版本号而不是覆盖已有版本。4.4 依赖拉取验证部署完成后在另一个项目中添加依赖dependency groupIdcom.example/groupId artifactIdmy-library/artifactId version1.0.0/version /dependency执行mvn clean compile观察日志中是否从私服地址下载。如果之前本地仓库已经有缓存可以先删除本地对应的目录再试确保走的是私服。5. 权限管理与安全加固5.1 基于角色的访问控制Nexus的权限模型是用户-角色-权限三层结构。默认有一些内置角色比如nx-admin拥有所有权限nx-anonymous是匿名用户角色。生产环境中我一般会创建几个自定义角色developer角色拥有对宿主仓库的读写权限对代理仓库的读权限。开发人员用这个角色。ci角色只有对宿主仓库的写权限用于CI/CD流水线自动部署。reader角色只有读权限用于只需要拉取依赖的场景。创建角色的路径是Security - Roles - Create role选择Nexus role然后从权限列表中勾选需要的权限。权限粒度可以细到某个仓库的某个操作比如nx-repository-view-maven2-maven-releases-add就是向Release仓库添加制品的权限。5.2 用户创建与Token管理创建用户的路径是Security - Users - Create user。填写用户名、密码、邮箱然后分配角色。一个重要的安全实践不要多个开发者共用同一个账号。每个人用自己的账号这样在审计日志中能追溯到具体是谁部署了什么。如果人员离职直接禁用对应账号即可不影响其他人。对于CI/CD场景建议使用Nexus的User Token而不是明文密码。在用户设置中可以生成TokenToken可以设置过期时间比密码更安全。生成后在CI配置中使用Token替代密码。5.3 匿名访问的取舍Nexus默认允许匿名访问也就是不需要登录就能拉取依赖。这在内部网络环境中问题不大但如果服务器有公网IP就存在信息泄露风险。我的建议是如果服务器只在局域网内可以保留匿名访问方便新人快速上手如果有任何公网暴露的可能必须关闭匿名访问。关闭后所有请求都需要认证安全性大幅提升。关闭方法Security - Anonymous - 取消勾选“Allow anonymous users to access the server”。5.4 定期清理与磁盘管理Nexus用久了磁盘占用会越来越大。主要有两个清理方向清理快照版本Snapshot仓库会积累大量历史快照可以配置定期清理任务。在Repository - maven-snapshots - Cleanup policies中创建策略比如保留最近30天的快照或者保留最近5个版本。清理未使用的代理缓存代理仓库缓存的依赖有些可能永远不会再被请求。可以创建Compact blob store任务定期压缩和清理无引用的数据。在System - Tasks中可以创建定时任务比如每周日凌晨执行清理。注意清理任务执行时会占用一定IO建议放在业务低峰期。6. 日常运维与故障排查实录6.1 常见问题速查表问题现象可能原因排查方向解决方案启动报错“Cannot allocate memory”JVM内存设置过大检查nexus.vmoptions调小Xmx值或增加服务器内存上传依赖返回401认证信息不匹配对比server id和repository id确保两处id完全一致上传依赖返回400版本策略冲突检查仓库Version policyRelease仓库不能传SNAPSHOT版本拉取依赖超时代理仓库网络不通检查Remote storage地址更换可访问的镜像地址或调大超时磁盘空间满快照和缓存积累查看blob store占用配置清理策略并执行Compact任务界面访问502Nexus进程挂了查看nexus.log根据日志排查常见是OOM部署速度慢大文件上传带宽不足检查网络和文件大小分模块部署或优化包体积6.2 日志分析与问题定位Nexus的日志文件在sonatype-work/nexus3/log/nexus.log这是排查问题的第一手资料。日志级别可以在etc/logback.xml中调整默认是INFO排查特定问题时可以临时调到DEBUG。几个常见的日志关键词OutOfMemoryErrorJVM内存不足需要调大Xmx或者排查内存泄漏。Connection refused代理仓库无法连接远程地址检查网络和防火墙。Blob store相关错误存储目录权限问题或者磁盘满。Task failed定时任务执行失败查看具体任务日志。我遇到过一次比较诡异的问题Nexus运行几天后响应越来越慢重启就恢复。后来查日志发现是某个定时任务卡住了导致线程池被占满。解决办法是调整任务执行时间避免多个任务同时运行。6.3 备份策略与数据恢复Nexus的数据都在sonatype-work目录中备份这个目录就相当于备份了所有配置和制品。但直接复制文件的方式在Nexus运行时可能不一致推荐使用Nexus自带的备份任务。在System - Tasks中创建“Admin - Export databases for backup”任务它会导出数据库和配置到一个zip文件。制品文件本身不需要导出因为blob store中的文件是内容寻址的不会变化。恢复时先停止Nexus把备份的数据库文件解压到对应目录然后重启。如果blob store也损坏了那就需要从文件系统级别的备份恢复。实操建议备份任务每周执行一次备份文件保留最近4份。同时把备份文件同步到另一台服务器或者对象存储防止单点故障。6.4 性能调优的几个关键点如果团队规模较大Nexus的默认配置可能会成为瓶颈。以下几个调优点值得关注JVM调优除了调整Xmx还可以调整GC策略。对于大内存服务器建议使用G1 GC-XX:UseG1GC -XX:MaxGCPauseMillis200数据库调优Nexus 3.x默认使用H2数据库小规模够用。如果团队超过100人建议切换到PostgreSQL性能和稳定性都更好。在etc/nexus.properties中配置数据库连接即可。Blob store分离如果条件允许把不同的仓库放在不同的blob store中甚至不同的磁盘上可以分散IO压力。反向代理缓存在Nexus前面加一层Nginx配置静态资源缓存可以减轻Nexus的负载。Nginx配置中把/repository/路径的请求代理到Nexus同时开启gzip压缩。7. 私服使用的进阶技巧7.1 多环境仓库隔离有些团队需要区分开发、测试、生产三个环境的制品。一种做法是在Nexus中创建多组仓库比如dev-releases、test-releases、prod-releases然后在不同环境的CI配置中使用不同的distributionManagement。另一种做法是用仓库的Routing规则根据请求来源IP或者用户角色自动路由到不同仓库。这个功能在Nexus Pro版本中支持OSS版本需要手动配置。7.2 依赖版本锁定与冲突解决私服虽然解决了依赖获取的问题但版本冲突依然可能发生。建议在父pom.xml中使用dependencyManagement统一管理版本号子模块只声明groupId和artifactId不写version。这样所有模块的依赖版本一致减少冲突。如果确实出现了冲突可以用mvn dependency:tree分析依赖树找到冲突的源头然后用exclusions排除不需要的传递依赖。7.3 与CI/CD流水线的集成在Jenkins或者GitLab CI中部署到Nexus的步骤通常是这样mvn clean deploy -DskipTests -s /path/to/settings.xmlsettings.xml中配置好认证信息CI服务器上不需要明文密码可以用环境变量注入。比如在Jenkins中配置Credentials然后在Pipeline中引用。对于快照版本可以配置每次构建都自动部署方便其他团队实时获取最新版本。对于正式版本建议手动触发部署并且部署前执行完整的测试用例。7.4 监控与告警配置Nexus本身没有太丰富的监控指标但可以通过几种方式实现基本监控健康检查接口http://服务器IP:8081/service/rest/v1/status返回Nexus状态可以用监控工具定期探测。磁盘空间监控监控sonatype-work目录所在分区的使用率超过80%告警。日志监控用日志采集工具收集nexus.log对ERROR级别日志设置告警。JVM监控开启JMX用监控工具采集堆内存、GC次数等指标。我在实际运维中最关注的指标是磁盘使用率和JVM老年代占用。磁盘满了会导致所有写入失败老年代持续高位则说明可能有内存泄漏需要及时重启或排查。7.5 从Nexus 2迁移到Nexus 3的注意事项有些老团队可能还在用Nexus 2.x升级到3.x时需要注意Nexus 3的仓库格式和2不同不能直接复制数据目录。需要用官方提供的升级工具或者手动重新配置仓库然后重新部署制品。权限模型有变化角色和权限需要重新映射。API接口不兼容如果有脚本调用Nexus 2的API需要改写。如果制品数量不多最省事的方式是搭建一个新的Nexus 3重新配置仓库然后让CI重新部署一遍。虽然麻烦但比迁移工具出问题再排查要省心。8. 个人实操体会与建议搭建Nexus私服这件事技术门槛其实不高真正花时间的是后期的运维和细节打磨。我前后搭过几次私服踩过的坑主要集中在几个方面一是磁盘规划没做好用了半年就满了迁移数据折腾了一整天二是权限配置太粗放所有人都用admin账号后来想审计都查不到记录三是没有配置清理策略快照版本堆积如山。如果让我重新来一次我会在第一天就把这几件事做好数据目录单独挂载大磁盘、每个人用自己的账号、创建快照清理任务、配置好备份。这些前期花半小时做的事情后期能省下几十个小时的排查和修复时间。另外一个小技巧在Nexus的仓库描述中写清楚这个仓库的用途和维护人时间久了之后新人看到描述就能明白不用每次都来问你。这种文档性的工作看起来不起眼但对团队协作的帮助很大。最后再分享一个实用配置在settings.xml中配置updatePolicyalways/updatePolicy可以让Maven每次都检查快照更新但会增加请求频率。对于快照依赖频繁变动的项目可以设为interval:30每30分钟检查一次平衡实时性和性能。