背景
九月初，炎夏褪去，秋微涼，最近，不知從哪一天開始，早上 5 點鐘起床時，天還沒亮；晚上不到 7 點，天已黑；四季的車輪，就在人無所察覺中轟隆而過！
言歸正傳，今天介紹一下 maven 多模塊打包程序中蹚過的點，昨天耗費一整天的時間，就只玩了一個 mvn -X clean install 命令，說多了都是學藝不精交的時間學費，值得反思……
功能描述
近期參與的一個產品，技術組合是 maven 多模塊 + SpringBoot 后端 + Vue.js 前端，
前一陣兒略玩了一下單模塊的打包，昨天被領導安排去部署整個產品，雖說就是一個在父模塊根目錄下執行 mvn -X clean install 的事情，也遭遇了三個只有原來打包同事【已成為前同事】才知道的問題，總結一下，
不出意外的話，打包其實是很容易的事情，將各個模塊 target 目錄下的 moduleName.war 上傳服務器的 Tomcat 的 webapps 目錄下，重啟 Tomcat 即可，工程的 build.xml 腳本將所有目標 war 打包到一個 webapps.zip 檔案，直接 unzip 該檔案，然后上傳即可，
雖然也部署過無數次 web 應用，為避免意外，事先備份了服務器上的 webapps 目錄，事實證明，小心駛得萬年船，程式員的謹慎意識對后來定位問題起到了決定性作用，
問題一：空白頁
部署后，訪問專案選單模塊時，出現了 SpringBoot 空白頁：
問題排查：將這個工程的 war 包還原為備份版本，訪問正常，說明直接原因是 mvn 生成的新包有問題，對比 Tomcat 下的兩個工程目錄，發現空白頁面這個工程的 classes 下沒有 static 靜態資源檔案，
理論上，所有前端代碼都應該通過 npm build 打包對應的 SpringBoot 后端工程的 static 目錄下的，這個空白頁產生大概率是訪問不到前端頁面檔案，難道這個工程沒有打包前端？
為什么這個工程沒有打包前端檔案呢？進入它的 pom.xml 中看:
<id>exec-npm-install</id>
<phase>prepare-package</phase>
沒有配置這個預處理動作，導致前端檔案缺失，除了它，其他所有前后端分離的模塊都有，為什么呢？
一再追問下，前同事都被我的問得不耐煩了，真相竟然是這個模塊不需要重新打包替換，所以沒有配置前端打包命令，
問題二：axios 請求路徑錯誤
解決了第一個問題后，選單功能正常了，但是 F12 看到控制臺一堆 localhost:8080 請求報 404 ,這個問題早有所聞，因為專案多模塊之間沒法完全獨立，所以通過組態檔設定其他模塊的后端請求路徑 ：
const moduleUrl= {
md1: 'http://localhost:8080/m1',
md2: 'http://localhost:8080/m2',
};
export default moduleUrl;
開發環境，不同的后端工程，內置 Tomcat 埠不同，所以配置 moduleUrl 的時候需要注意埠資訊；統一發布到一個 Tomcat 目錄后，埠是統一的，但是路徑中不能用 localhost ，因為這是前端配置，瀏覽訪問 localhost 的時候，視為本機 IP，所以會請求失敗，
解決辦法：全域路徑配置中，區分開發環境和測驗環境，開發環境，直接用相對路徑：
const moduleUrl= {
md1: 'http://localhost:8080/m1',
md2: 'http://localhost:8080/m2',
};
if (process.env.NODE_ENV === 'production') {
moduleUrl.md1 = 'm1';
moduleUrl.md2 = 'm2';
}
export default moduleUrl;
問題三：context-path 配置和發布路徑不一致問題
最后一個問題，是 SpringBoot 的 servlet:context-path 配置和發布路徑不一致導致前端 axios 請求 404 錯誤，
有一個模塊，特立獨行，它的模塊根路徑配置為 / ：
# Tomcat
server:
tomcat:
uri-encoding: UTF-8
max-threads: 1000
min-spare-threads: 30
port: 8084
servlet:
context-path: /
而打包后，該工程為 manager.war ，即部署后，前端應該訪問路徑是 /manager，但所有的 axios 請求都是相對于根路徑的，比如，這個登錄請求：
因此前端爆出一堆 404 ，通過對比備份工程和當前工程的網路請求，發現了該問題，
隱藏的這么深，我一個寫了半年前端的人，咋可能知道嘛！
啟示錄
原以為就是放幾個 war 包的事情，憑我對 Tomcat 的了解，logs 日志里面沒有一個例外，判斷部署流程沒問題，但是前端頁面始終是空白頁，鼓足了被討厭的勇氣，追問前同事了十幾個問題后，終于搞明白了這個簡單部署作業背后要注意的問題，
結論就是，打包真的是個極其考驗耐心的作業，耗時又長，稍有問題，就要重來：
- mvn -X clean install 一次，順利的時候，四十分鐘，忘記關 FTP 目錄，導致 clean 一半失敗了，還要重來；
- 50M 的破網再直連 VPN 上傳 六七個 150MB 左右的檔案，90Kb/s 的速度，上傳完成半個小時到四十分鐘，網速還得看運氣；
- 重啟一次 Tomcat ，5分鐘；
- 被領導扣扣追問進度 3 次，電話催問兩次，總共20分鐘；
- 對比問題包和正常包，以及想到要去對比來定位問題，這個程序一共經過了一小時，
昨天打包這件事，也讓我深刻體會到 IT 行業人員變動的時間成本是多么大呀！這些問題原來負責的人都深切經歷過的坑點，沒有交接給后來人，后者再經歷一次排查，雖然成本都是企業的，但當事人可能是自己，
所以，檔案很重要，今天公司產品的 doc 目錄下已經多了一份打包注意事項，就讓這個問題在我手上終結吧，這就是記錄的意義！
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/7759.html
標籤：其他
上一篇：android 常見面試題（三）
下一篇：程式員的悲哀是什么？