MAVEN3.9.x的301问题分析及解决

本文主要是针对“构建加速”需求交付过程中，针对maven depoy “301”响应码的现象分析、原因查找、解决方案、技术改造及验证的过程。改造之后，支持用户基于mvnd的构建方式，提升代码构建速度。

01背景

为了提升maven客户端的构建速度，经过调研，了解到mvnd存在以下技术特性：

1. GraalVM的使用，mvnd使用GraalVM替代了传统的JVM，使得启动速度更快，占用的内存更少。GraalVM是一个高性能的运行时，它能够快速启动，并且具有较低的内存占用。这意味着mvnd在启动和运行时的性能都优于使用传统JVM的mvn。
2. 缓存机制，mvnd对于Maven插件的缓存机制也有所改进。在mvn构建过程中，每次构建都需要重新加载和编译所有的Maven插件。而在mvnd中，这些插件被缓存在多个构建中，只有当插件的版本发生变化时，才会重新加载和编译。

基于以上优点，为支持mvnd功能，实现加速构建能力，用户需要将maven版本从3.6.x版本升级到3.9.x版本，用户升级之后在提交构建二进制制品过程当中发现maven 3.9.x版本的兼容性问题。后续就兼容性问题进行识别改造，完成需求交付。

02现象

基于maven3.6.x版本执行deploy动作，所构建制品可以正常发布到nexus仓库。        

基于maven3.9.x版本提交所构建制品失败，收到nexus服务“301”返回码。

03 分析原因

Figure 1 DEPLOY请求示意

用户在本地执行“mvn deploy” 命令之后，本地开始编译构建制品，构建完成之后开始交付所构建制品部署到nexus服务，在部署到nexus之前经由nginx进行代理，之后上传到nexus仓库。

Nginx.conf 配置片段

用户本地pom.xml配置片段

早期版本根据护网安全需求，需要把应用的原始请求资源路径屏蔽掉，在nginx.conf层面进行转发配置，针对用户在pomxml当中配置的屏蔽原始路径之后的仓库地址进行重定向。

针对maven3.6.x版本的交互过程进行分析

1. 在maven3.6.x版本的场景下，执行DEPLOY，观察到第一次请求打到nginx之后，nginx响应301永久重定向，并且在响应头location字段返回新的URL地址；
2. Maven3.6.x 拿到301重定向，根据location的地址，重新发起请求新的URL；
3. 后续交互过程以相同方式完成交互，直至deploy完成。

针对maven3.9.x版本的交互过程进行分析

1. 在maven3.9.x场景下，执行deploy命令，请求到达nginx之后，给出相同的301响应，并且在响应头的location当中指定重定向之后的URL；
2. Maven在拿到重定向响应之后，忽略301，直接开启下一个步骤的请求；
3. 在下一个步骤的交互里面，nginx涛声依旧……，然后就是我们在cmd上面看到的最终的失败的执行结果。

04解决方案及验证

根据上面现象分析，经过验证发现是maven 3.9版本不处理301重定向，根据这个特性，针对nginx进行改造：

upstream nexus_server {         server xxx.xxx.xxx.xxx:xxx max_fails=3 fail_timeout=900s weight=10;     } server {         listen       80;         server_name  test.repo.htsc;         access_log  /var/log/nginx/access.log  ;         error_log  /var/log/nginx/access.log  ;     location /     {           # 摘除/nexus或/nexus/content         rewrite ^/nexus/content/(.*)$ /$1 last;         rewrite ^/nexus/(.*)$ /$1 last;         # 将repositories替换为repository         rewrite ^/(.*)repositories(.*)$ /$1repository$2 last;      ……         expires -1;     } }

针对nginx.conf进行改造，将rewrite 中permannet 永久重定向调整为last，在重写URI之后再次进入locate过滤，直至proxy_pass，将原来依赖客户端处理301的逻辑调整为nginx自身完成URI转换和请求处理，改造之后既减少网络IO，每个请求省了一次交互，又提升了用户的使用体验，提升了deploy的效率。

05结语

本次改造针对若干主要的用户使用deploy的存量和增量场景进行兼容，实现mvnd命令的支持，从IO角度的来说，相比于改造前，省去了重定向请求的网络开销，客户端请求次数减半；从构建加速的角度来说，基于maven3.9.x mvnd方式构建提升构建速度提升10%-20%；有效实现构建环节的加速增效。