背景
先介紹普通的超時配置
普通的超時控制：
A - > B - > C -> D
比如B->C 默認超時時間200ms，但是B->C實際調(diào)用了230ms
此時B知道調(diào)用超時了，會處理異?；蛘甙旬惓７祷亟o上游
這里方式較多，比如socket timeout，網(wǎng)上一堆資料
這里，B知道后續(xù)請求超時，B會處理異常返回給A
但是C不知道，C會接著走自己的邏輯，會繼續(xù)把請求發(fā)送給D。對于D來說，這一次請求完全是浪費的，因為不管D處理結(jié)果成功失敗，上游都已經(jīng)當成失敗了。
如何優(yōu)化這樣的場景呢？
工業(yè)界也會有這種情況，尤其是對于底層，中臺這樣的服務(wù)，有時候請求過來的時候，上游已經(jīng)當成失敗處理了，這個時候中臺還去處理這些請求，浪費資源和效率
設(shè)計方式
這里只是提出簡單的思路，并不給出詳細的實現(xiàn)代碼
上下游調(diào)用的時候設(shè)置一個TTL
每次調(diào)用請求的時候，在請求rpc context里面?zhèn)鬟f一下TTL，記錄剩余多長時間。
那么，
上游調(diào)用下游時，檢查當前的TTL是否<0，是的話就不調(diào)用了，節(jié)省下游資源
下游被上游調(diào)用時，同理，就直接返回錯誤。
思考
1.上面的例子都是簡單的串行化例子，實際上還有ABCD串行化調(diào)用過程中，BC兩步單獨沒有超時，但是整體已經(jīng)超過了A的時間，此時C向D發(fā)出請求時，TTL也是<0
2.業(yè)務(wù)本地的處理邏輯還是會走完的。ABCD請求上面都正常，D本身超時了，D自己的業(yè)務(wù)邏輯也會走完。
3.這種檢測機制可以放在middleware里面處理，通過這種方式，能減少在上游整體超時或者單個上游自身超時的情況下，對下游的請求量。
