调用lambda

by Yan Cui

崔燕

如何使用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请求这一事实使事情变得更加复杂。 例如，

1. read from DynamoDB

   从DynamoDB读取

2. perform business logic on the data
   对数据执行业务逻辑

3. save the update to DynamoDB

   将更新保存到DynamoDB

4. 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,

例如，

1. exe­cute a DynamoDB read inside CommandA

   执行CommandA内部读取的DynamoDB

2. In the getFallback method, exe­cute CommandB which would return a pre­vi­ous­ly cached response if avail­able

   在getFallback方法中，执行CommandB ，它将返回以前缓存的响应(如果有)

3. If there is no cached response, then CommandB would fail and trig­ger its own getFallback method

   如果没有缓存的响应，则CommandB将失败并触发自己的getFallback方法

4. 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 。 大多数被烤成豪猪的模式可以在我们的无服务器应用程序，帮助轻易采取使他们更适应故障。

翻译自: https://www.freecodecamp.org/news/how-to-set-timeouts-dynamically-using-lambda-invocation-context-3e78fa832a5b/

调用lambda