本文主要是針對“構(gòu)建加速”需求交付過程中，針對maven depoy “301”響應碼的現(xiàn)象分析、原因查找、解決方案、技術(shù)改造及驗證的過程。改造之后，支持用戶基于mvnd的構(gòu)建方式，提升代碼構(gòu)建速度。

01、背景

為了提升maven客戶端的構(gòu)建速度，經(jīng)過調(diào)研，了解到mvnd存在以下技術(shù)特性：

• GraalVM的使用，mvnd使用GraalVM替代了傳統(tǒng)的JVM，使得啟動速度更快，占用的內(nèi)存更少。GraalVM是一個高性能的運行時，它能夠快速啟動，并且具有較低的內(nèi)存占用。這意味著mvnd在啟動和運行時的性能都優(yōu)于使用傳統(tǒng)JVM的mvn。
• 緩存機制，mvnd對于Maven插件的緩存機制也有所改進。在mvn構(gòu)建過程中，每次構(gòu)建都需要重新加載和編譯所有的Maven插件。而在mvnd中，這些插件被緩存在多個構(gòu)建中，只有當插件的版本發(fā)生變化時，才會重新加載和編譯。

基于以上優(yōu)點，為支持mvnd功能，實現(xiàn)加速構(gòu)建能力，用戶需要將maven版本從3.6.x版本升級到3.9.x版本，用戶升級之后在提交構(gòu)建二進制制品過程當中發(fā)現(xiàn)maven 3.9.x版本的兼容性問題。后續(xù)就兼容性問題進行識別改造，完成需求交付。

02、現(xiàn)象

基于maven3.6.x版本執(zhí)行deploy動作，所構(gòu)建制品可以正常發(fā)布到nexus倉庫。        

基于maven3.9.x版本提交所構(gòu)建制品失敗，收到nexus服務“301”返回碼。

03、分析原因

Figure 1 DEPLOY請求示意

用戶在本地執(zhí)行“mvn deploy” 命令之后，本地開始編譯構(gòu)建制品，構(gòu)建完成之后開始交付所構(gòu)建制品部署到nexus服務，在部署到nexus之前經(jīng)由nginx進行代理，之后上傳到nexus倉庫。

Nginx.conf 配置片段

用戶本地pom.xml配置片段

早期版本根據(jù)護網(wǎng)安全需求，需要把應用的原始請求資源路徑屏蔽掉，在nginx.conf層面進行轉(zhuǎn)發(fā)配置，針對用戶在pomxml當中配置的屏蔽原始路徑之后的倉庫地址進行重定向。

針對maven3.6.x版本的交互過程進行分析

• 在maven3.6.x版本的場景下，執(zhí)行DEPLOY，觀察到第一次請求打到nginx之后，nginx響應301永久重定向，并且在響應頭location字段返回新的URL地址；
• Maven3.6.x 拿到301重定向，根據(jù)location的地址，重新發(fā)起請求新的URL；
• 后續(xù)交互過程以相同方式完成交互，直至deploy完成。

針對maven3.9.x版本的交互過程進行分析

• 在maven3.9.x場景下，執(zhí)行deploy命令，請求到達nginx之后，給出相同的301響應，并且在響應頭的location當中指定重定向之后的URL；
• Maven在拿到重定向響應之后，忽略301，直接開啟下一個步驟的請求；
• 在下一個步驟的交互里面，nginx濤聲依舊……，然后就是我們在cmd上面看到的最終的失敗的執(zhí)行結(jié)果。

04、解決方案及驗證

根據(jù)上面現(xiàn)象分析，經(jīng)過驗證發(fā)現(xiàn)是maven 3.9版本不處理301重定向，根據(jù)這個特性，針對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 永久重定向調(diào)整為last，在重寫URI之后再次進入locate過濾，直至proxy_pass，將原來依賴客戶端處理301的邏輯調(diào)整為nginx自身完成URI轉(zhuǎn)換和請求處理，改造之后既減少網(wǎng)絡IO，每個請求省了一次交互，又提升了用戶的使用體驗，提升了deploy的效率。

05、結(jié)語

本次改造針對若干主要的用戶使用deploy的存量和增量場景進行兼容，實現(xiàn)mvnd命令的支持，從IO角度的來說，相比于改造前，省去了重定向請求的網(wǎng)絡開銷，客戶端請求次數(shù)減半；從構(gòu)建加速的角度來說，基于maven3.9.x mvnd方式構(gòu)建提升構(gòu)建速度提升10%-20%；有效實現(xiàn)構(gòu)建環(huán)節(jié)的加速增效。

到此這篇關于MAVEN3.9.x中301問題及解決方法的文章就介紹到這了,更多相關MAVEN3.9.x 301問題內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！

最新評論