在開(kāi)發(fā)交付群里被了一百次“連不上Nexus構(gòu)建全掛了”大概每個(gè)搞過(guò)Java后端、跑過(guò)Maven私服的人都有過(guò)這種經(jīng)歷。Maven連接Nexus報(bào)錯(cuò)的原因五花八門但報(bào)錯(cuò)信息翻來(lái)覆去就那么幾行Connection refused、ConnectException、Could not transfer artifact看著像是同一個(gè)問(wèn)題實(shí)際上可能差著十萬(wàn)八千里。這篇東西就是沖著“速查”兩個(gè)字去的把我在實(shí)際項(xiàng)目里遇到過(guò)的、以及幫別的團(tuán)隊(duì)排查過(guò)的連接被拒絕場(chǎng)景按根因類別全部列出來(lái)每一條都會(huì)問(wèn)你三個(gè)問(wèn)題服務(wù)到底起沒(méi)起、Maven這邊配置對(duì)不對(duì)、網(wǎng)絡(luò)到底通不通。配置文件、排查命令、坑位提醒都會(huì)給到適合正在被構(gòu)建報(bào)錯(cuò)折騰的開(kāi)發(fā)和運(yùn)維同學(xué)也適合剛接手Nexus私服、想搞明白連接機(jī)制的人。1. 連接被拒絕的第一根因Nexus到底“活著”沒(méi)有拿到任何“連接被拒絕”的報(bào)錯(cuò)我從來(lái)不會(huì)先去翻settings.xml而是先確認(rèn)一件事Nexus進(jìn)程到底在不在跑、IP和端口到底能不能通。因?yàn)镃onnection refused這個(gè)英文本身就已經(jīng)說(shuō)得很清楚了——你的請(qǐng)求被操作系統(tǒng)拒絕了也就是說(shuō)目標(biāo)機(jī)器上根本沒(méi)有程序在那個(gè)端口等著你。很多時(shí)候Maven報(bào)錯(cuò)只是表象真正的根因是Nexus服務(wù)壓根沒(méi)起來(lái)或者是起了但監(jiān)聽(tīng)地址不對(duì)。1.1 最容易被忽略的順序問(wèn)題先確認(rèn)服務(wù)狀態(tài)很多團(tuán)隊(duì)習(xí)慣把Nexus部署在專門的一臺(tái)服務(wù)器上或者放在某個(gè)虛擬機(jī)的容器里。Nexus沒(méi)起來(lái)的原因又特別多進(jìn)程被kill了、機(jī)器重啟以后忘了設(shè)置開(kāi)機(jī)自啟、磁盤(pán)滿了導(dǎo)致啟動(dòng)失敗。更隱蔽的情況是服務(wù)起來(lái)了但還沒(méi)完全就緒——Nexus啟動(dòng)過(guò)程中會(huì)有一段時(shí)間對(duì)外端口已經(jīng)打開(kāi)了但內(nèi)部應(yīng)用還沒(méi)準(zhǔn)備好這時(shí)候發(fā)過(guò)去的請(qǐng)求同樣可能被重置或者被拒絕。排查時(shí)用一條命令就能快速定位# 在Nexus服務(wù)器本機(jī)上檢查進(jìn)程 ps -ef | grep nexus # 或者查看端口監(jiān)聽(tīng)狀態(tài)Linux ss -lntp | grep 8081如果進(jìn)程存在但端口沒(méi)有LISTEN說(shuō)明啟動(dòng)過(guò)程卡住了或者配置的端口不是8081。如果端口在LISTEN但本機(jī)訪問(wèn)仍然失敗先懷疑是不是防火墻攔了回環(huán)地址。這里有個(gè)很經(jīng)典的坑很多人把Nexus裝好以后第一次啟動(dòng)一直報(bào)錯(cuò)后來(lái)發(fā)現(xiàn)是啟動(dòng)腳本參數(shù)里指定了低版本JDK路徑而Nexus版本要求JDK版本更高導(dǎo)致JVM起來(lái)后立刻崩掉進(jìn)程反復(fù)重啟。這類問(wèn)題不能光看Maven的報(bào)錯(cuò)得去Nexus的日志目錄看啟動(dòng)日志sonatype-work/nexus3/log/下面通常有nexus.log和jvm.log任何啟動(dòng)階段的異常都會(huì)寫(xiě)在這里。1.2 端口和地址確認(rèn)8081不是唯一答案Nexus3的默認(rèn)端口是8081但生產(chǎn)環(huán)境很多團(tuán)隊(duì)會(huì)改掉這個(gè)端口或者用反向代理把外部8080映射到內(nèi)部8081。排查連接問(wèn)題之前必須確認(rèn)Maven訪問(wèn)的地址和Nexus實(shí)際監(jiān)聽(tīng)地址完全一致。在Nexus服務(wù)器上執(zhí)行curl -v http://localhost:8081/service/rest/v1/status這行命令返回JSON并且HTTP狀態(tài)碼是200的話說(shuō)明服務(wù)正常。返回Connection refused說(shuō)明服務(wù)沒(méi)起來(lái)或端口不對(duì)。返回超時(shí)說(shuō)明端口被防火墻靜默丟棄了。需要注意的是Nexus3的REST API路徑在不同版本上略有差異但/service/rest/v1/status這個(gè)路徑從Nexus3.20以后一直很穩(wěn)定。提示如果你用Docker啟動(dòng)Nexus別忘記檢查端口映射。docker ps里顯示的宿主機(jī)端口和容器內(nèi)部端口都要確認(rèn)-p 8081:8081這種映射方式把宿主機(jī)的8081映射到容器的8081如果宿主機(jī)8081被別的進(jìn)程占用了容器可能啟動(dòng)成功但端口沒(méi)綁上。2. Maven側(cè)配置settings.xml里那些“自作主張”的坑如果Nexus這邊一切正常問(wèn)題就轉(zhuǎn)移到Maven這一側(cè)。Maven的settings.xml是全局配置文件里面配了mirror、server、proxy等一堆東西任何一個(gè)字段寫(xiě)錯(cuò)都能造成連接失敗。而且Maven報(bào)錯(cuò)經(jīng)常是嵌套的外層寫(xiě)著Could not transfer artifact內(nèi)層才藏著你真正需要看的異常信息。很多人只看前兩行就開(kāi)始懷疑網(wǎng)絡(luò)結(jié)果折騰半天發(fā)現(xiàn)就是URL少寫(xiě)了一個(gè)字母。2.1 mirrors和repositories的address糾錯(cuò)Maven查找依賴的順序是先讀settings.xml里的mirror配置如果不匹配再讀pom.xml里的repository。連接被拒絕最常見(jiàn)的原因是settings.xml里的mirror配置指向了一個(gè)錯(cuò)誤的倉(cāng)庫(kù)地址。mirror idlocal-nexus/id mirrorOf*/mirrorOf urlhttp://192.168.1.100:8081/repository/maven-public//url /mirror這段配置看起來(lái)人畜無(wú)害但出問(wèn)題的點(diǎn)往往不在格式而在URL本身。第一個(gè)坑末尾的斜杠。Nexus的repository路徑必須以斜杠結(jié)尾如果漏掉了Maven拼接路徑時(shí)會(huì)直接拼出一個(gè)奇怪的URL比如repository/maven-public/com/example/xxx.jar前者正常后者卻會(huì)報(bào)404而不是Connection refused。第二個(gè)坑協(xié)議。有人配了https://開(kāi)頭的URL但Nexus實(shí)際只開(kāi)了HTTP監(jiān)聽(tīng)這就會(huì)直接握手失敗報(bào)出來(lái)的錯(cuò)誤五花八門有時(shí)候是SSLHandshakeException有時(shí)候直接就是Connection refused。第三個(gè)坑hostname解析。你寫(xiě)的是域名但這個(gè)域名在構(gòu)建機(jī)上的DNS和hosts文件里根本沒(méi)有映射那請(qǐng)求就是往一個(gè)不存在的地址上發(fā)報(bào)錯(cuò)也經(jīng)常是Connection refused。排查方式很簡(jiǎn)單把配的URL直接復(fù)制到瀏覽器或curl里訪問(wèn)curl -I http://192.168.1.100:8081/repository/maven-public/如果返回HTTP/1.1 200說(shuō)明地址沒(méi)問(wèn)題。如果返回301或302說(shuō)明Nexus配置了HTTP→HTTPS重定向那你Maven里的URL也得跟著改成https。這個(gè)情況比大家想象中要多很多團(tuán)隊(duì)在Nexus前面掛了Nginx或者自己買了SSL證書(shū)HTTP的8081對(duì)外已經(jīng)不可見(jiàn)了。2.2 server認(rèn)證配置的坑Nexus默認(rèn)設(shè)置了匿名訪問(wèn)權(quán)限但生產(chǎn)環(huán)境通常都會(huì)關(guān)掉匿名或者只對(duì)特定倉(cāng)庫(kù)開(kāi)匿名。一旦Nexus要求認(rèn)證而Maven側(cè)沒(méi)有配置正確的server憑據(jù)報(bào)錯(cuò)可能就不是401 Unauthorized那么直白。Maven在某些版本、某些傳輸場(chǎng)景下會(huì)把401包裝成Could not transfer artifact甚至顯示為Repository blocked。正確的配置方式是servers server idlocal-nexus/id usernamedeployer/username passwordpassword/password /server /servers這里有一個(gè)極其隱蔽的坑id必須和mirror或者repository配置里的id完全一致。你看好了是“完全一致”包括大小寫(xiě)和字符。因?yàn)镸aven匹配憑據(jù)的時(shí)候就是通過(guò)這個(gè)id去servers列表里找對(duì)應(yīng)配置的。id對(duì)不上Maven根本不會(huì)把用戶名密碼帶上那Nexus返回401或403Maven這邊看到的就是連接失敗或者認(rèn)證失敗。另外密碼里如果帶有特殊字符比如、、在XML里必須做轉(zhuǎn)義否則settings.xml直接解析失敗Maven會(huì)報(bào)錯(cuò)“malformed POM”或者干脆無(wú)法啟動(dòng)構(gòu)建很多人遇到這種問(wèn)題還以為是Java環(huán)境壞了。2.3 HTTP/HTTPS與代理端口還有一個(gè)經(jīng)常被忽略的場(chǎng)景你所在的環(huán)境是內(nèi)網(wǎng)開(kāi)發(fā)環(huán)境但本機(jī)也配了HTTP代理比如公司辦公網(wǎng)絡(luò)要求所有HTTP請(qǐng)求走代理。settings.xml里的proxies配置會(huì)影響到Maven發(fā)起的所有連接。一旦代理服務(wù)器本身不通Maven訪問(wèn)Nexus也會(huì)報(bào)Connection refused但這個(gè)refused的對(duì)象其實(shí)是代理服務(wù)器而不是Nexus本身。proxies proxy idoffice-proxy/id activetrue/active protocolhttp/protocol hostproxy.company.com/host port8080/port nonProxyHosts192.168.1.*|localhost/nonProxyHosts /proxy /proxiesnonProxyHosts字段用豎線分隔多個(gè)地址支持通配符。如果這里沒(méi)把內(nèi)網(wǎng)Nexus地址加進(jìn)去那么每一次下載依賴都會(huì)繞路到外網(wǎng)代理既慢又容易失敗。很多項(xiàng)目連接Nexus時(shí)好時(shí)壞罪魁禍?zhǔn)拙褪沁@臺(tái)代理服務(wù)器偶爾抽風(fēng)。建議排查的時(shí)候直接先臨時(shí)把a(bǔ)ctive改成false再跑一把mvn構(gòu)建如果問(wèn)題消失那說(shuō)明就是代理配置的問(wèn)題。3. 網(wǎng)絡(luò)與環(huán)境從localhost到防火墻的層層關(guān)卡前面兩步都排查過(guò)了Nexus活著、Maven配置正確但依然連接失敗那問(wèn)題就出在請(qǐng)求路徑的中間環(huán)境里。這里的“中間環(huán)境”可能是真實(shí)的防火墻也可能是容器網(wǎng)絡(luò)、云平臺(tái)安全組、虛擬機(jī)網(wǎng)絡(luò)模式甚至只是一個(gè)寫(xiě)錯(cuò)了的hosts映射。這個(gè)階段的排查思路應(yīng)該分層進(jìn)行每次只“打通”一層逐步縮小故障范圍。3.1 同一臺(tái)機(jī)器 vs 遠(yuǎn)程訪問(wèn)bind addressNexus默認(rèn)會(huì)監(jiān)聽(tīng)所有網(wǎng)卡的8081端口但有些部署方式里啟動(dòng)參數(shù)會(huì)修改成只監(jiān)聽(tīng)某個(gè)IP。比如在nexus.vmoptions文件里或者啟動(dòng)腳本中設(shè)置了-Djava.net.preferIPv4Stacktrue或者Nexus的application.properties如果存在里指定了application-host參數(shù)。如果配置了只監(jiān)聽(tīng)127.0.0.1那么Maven從另外一臺(tái)機(jī)器來(lái)訪問(wèn)就是白搭報(bào)出來(lái)就是Connection refused。驗(yàn)證方式是在開(kāi)發(fā)機(jī)上執(zhí)行telnet 192.168.1.100 8081能通的話說(shuō)明Nexus對(duì)遠(yuǎn)程訪問(wèn)是開(kāi)放的。不通的話登錄服務(wù)器再執(zhí)行一次ss -lntp | grep 8081看看監(jiān)聽(tīng)地址是0.0.0.0:8081、*:8081還是具體的局域網(wǎng)IP。如果是127.0.0.1:8081說(shuō)明配置把綁定地址限制在回環(huán)接口上了。這時(shí)候可以到安裝目錄下檢查etc/nexus.properties或者啟動(dòng)時(shí)追加的JVM參數(shù)把a(bǔ)pplication-host的值改成0.0.0.0或者在啟動(dòng)命令里去掉這個(gè)限制。3.2 防火墻、安全組、容器網(wǎng)絡(luò)的排查思路Linux服務(wù)器上最常見(jiàn)的攔截者是iptables、firewalld或者ufw。很多服務(wù)器管理員會(huì)把默認(rèn)策略設(shè)為DROP沒(méi)有顯式放行8081端口的話外部的連接請(qǐng)求會(huì)被靜默丟棄表現(xiàn)不是Connection refused而是timeout。如果你看到的是refused說(shuō)明對(duì)方服務(wù)器對(duì)你的請(qǐng)求發(fā)了RST包也就是說(shuō)端口可能沒(méi)監(jiān)聽(tīng)但如果是timeout那大概率就是防火墻把包丟了。容器環(huán)境里還有一個(gè)額外的坑Nexus跑在某個(gè)Docker容器里容器網(wǎng)絡(luò)是bridge模式宿主機(jī)做了-p端口映射。此時(shí)從宿主機(jī)訪問(wèn)沒(méi)問(wèn)題但從另一臺(tái)機(jī)器訪問(wèn)就要看宿主機(jī)的防火墻、云安全組是否放行了8081端口。很多人遇到的情況是開(kāi)發(fā)機(jī)的telnet能通Nexus所在服務(wù)器IP的8081但是從另一臺(tái)網(wǎng)絡(luò)環(huán)境奇特的機(jī)器上就是不通最后發(fā)現(xiàn)是兩個(gè)子網(wǎng)之間的ACL規(guī)則沒(méi)放行或者云平臺(tái)安全組只允許了辦公網(wǎng)段訪問(wèn)。注意即使你用Docker跑Nexus也不要忘掉容器內(nèi)部還有一層網(wǎng)絡(luò)命名空間。進(jìn)入容器用docker exec -it [容器ID] curl http://localhost:8081/service/rest/v1/status可以驗(yàn)證容器內(nèi)部服務(wù)本身是否正常這能幫你區(qū)分是容器服務(wù)問(wèn)題還是端口映射問(wèn)題。3.3 用telnet/curl/nc快速定位故障層級(jí)連接問(wèn)題的排查一定要用“最小化命令”去定位不要一上來(lái)就mvn clean package。我自己習(xí)慣這樣一層層試# 第一層DNS/域名解析 ping my-nexus.example.com # 或者 nslookup my-nexus.example.com # 第二層端口連通性 telnet my-nexus.example.com 8081 # 或者 nc -vz my-nexus.example.com 8081 # 第三層HTTP服務(wù)可達(dá)性 curl -v http://my-nexus.example.com:8081/repository/maven-public/如果telnet都連不通說(shuō)明問(wèn)題出在網(wǎng)絡(luò)層再去糾結(jié)Maven配置沒(méi)有意義。如果telnet通但curl返回異常比如HTTP狀態(tài)碼是400或者500那就進(jìn)入應(yīng)用層排查看Nexus的后臺(tái)日志。還有一類罕見(jiàn)情況telnet能通curl也能通但mvn構(gòu)建依然報(bào)Connection refused這是因?yàn)镸aven在解析settings.xml或者pom.xml里的repository URL時(shí)做了變量替換實(shí)際請(qǐng)求的地址和你在curl里測(cè)試的地址根本不一樣。這時(shí)候要靠Maven的調(diào)試日志來(lái)定位mvn clean install -X -DskipTests日志里會(huì)打印出每個(gè)依賴下載的實(shí)際URL照著那個(gè)URL再去curl通常就能發(fā)現(xiàn)問(wèn)題。4. 常見(jiàn)錯(cuò)誤信息速查與一攬子解決方案做技術(shù)排障不能靠猜得靠“從現(xiàn)象反推原因”。這里把Maven連接Nexus時(shí)最常出現(xiàn)的幾類報(bào)錯(cuò)信息整理成一張速查思路表每條列出典型報(bào)錯(cuò)、可能的根因以及首選排查動(dòng)作。注意這里的報(bào)錯(cuò)信息只是“線索”最終診斷必須結(jié)合前文的排查流程綜合判斷。報(bào)錯(cuò)現(xiàn)象關(guān)鍵詞典型根因首選排查動(dòng)作Connection refused / ConnectExceptionNexus服務(wù)未啟動(dòng)、端口錯(cuò)誤、防火墻拒絕、監(jiān)聽(tīng)地址受限登錄服務(wù)器查進(jìn)程執(zhí)行 ss -lntpConnection timed out防火墻DROP策略、跨網(wǎng)段ACL攔截、服務(wù)器宕機(jī)檢查云安全組/防火墻規(guī)則ping和telnet逐步定位SSLHandshakeExceptionNexus使用的HTTPS證書(shū)過(guò)期或Maven側(cè)URL協(xié)議錯(cuò)誤換成http測(cè)試或更新JDK信任庫(kù)里的證書(shū)HTTP 401 Unauthorized認(rèn)證憑據(jù)缺失或服務(wù)器id不匹配檢查settings.xml中的servers配置確保id一致HTTP 403 Forbidden用戶權(quán)限不足登錄Nexus檢查該用戶是否有對(duì)應(yīng)倉(cāng)庫(kù)的訪問(wèn)權(quán)限HTTP 404 Not Foundrepository名稱或路徑拼寫(xiě)錯(cuò)誤在Nexus Web界面查看實(shí)際倉(cāng)庫(kù)名并核對(duì)URLCould not transfer artifact多種原因最常見(jiàn)是鏡像URL錯(cuò)誤或代理配置錯(cuò)誤查看Maven -X日志中打印的最終下載地址Repository blocked遠(yuǎn)程倉(cāng)庫(kù)被Nexus誤判為不可用登錄Nexus后臺(tái)查看倉(cāng)庫(kù)狀態(tài)嘗試重新連接遠(yuǎn)程倉(cāng)庫(kù)UnknownHostExceptionDNS解析失敗檢查hosts文件或DNS服務(wù)器配置MalformedURLExceptionURL地址中協(xié)議、端口或路徑格式錯(cuò)誤檢查settings.xml中url字段是否缺少斜杠或包含非法字符4.1 Connection refused 與 timeout 的語(yǔ)義區(qū)別這個(gè)值得單獨(dú)拎出來(lái)講。Connection refused和Connection timeout雖然都表現(xiàn)為“連不上”但底層邏輯完全不同。Connection refused是TCP層收到了對(duì)方的RST包換句話說(shuō)目標(biāo)主機(jī)的網(wǎng)絡(luò)棧是通的但它告訴你“這個(gè)端口我沒(méi)法連接”通常是服務(wù)沒(méi)監(jiān)聽(tīng)或者防火墻主動(dòng)拒絕。Connection timeout則是發(fā)出了SYN包但一直沒(méi)等到回應(yīng)多半是包被丟棄了典型場(chǎng)景是防火墻DROP策略、路由器ACL或者目標(biāo)主機(jī)宕機(jī)。所以當(dāng)你拿到報(bào)錯(cuò)時(shí)第一反應(yīng)應(yīng)該是看“關(guān)鍵字”。我的習(xí)慣是看到refused優(yōu)先查“服務(wù)是否啟動(dòng)”其次查“端口監(jiān)聽(tīng)地址”最后查“防火墻是否顯式REJECT”看到timeout優(yōu)先查“網(wǎng)絡(luò)路由是否可達(dá)”其次查“云安全組”最后查“目標(biāo)服務(wù)器是否宕機(jī)”4.2 401、403 等權(quán)限類錯(cuò)誤的聯(lián)動(dòng)排查權(quán)限類錯(cuò)誤看起來(lái)和“連接被拒絕”無(wú)關(guān)但在Nexus里這兩者經(jīng)常被串在一起。最典型的場(chǎng)景是匿名用戶沒(méi)有任何倉(cāng)庫(kù)的查看權(quán)限Nexus直接拒絕連接請(qǐng)求表現(xiàn)就是Maven下載依賴時(shí)連續(xù)報(bào)錯(cuò)看起來(lái)像網(wǎng)絡(luò)不可達(dá)。第二次遇到類似問(wèn)題時(shí)我會(huì)先打開(kāi)Nexus后臺(tái)看一下對(duì)應(yīng)倉(cāng)庫(kù)的“Anonymous Access”是否被勾選了。在Nexus3的管理界面中Settings → Security → Anonymous Access可以控制匿名訪問(wèn)而每個(gè)倉(cāng)庫(kù)的Repository → Settings → Security里還有細(xì)粒度的權(quán)限控制。生產(chǎn)環(huán)境建議關(guān)閉匿名但關(guān)閉的同時(shí)必須確保所有開(kāi)發(fā)機(jī)上的settings.xml都配了正確的server憑據(jù)否則所有人都會(huì)連不上那時(shí)候就別談什么“連接被拒絕”了那叫“權(quán)限管理事故”。4.3 快速檢查清單三步從報(bào)錯(cuò)到定位為了不讓自己在排障時(shí)漏掉細(xì)節(jié)我給自己擬了一張“三步走”清單每次都能在十分鐘內(nèi)從報(bào)錯(cuò)信息定位到根因跑一次帶調(diào)試日志的構(gòu)建把-X輸出的完整報(bào)錯(cuò)截圖或者復(fù)制下來(lái)重點(diǎn)看最底部的Caused by因?yàn)槟莻€(gè)才是真正的異常源頭。拿報(bào)錯(cuò)里的URL地址直接去telnet和curl測(cè)試服務(wù)是否真的“拒絕連接”用最小化手段復(fù)現(xiàn)不要帶著Maven的整個(gè)依賴解析流程去猜。逐項(xiàng)對(duì)照上面表格里的“典型根因”最可疑的候選先驗(yàn)證驗(yàn)證方式就是修改一處配置后重新跑一次構(gòu)建能復(fù)現(xiàn)就說(shuō)明沒(méi)改對(duì)不能復(fù)現(xiàn)就說(shuō)明命中根因。這三步的核心思想是“剝離層次、逐級(jí)排雷”。Maven構(gòu)建只是客戶端它的報(bào)錯(cuò)信息本質(zhì)上就是HTTP或者網(wǎng)絡(luò)層的異常包裝把包裝拆掉底層的真相并不難找。5. 實(shí)操記錄一次完整Nexus連接故障的排查復(fù)盤(pán)前面講了一堆方法不如直接看一次真實(shí)排查過(guò)程。這個(gè)案例發(fā)生在某公司的Java微服務(wù)項(xiàng)目里場(chǎng)景是十幾臺(tái)構(gòu)建機(jī)器分批執(zhí)行CI構(gòu)建某天早上突然大面積失敗報(bào)錯(cuò)全部是Connection refused。公司IT環(huán)境屬于內(nèi)網(wǎng)部署Nexus跑在一臺(tái)虛擬機(jī)里IP地址是192.168.10.20端口8081構(gòu)建機(jī)的Maven配置了統(tǒng)一的settings.xml鏡像指向它。5.1 從報(bào)錯(cuò)到定位分段排查的完整邏輯當(dāng)天早上故障一報(bào)出來(lái)我先看的是CI日志連續(xù)翻了十幾個(gè)都是同一個(gè)錯(cuò)誤——Could not transfer artifact ... Connection refused。第一反應(yīng)是Nexus服務(wù)掛了。于是登錄192.168.10.20服務(wù)器執(zhí)行ps -ef | grep nexus進(jìn)程存在但再執(zhí)行ss -lntp | grep 8081發(fā)現(xiàn)8081端口根本沒(méi)有監(jiān)聽(tīng)。當(dāng)時(shí)心里“咯噔”一下因?yàn)檫M(jìn)程在但端口沒(méi)綁定這通常意味著Nexus啟動(dòng)到一半卡住了。緊接著看了日志文件發(fā)現(xiàn)最后的記錄是ES索引初始化失敗導(dǎo)致整個(gè)應(yīng)用無(wú)法完成啟動(dòng)流程N(yùn)exus進(jìn)程雖然在跑但JVM內(nèi)部并沒(méi)進(jìn)入可用狀態(tài)。處理完索引問(wèn)題重啟Nexus端口正常監(jiān)聽(tīng)了。但CI重跑依然有部分機(jī)器報(bào)Connection refused。這時(shí)候我卻注意到報(bào)錯(cuò)機(jī)器和正常機(jī)器之間的差異——報(bào)錯(cuò)的都是最近新擴(kuò)容的構(gòu)建機(jī)正常的都是老機(jī)器。再一查發(fā)現(xiàn)新構(gòu)建機(jī)上的settings.xml是從另一個(gè)團(tuán)隊(duì)倉(cāng)庫(kù)里拷來(lái)的鏡像URL寫(xiě)的是http://192.168.10.21:8081/repository/maven-public/把地址寫(xiě)錯(cuò)了。高可用方案里Nexus有第二個(gè)節(jié)點(diǎn)新機(jī)器配置寫(xiě)的是故障節(jié)點(diǎn)的IP而故障節(jié)點(diǎn)已經(jīng)下線了。只改掉這一處配置后全部構(gòu)建恢復(fù)。這次排查其實(shí)踩了一個(gè)很典型的“思維定式”坑第一輪看到連接被拒絕我的注意力全在服務(wù)狀態(tài)上等確認(rèn)服務(wù)正常后沒(méi)有再重新審視“報(bào)錯(cuò)的都是哪些機(jī)器、它們和正常機(jī)器有什么區(qū)別”。如果把機(jī)器分組和配置差異核查提前到第二位至少能省出一輪CI重跑的等待時(shí)間。5.2 故障加固建議日志、監(jiān)控與公共配置在排查修復(fù)之后我還給團(tuán)隊(duì)做了三件事防止類似問(wèn)題再次造成大面積故障。第一給Nexus的啟動(dòng)和運(yùn)行狀態(tài)做基礎(chǔ)監(jiān)控不需要很復(fù)雜的系統(tǒng)只要能每分鐘探測(cè)一次/service/rest/v1/status接口并告警就行。第二修改統(tǒng)一分發(fā)settings.xml的方式不再允許各項(xiàng)目組自己復(fù)制粘貼配置而是走配置中心統(tǒng)一管理鏡像地址、server憑據(jù)全部做好版本控制。第三在構(gòu)建腳本里把Maven的調(diào)試日志默認(rèn)打開(kāi)一份輸出到固定目錄以后再有連接類報(bào)錯(cuò)別問(wèn)開(kāi)發(fā)同學(xué)“報(bào)什么錯(cuò)”直接讓他們把日志文件發(fā)過(guò)來(lái)手工定位的時(shí)間至少縮短一半。這套“監(jiān)測(cè)配置治理日志留存”的組合拳雖然不是解決“連接被拒絕”的直接操作但屬于事后避免同樣問(wèn)題再次發(fā)生的有效手段。真正負(fù)責(zé)Nexus或者CI基礎(chǔ)設(shè)施的同學(xué)我建議也照著這套思路做不然就算今天把問(wèn)題修好了下周換一批機(jī)器、換一個(gè)網(wǎng)段同樣的坑還會(huì)再踩一遍。寫(xiě)在最后我個(gè)人在實(shí)際排查Nexus連接被拒這類問(wèn)題時(shí)逐漸養(yǎng)成了一個(gè)強(qiáng)迫癥永遠(yuǎn)先問(wèn)“服務(wù)在哪、監(jiān)聽(tīng)在哪、通不通”再問(wèn)“配置寫(xiě)了什么、憑據(jù)對(duì)不對(duì)”最后才去懷疑代碼和構(gòu)建流程本身。這里有一個(gè)不太容易從官方文檔里學(xué)到的經(jīng)驗(yàn)——用mvn -X輸出來(lái)定位連接問(wèn)題時(shí)請(qǐng)同時(shí)關(guān)注Maven解析配置的“順序”和“結(jié)果”因?yàn)橛卸嗵诅R像、多個(gè)repository存在的時(shí)候Maven到底走了哪條路徑往往比報(bào)錯(cuò)內(nèi)容本身更能暴露問(wèn)題。以后再遇到Connection refused希望你第一反應(yīng)不是煩躁而是把這篇手冊(cè)里的速查表對(duì)照一遍。大部分場(chǎng)景下問(wèn)題都能在十分鐘內(nèi)水落石出。