如何使用Lambda調用上下文動態設置超時 (How to set timeouts dynamically using Lambda invocation context)

With API Gate-way and Lamb-da, you’re forced to use short time-outs on the serv-er-side:

使用API?? Gateway和Lambda，您不得不在服務器端使用較短的超時：

API Gate-way has a 29s max time-out on all inte-gra-tion points
API網關在所有集成點上的最大超時為29秒
The Server-less frame-work uses a default of 6s for AWS Lamb-da func-tions
無服務器框架對AWS Lambda函數使用默認值6s

How-ev-er, you have lim-it-ed influ-ence over a Lamb-da function’s cold start time. And you have no con-trol over how much over-head API Gate-way adds. So the actu-al laten-cy you’d expe-ri-ence from a call-ing func-tion is far less pre-dictable than you might think.

但是，你要通過lambda函數的冷啟動時間的影響有限。而且，您無法控制API網關添加多少開銷。因此，您從調用函數遇到的實際延遲遠比您想象的要難預測。

We don’t want a slow HTTP respons-e to cause the call-ing func-tion to time-out. This has a negative impact on the user experience. Instead, we should stop wait-ing for a response before the call-ing func-tion times out.

我們不希望緩慢的HTTP響應導致調用函數超時。這對用戶體驗有負面影響。相反，我們應該在調用函數超時之前停止等待響應。

“The goal of the time-out strat-e-gy is to give HTTP requests the best chance to suc-ceed, pro-vid-ed that doing so does not cause the call-ing func-tion itself to err.”
“超時策略的目標是為HTTP請求提供成功的最佳機會，前提是這樣做不會導致調用函數本身出錯。”

- Me

- 我

Most of the time, I see folks use fixed time-out val-ues — but it’s often tricky to decide:

在大多數情況下，我看到人們使用固定的超時值-但要決定通常很棘手：

Too short, and you won’t give the request the best chance to suc-ceed. For example, there’s 5s left in the invo-ca-tion, but the time-out is set to 3s.
太短了，您將不會給請求獲得成功的最佳機會。 例如，調用中還剩下5s，但是超時設置為3s。
Too long, and you run the risk of let-ting the request time-out the call-ing func-tion. For example, there’s 5s left in the invo-ca-tion but the time-out is set to 6s.
太長了，您冒著使請求超時的調用函數的風險。例如，調用中還剩下5s，但是超時設置為6s。

Things are fur-ther com-pli-cat-ed by the fact that we often per-form more than one HTTP request dur-ing a func-tion invo-ca-tion. For example,

在函數調用期間我們經常執行多個HTTP請求這一事實使事情變得更加復雜。例如，

read from DynamoDB
從DynamoDB讀取
perform business logic on the data
對數據執行業務邏輯
save the update to DynamoDB
將更新保存到DynamoDB
publish an event to Kinesis
向Kinesis發布事件

Let’s look at two com-mon approach-es for pick-ing time-out val-ues, and where they fall short.

讓我們看一下兩種選擇超時值的常見方法，以及它們的不足之處。

Instead of following these approaches, I propose we should set the request time-out based on the amount of invo-ca-tion time left. We should also reserve some time to per-form recovery steps in the event of failures.

我建議不要基于這些方法， 而應根據剩余的調用時間來設置請求超時 。如果發生故障，我們還應該保留一些時間來執行恢復步驟 。

You can find out how much time is left in the cur-rent invo-ca-tion through the context object.

您可以通過context對象找出當前調用中還剩下多少時間。

For exam-ple, if a function’s timeout is 6s, and we’re 1s into the invocation. If we reserve 500ms for recov-ery, then that leaves us with 4.5s to wait for a HTTP response.

例如，如果一個函數的timeout為6s，而調用的timeout為1s。如果我們保留500毫秒用于恢復，那么剩下4.5秒鐘的時間來等待HTTP響應。

With this approach, we get the best of both worlds:

通過這種方法，我們可以兩全其美：

Allow requests the best chance to suc-ceed based on the actu-al amount of invo-ca-tion time we have left
允許請求根據我們剩下的實際調用時間獲得成功的最佳機會

Pre-vent slow respons-es from tim-ing out the func-tion, which gives us a window of oppor-tu-ni-ty to per-form recov-ery actions.
防止響應緩慢導致功能超時，這為我們提供了執行恢復操作的機會。

But what are you going to do after you time out these requests? Aren’t you still going to have to respond with a HTTP error, since you couldn’t fin-ish what-ev-er oper-a-tions you need-ed to per-form?

但是，這些請求超時后您將要做什么？由于您無法完成所需執行的任何操作，您是否仍將不得不以HTTP錯誤進行響應？

At the min-i-mum, the recov-ery actions should include:

至少，恢復操作應包括：

Log the timeout incident with as much context as possible. For example, request target, timeout value, correlation IDs, and the request object.
使用盡可能多的上下文記錄超時事件。例如，請求目標，超時值，相關性ID和請求對象。
Track cus-tom met-rics for serviceX.timedout so it can be mon-i-tored and the team can be alert-ed if the sit-u-a-tion esca-lates
跟蹤serviceX.timedout自定義指標，以便在情況升級時可以對其進行監視并向團隊發出警報
Return an appli-ca-tion error code and the original request ID in the response body. The client app can then dis-play a user-friend-ly mes-sage like “Oops, looks like this fea-ture is cur-rent-ly unavail-able, please try again lat-er. If this is urgent, please con-tact us at xxx@domain.com and quote the request ID f19a7dca. Thank you for your coop-er-a-tion :-)”
在響應正文中返回應用程序錯誤代碼和原始請求ID。然后，客戶端應用程序可以顯示一條用戶友好的消息，例如“Oops, looks like this feature is currently unavailable, please try again later. If this is urgent, please contact us at xxx@domain.com and quote the request ID f19a7dca. Thank you for your cooperation :-)” “Oops, looks like this feature is currently unavailable, please try again later. If this is urgent, please contact us at xxx@domain.com and quote the request ID f19a7dca. Thank you for your cooperation :-)”

{   "errorCode": 10021,   "requestId": "f19a7dca",   "message": "service X timed out" }

In some cas-es, you can also recov-er even more grace-ful-ly using fall-backs.

在某些 情況下，您還可以使用后備功能更優雅地恢復。

Netflix’s Hys-trix library sup-ports sev-er-al flavors of fall-backs via the Com-mand pat-tern it employs heav-i-ly. I recommend reading its wiki page, as there is tons of use-ful infor-ma-tion and ideas there.

Netflix的猬庫支持通過它使用大量的Command模式回退的幾種口味。我建議閱讀其Wiki頁面，因為那里有大量有用的信息和想法。

Every Hystrix com-mand lets you spec-i-fy a fall-back action.

每個Hystrix命令都可以讓您指定一個后備操作。

You can also chain the fall-back togeth-er by chain-ing com-mands via their respec-tive getFallback meth-ods.

您還可以通過各自的getFallback方法將命令鏈接在一起，從而將后備鏈接鏈接在一起。

For exam-ple,

例如，

exe-cute a DynamoDB read inside CommandA
執行CommandA內部讀取的DynamoDB
In the getFallback method, exe-cute CommandB which would return a pre-vi-ous-ly cached response if avail-able
在getFallback方法中，執行CommandB ，它將返回以前緩存的響應(如果有)
If there is no cached response, then CommandB would fail and trig-ger its own getFallback method
如果沒有緩存的響應，則CommandB將失敗并觸發自己的getFallback方法
Exe-cute CommandC, which returns a stubbed response
執行CommandC ，它返回存根響應

You should check out Hys-trix if you haven’t already. Most of the pat-terns that are baked into Hys-trix can be eas-i-ly adopt-ed in our server-less appli-ca-tions to help make them more resilient to fail-ures.

如果還沒有，請檢查Hystrix 。大多數被烤成豪豬的模式可以在我們的無服務器應用程序，幫助輕易采取使他們更適應故障。