http請(qǐng)求超時(shí)的問(wèn)題排查
問(wèn)題描述
背景：生產(chǎn)環(huán)境中持灰，服務(wù)間內(nèi)網(wǎng)http調(diào)用，偶現(xiàn)超時(shí)怎燥。由于內(nèi)網(wǎng)調(diào)用瘫筐，網(wǎng)絡(luò)開銷理論較小，ToC服務(wù)偏重業(yè)務(wù)铐姚，請(qǐng)求響應(yīng)延時(shí)有一定要求严肪，所以服務(wù)間http請(qǐng)求超時(shí)時(shí)間設(shè)置為1秒鐘，但是通過(guò)監(jiān)控和告警發(fā)現(xiàn)谦屑，服務(wù)運(yùn)行過(guò)程中驳糯，會(huì)偶爾出現(xiàn)請(qǐng)求超時(shí)的現(xiàn)象，需要將問(wèn)題定位氢橙。
// 初始化http client
httpClient := &http.Client{
Timeout: time.Duration(1) * time.Second,
}
// 網(wǎng)絡(luò)調(diào)用
_, _ = httpClient.Do(request)
排查步驟
- 首先請(qǐng)求超時(shí)酝枢，第一反應(yīng)一定是下游處理慢了，于是根據(jù)traceId查看下游服務(wù)日志悍手，發(fā)現(xiàn)服務(wù)根本沒(méi)有收到帘睦。
- 這就有了疑問(wèn)，為啥沒(méi)有收到請(qǐng)求呢坦康。因?yàn)閮?nèi)網(wǎng)調(diào)用走的是域名（nginx）竣付，所以就申請(qǐng)了權(quán)限，看了下nginx日志滞欠，這時(shí)才發(fā)現(xiàn)古胆，nginx是不記錄http header了，所以為了排查問(wèn)題，只好將traceId放在了query里逸绎，這樣nginx就會(huì)在打印uri的時(shí)候惹恃，打印出請(qǐng)求的traceId了。這是很關(guān)鍵的一步棺牧，有助于我們將全鏈路打通巫糙。
- 改動(dòng)之后部署到qa環(huán)境，繼續(xù)期待這個(gè)偶現(xiàn)問(wèn)題的出現(xiàn)颊乘，果真出現(xiàn)了参淹，我們發(fā)現(xiàn)nginx也沒(méi)有收到這條請(qǐng)求，那只有兩個(gè)可能乏悄，報(bào)文在網(wǎng)絡(luò)傳輸?shù)倪^(guò)程中被丟棄了浙值，內(nèi)網(wǎng)環(huán)境，帶寬充足纲爸，這種概率實(shí)在太小亥鸠。那還有另一個(gè)可能妆够，那就是服務(wù)與nginx的鏈接沒(méi)有建立成功识啦，以至于無(wú)法傳輸報(bào)文。
- 由于go http client設(shè)置超時(shí)后神妹，會(huì)將錯(cuò)誤統(tǒng)一封裝成“context deadline exceeded (Client.Timeout exceeded while awaiting headers”颓哮，無(wú)法排查問(wèn)題。于是鸵荠，在初始化的時(shí)候冕茅，設(shè)置tcp鏈接的建立時(shí)間，使其略小于設(shè)置的超時(shí)時(shí)間蛹找，果然一段時(shí)間后姨伤，收到了如下告警“l(fā)ookup xxx i/o timeout”，其大概率是dns解析過(guò)慢庸疾，無(wú)法獲取ip port乍楚，所以無(wú)法建立tcp鏈接。至此届慈，出現(xiàn)請(qǐng)求超時(shí)的問(wèn)題徒溪，終于被我們找到了。
// 初始化http client & 增加tcp建立連接超時(shí)配置
httpClient := &http.Client{
Transport: &http.Transport{
DialContext: (&net.Dialer{
Timeout: 900 * time.Millisecond, // 連接超時(shí)
}).DialContext,
DialTLSContext: (&net.Dialer{
Timeout: 900 * time.Millisecond, // 連接超時(shí)
}).DialContext,
DisableKeepAlives: true,
ForceAttemptHTTP2: true,
TLSHandshakeTimeout: 900 * time.Millisecond,
},
Timeout: time.Duration(2) * time.Second,
}
解決建議
- 配置本地dns
- 可以上k8s金顿，服務(wù)發(fā)現(xiàn)使用ip port臊泌，就沒(méi)有dns這一步，而且k8s對(duì)微服務(wù)的運(yùn)維部署都很友好揍拆，是一個(gè)互聯(lián)網(wǎng)的趨勢(shì)
總結(jié)
問(wèn)題看似簡(jiǎn)單渠概，其實(shí)整體耗費(fèi)了不少時(shí)間，生產(chǎn)環(huán)境出現(xiàn)問(wèn)題嫂拴，還是要認(rèn)真對(duì)待高氮，既是對(duì)公司的業(yè)務(wù)負(fù)責(zé)慧妄，也是對(duì)自己的服務(wù)負(fù)責(zé)。僅此記錄剪芍，與各位開發(fā)者共勉塞淹！
