為什么需要超時(shí)控制鲸鹦？
很多連鎖故障的場(chǎng)景下的一個(gè)常見問題是服務(wù)器正在消耗大量資源處理那些早已經(jīng)超過客戶端截止時(shí)間的請(qǐng)求慧库，這樣的結(jié)果是，服務(wù)器消耗大量資源沒有做任何有價(jià)值的工作馋嗜，回復(fù)已經(jīng)超時(shí)的請(qǐng)求是沒有任何意義的齐板。
超時(shí)控制可以說是保證服務(wù)穩(wěn)定性的一道重要的防線，它的本質(zhì)是快速失敗(fail fast)嵌戈，良好的超時(shí)控制策略可以盡快清空高延遲的請(qǐng)求覆积，盡快釋放資源避免請(qǐng)求的堆積。
服務(wù)間超時(shí)傳遞
如果一個(gè)請(qǐng)求有多個(gè)階段熟呛，比如由一系列 RPC 調(diào)用組成宽档，那么我們的服務(wù)應(yīng)該在每個(gè)階段開始前檢查截止時(shí)間以避免做無用功，也就是要檢查是否還有足夠的剩余時(shí)間處理請(qǐng)求庵朝。
一個(gè)常見的錯(cuò)誤實(shí)現(xiàn)方式是在每個(gè) RPC 服務(wù)設(shè)置一個(gè)固定的超時(shí)時(shí)間吗冤，我們應(yīng)該在每個(gè)服務(wù)間傳遞超時(shí)時(shí)間，超時(shí)時(shí)間可以在服務(wù)調(diào)用的最上層設(shè)置九府，由初始請(qǐng)求觸發(fā)的整個(gè) RPC 樹會(huì)設(shè)置同樣的絕對(duì)截止時(shí)間椎瘟。例如，在服務(wù)請(qǐng)求的最上層設(shè)置超時(shí)時(shí)間為3s侄旬，服務(wù)A請(qǐng)求服務(wù)B肺蔚，服務(wù)B執(zhí)行耗時(shí)為1s，服務(wù)B再請(qǐng)求服務(wù)C這時(shí)超時(shí)時(shí)間剩余2s儡羔，服務(wù)C執(zhí)行耗時(shí)為1s宣羊，這時(shí)服務(wù)C再請(qǐng)求服務(wù)D璧诵，服務(wù)D執(zhí)行耗時(shí)為500ms，以此類推仇冯，理想情況下在整個(gè)調(diào)用鏈里都采用相同的超時(shí)傳遞機(jī)制之宿。
如果不采用超時(shí)傳遞機(jī)制，那么就會(huì)出現(xiàn)如下情況：
- 服務(wù)A給服務(wù)B發(fā)送一個(gè)請(qǐng)求苛坚，設(shè)置的超時(shí)時(shí)間為3s
- 服務(wù)B處理請(qǐng)求耗時(shí)為2s比被，并且繼續(xù)請(qǐng)求服務(wù)C
- 如果使用了超時(shí)傳遞那么服務(wù)C的超時(shí)時(shí)間應(yīng)該為1s，但這里沒有采用超時(shí)傳遞所以超時(shí)時(shí)間為在配置中寫死的3s
- 服務(wù)C繼續(xù)執(zhí)行耗時(shí)為2s泼舱，其實(shí)這時(shí)候最上層設(shè)置的超時(shí)時(shí)間已截止等缀，如下的請(qǐng)求無意義
- 繼續(xù)請(qǐng)求服務(wù)D
如果服務(wù)B采用了超時(shí)傳遞機(jī)制，那么在服務(wù)C就應(yīng)該立刻放棄該請(qǐng)求柠掂，因?yàn)橐呀?jīng)到了截止時(shí)間项滑，客戶端可能已經(jīng)報(bào)錯(cuò)。我們?cè)谠O(shè)置超時(shí)傳遞的時(shí)候一般會(huì)將傳遞出去的截止時(shí)間減少一點(diǎn)涯贞，比如100毫秒枪狂，以便將網(wǎng)絡(luò)傳輸時(shí)間和客戶端收到回復(fù)之后的處理時(shí)間考慮在內(nèi)。
進(jìn)程內(nèi)超時(shí)傳遞
不光服務(wù)間需要超時(shí)傳遞進(jìn)程內(nèi)同樣需要進(jìn)行超時(shí)傳遞宋渔，比如在一個(gè)進(jìn)程內(nèi)串行的調(diào)用了Mysql州疾、Redis和服務(wù)B，設(shè)置總的請(qǐng)求時(shí)間為3s皇拣，請(qǐng)求Mysql耗時(shí)1s后再次請(qǐng)求Redis這時(shí)的超時(shí)時(shí)間為2s严蓖，Redis執(zhí)行耗時(shí)500ms再請(qǐng)求服務(wù)B這時(shí)候超時(shí)時(shí)間為1.5s，因?yàn)槲覀兊拿總€(gè)中間件或者服務(wù)都會(huì)在配置文件中設(shè)置一個(gè)固定的超時(shí)時(shí)間氧急，我們需要取剩余時(shí)間和設(shè)置時(shí)間中的最小值颗胡。
context實(shí)現(xiàn)超時(shí)傳遞
context原理非常簡(jiǎn)單，但功能卻非常強(qiáng)大吩坝，go的標(biāo)準(zhǔn)庫也都已實(shí)現(xiàn)了對(duì)context的支持毒姨，各種開源的框架也實(shí)現(xiàn)了對(duì)context的支持，context已然成為了標(biāo)準(zhǔn)钉寝，超時(shí)傳遞也依賴context來實(shí)現(xiàn)弧呐。
我們一般在服務(wù)的最上層通過設(shè)置初始context進(jìn)行超時(shí)控制傳遞，比如設(shè)置超時(shí)時(shí)間為3s
ctx, cancel := context.WithTimeout(context.Background(), time.Second*3)
defer cancel()
當(dāng)進(jìn)行context傳遞的時(shí)候嵌纲，比如上圖中請(qǐng)求Redis俘枫，那么通過如下方式獲取剩余時(shí)間，然后對(duì)比Redis設(shè)置的超時(shí)時(shí)間取較小的時(shí)間
dl, ok := ctx.Deadline()
timeout := time.Now().Add(time.Second * 3)
if ok := dl.Before(timeout); ok {
timeout = dl
}
服務(wù)間超時(shí)傳遞主要是指 RPC 調(diào)用時(shí)候的超時(shí)傳遞逮走，對(duì)于 gRPC 來說并不需要要我們做額外的處理鸠蚪，gRPC 本身就支持超時(shí)傳遞，原理和上面差不多，是通過 metadata 進(jìn)行傳遞邓嘹，最終會(huì)被轉(zhuǎn)化為 grpc-timeout 的值酣栈，如下代碼所示 grpc-go/internal/transport/handler_server.go:79
if v := r.Header.Get("grpc-timeout"); v != "" {
to, err := decodeTimeout(v)
if err != nil {
return nil, status.Errorf(codes.Internal, "malformed time-out: %v", err)
}
st.timeoutSet = true
st.timeout = to
}
超時(shí)傳遞是保證服務(wù)穩(wěn)定性的一道重要防線，原理和實(shí)現(xiàn)都非常簡(jiǎn)單汹押，你們的框架中實(shí)現(xiàn)了超時(shí)傳遞了嗎？如果沒有的話就趕緊動(dòng)起手來吧起便。
go-zero 中的超時(shí)傳遞
go-zero 中可以通過配置文件中的 Timeout 配置 api gateway 和 rpc 服務(wù)的超時(shí)棚贾，并且會(huì)在服務(wù)間自動(dòng)傳遞。
之前的 一文搞懂如何實(shí)現(xiàn) Go 超時(shí)控制 里面有講解超時(shí)控制如何使用榆综。
參考
《SRE：Google運(yùn)維解密》
項(xiàng)目地址
https://github.com/zeromicro/go-zero
歡迎使用 go-zero 并 star/fork 支持我們妙痹！
微信交流群
關(guān)注『微服務(wù)實(shí)踐』公眾號(hào)并點(diǎn)擊 交流群 獲取社區(qū)群二維碼。
