maven仓库--sonatype nexus如何搭建集群

常用的maven仓库：

1. nexus    2.*版本主要针对maven仓库，3.*版本功能比较强大，详细区别查官网；nexus-repository-oss 免费

2. artifactory    功能强大，提供丰富的rest 接口，如果需要devops可以考虑使用；收费

我们公司现在使用的是nexus-repository-oss 2.*  

随着公司项目组的使用量增加，为了防止nexus奔溃，准备搭建nexus的集群:

需要解决的问题：

仓库类资源需要同步，即一个jar包传到一台nexus服务器，集群里面其他的服务器需要能够立马获取到该jar包

解决方案有很多：

1. 集群之间使用一个共享存储，例如我们就是采用挂载一块nas盘的方案

2. 通过资源实时同步的方案，例如采用 rsync + inotify实现服务器之间文件实时同步

我采用的是第一种方案，第二种感觉比较麻烦，需要我自己干的事情比较多，不过个人认为第二种才是最佳的集群的方式，支持并发什么的，io瓶颈都会比第一种好，待有时间再试一试

先介绍第一种方案中的坑

我服务器A与B 上挂载了同一块nas盘到我的 /nasfiles/sonatype-work/nexus 目录

服务器A 上安装 nexus，目录结构如下：

进入conf目录，修改 nexus.properties

将 nexus-work目录指向我们的nas盘所挂载的目录  

启动服务器A的nexus服务， 

cd ../bin

./nexus start

启动之后，访问我们的nexus，  http://ip:port/nexus 我的port改成了8080 默认为8081；nexus start显示启动成功之后，页面需要一小会才能访问

启动成功的页面如下：

查看repositories，默认的只有 中央仓库和 apatch的仓库，这里可以自己添加一些常用的代理仓库，我添加了aliyun的作为代理仓库，另外新建了几个hosted的仓库用于不同开发部存放二方库的包

到这里都很简单，很流畅的完成；

后面是我们的重点，搭建服务器B的nexus；

因为需要共享仓库的资源，所以我也是按照服务器A的方式去修改nexus.properties，地址也是指向的nas盘所在目录，即配置

nexus-work=/nasfiles/sonatype-work/nexus

同样启动 nexus start；

直接启动报错，错误原因很简单，当前目录已经被使用（英文报错信息翻译过来就这意思）

到/nasfiles/sonatype-work/nexus里面瞄了一下：

这是nexus实际运行时的工作目录，一眼就看到了nexus.lock这个文件，果断打开看一下：

一个id +  服务器名称 

id就是 nexus服务运行的pid， ps -ef|grep nexus 就可以看到我的nexus服务的pid就是18381 

仔细想想，也要道理，nexus采用这种lock的检查方式，防止同时有多个服务去操作nexus中的配置；也是为了防止出现文件冲突吧

不管什么原因了，反正我现在想搭集群，那就解决这个吧；当然 如果采用 服务器同步的话 ，就没有这种目录已经被使用的问题啦，毕竟不是使用的同一个目录

继续尝试，

既然我们不能使用/nasfiles/sonatype-work/nexus 作为我的工作目录，那就改一个地址吧，先把nexus.properties还原回去

还是 使用默认的工作目录吧，先启动看看，没啥问题，正常启动，看看我们的${bundleBasedir}/../sonatype-work/nexus目录下，和/nasfiles/sonatype-work/nexus是一样的，

那就解决我们的资源共享问题吧，首先整理一下，我们的资源在那里，瞄了一下，可以发现

 

conf 目录：

主要的配置文件就是nexus.xml，打开一看，里面全部都是我nexus页面上配置的  repositories的信息，repositoryGrouping的信息以及配置的一些tasks

indexer目录：看名字也知道是索引文件

storage目录：我的仓库的信息，这个也是最重要的资源存放的地址，jar包，war包什么的都在这里啦

那么问题来了，我只需要将storage共享了，问题不就解决了吗，那我直接将我的nas盘挂载到 服务器A 和B的 /nasfiles/sonatype-work/nexus/storage目录，

资源就可以共享了吗，/nasfiles/sonatype-work/nexus目录下其他的文件和文件夹在服务器A和服务器B是独立的，互补干扰，启动也就没什么问题啦，这个方式应该可行；

可惜，我们的nas盘上面都已经存放的jar和war都已经几十个G啦，提工单又要找公司系统组的人处理，算啦；换个方式，

尝试服务器B上采用软链接的方式吧，测试一下，将服务器B的nexus工作目录下的storage目录删除掉，然后采用软链接

ln -s  /nasfiles/sonatype-work/nexus/storage  ./storage

这样我服务器B的当前工作目录就成了以下情况：

尝试重启服务器B的服务；   nexus restart

启动成功，

为了测试一下效果，先在服务器A上面，下载一些jar包下来，下载jar的方式，本地随便搞一个maven项目，pom.xml中配置一下服务器A的仓库地址，一般直接使用public Repositories这个group组 后面的那个url 就可以啦；或者本地settings.xml配置一下

  <mirrors>
<mirror>
      <id>all</id>
      <mirrorOf>*</mirrorOf>
      <url>http://10.191.9.13:8080/nexus/content/groups/public/</url>
    </mirror>
  </mirrors>

然后mvn install跑一下本地项目，先让服务器A的nexus下载一些jar包

确保服务器A的nexus已经下载了一些jar之后；我们到服务器B的nexus页面上看一眼，会发现服务器A中央仓库中；已经有jar包了，说明我们服务器A的包已经可以在服务器B展现啦；

结束啦，其实没有；

有没有发现服务器B的页面Repositories里面没有我们的在服务器A的nexus页面自己创建的仓库；同样的我们试一下手动传一些jar包到我们的服务器A的自己创建的hosted的仓库上；

分别打开http://服务器A的ip:8080/nexus/content/groups/public/  和  http://服务器B的ip:8080/nexus/content/groups/public/  找一下刚刚上传的jar的位置，会发现A上面有些包在B上不显示，下载也不行；

原因就是因为B上面没有配置过这些仓库，B的public repo的group里面就没有这些库；

继续修改，将A的nexus.xml的内容复制一份到B的nexus.xml里面；

nexus.xml中 的  repositoryTargets    repositoryGrouping   repositories   memberRepositories 标签里面的内容需要保持一致
tasks标签 B节点最好不要

这样从B下载A上面所有的包就不存在问题啦；

至于负载均衡，这个就自己找nginx配置啦，或者我们是直接弄个F5，配置一下负载，问题就搞定啦

我弄的比较简单，配置一下，凡是nexus/content/groups/public开头的，进行负载；非nexus/content/groups/public开头的，全部到A上面，这样用户使用搜索时，请求都是直接到A的，而A上面索引都是全的；

仅仅下载资源会同时用于A和B；