今天突然發(fā)生了一件怪事，在內(nèi)測環(huán)境下所有的客戶端通過hessian請求服務(wù)端時(shí)，部分的請求直接返回??'j' is unknow code ，服務(wù)端并不報(bào)錯(cuò)。發(fā)生這個(gè)問題，真把我給急壞了，內(nèi)測環(huán)境是我們上線生產(chǎn)的最后一道關(guān)，如果這個(gè)故障不解決，所有的應(yīng)用都要停止上線，以免給生產(chǎn)系統(tǒng)造成影響。一方面更新郵件不停的在累積，另一方面，出于對(duì)生產(chǎn)系統(tǒng)負(fù)責(zé)的態(tài)度，不敢對(duì)生產(chǎn)環(huán)境進(jìn)行更新。

某大神一直認(rèn)為是項(xiàng)目中的包的版本的問題，不斷的讓我換依賴包的版本，當(dāng)時(shí)我也沒有太好的排查方案，只好先嘗試換換看，換來換去問題依舊。一上午很快就過去了，到下午，無線那邊的產(chǎn)品挨個(gè)找我問我情況，迫于壓力，我回復(fù)產(chǎn)品部門，四點(diǎn)之前一定給出出力結(jié)果。于是我開始自己來分析問題。

1、生產(chǎn)環(huán)境和測試環(huán)境都沒問題，只有內(nèi)測環(huán)境有問題。內(nèi)測環(huán)境的包和生產(chǎn)環(huán)境的包都是一樣的，應(yīng)用的包文件沒有更換過，這樣其實(shí)先排除應(yīng)用內(nèi)部的原因了。(所以說上午聽某大神的換依賴包版本的建議是有多么的離譜了)

2、把內(nèi)測客戶端的RPC的請求地址先換成生產(chǎn)的RPC，排除故障是否與服務(wù)端有關(guān)系。改完測試之后，發(fā)現(xiàn)客戶端和服務(wù)端都沒問題。請求都很正常。說明問題在中間轉(zhuǎn)發(fā)層或者是服務(wù)端。再把RPC的請求地址更換成內(nèi)測服務(wù)端的IP地址（除中間轉(zhuǎn)發(fā)層），發(fā)現(xiàn)請求都正常。排除之后可以肯定，是由于中間層轉(zhuǎn)發(fā)出現(xiàn)了故障造成的。

3、找到運(yùn)維的負(fù)責(zé)請求轉(zhuǎn)發(fā)的同事，讓他檢查了一下，最終確認(rèn)的原因是由于 應(yīng)用防火墻的配置有問題導(dǎo)致請求被攔截造成返回?cái)?shù)據(jù)無法被hassian協(xié)議識(shí)別導(dǎo)致的。修復(fù)應(yīng)用防火墻配置，故障恢復(fù)。

?

hessian 報(bào) 'j' is unknow code故障分析