AWS Lambda 是否适用于实时 API Rest？答案

【问题标题】：Is AWS Lambda good for real-time API Rest?AWS Lambda 是否适用于实时 API Rest？
【发布时间】：2021-09-01 04:12:20
【问题描述】：

我正在学习 AWS Lambda，我担心同步的实时请求。事实上 lambda 有一个“冷启动”，这对于处理 GET 请求来说并不好。

假设用户正在使用应用程序并执行 GET HTTP 请求以获取产品或产品列表，如果 lambda 处于睡眠状态，则需要 10 秒才能响应，我认为这是不可接受的响应时间。将 AWS Lambda 用于经典（同步响应）API Rest 是好是坏？

【问题讨论】：

“响应时间为 10 秒” – 你从哪里得到那个的想法？唤醒大约需要 200 毫秒，而不是 10 秒。
@deceze 你是对的，也许不是 10 秒，但在某些文章中它说 1.5 秒，就像 medium.freecodecamp.org/… 一样。问题是，这类操作是好是坏？
“实时”、“慢”是主观术语。对于不同类型的应用程序，Lambda 的开销可以接受也可以不接受。所以我认为你的问题是无效的。最重要的是，互联网本身并不是“实时的”，网络延迟一般是不可预测的。
嗯，通常 lambda 执行模型对于无状态 HTTP 请求来说是完美的。您需要决定它是否适合您的用例。正如那篇文章所述，在某些配置中可能会有额外的开销产生延迟。是否使用这些特定配置由您决定。是否可以忍受几秒钟的冷启动由您决定。用户遇到冷启动的频率，只有您自己知道（访问者越多，他们就越少）。
Lambda 冷启动。启动可能需要几秒钟。如果您已将 lambda 配置为在 VPC 中，我最多可能需要 10 秒才能启动（创建网络接口需要一些时间）。一种解决方案是通过使用 cloudwatch 创建计划任务来保持 lambda 温暖，该任务会触发具有空有效负载的 lambda。无论 Lambda 需要几秒钟才能启动，它在任何情况下都不能用于实时。最好使用成熟的 Websocket 服务器或 SNS，甚至...... AWS IoT。

标签： amazon-web-services aws-lambda serverless

【解决方案1】：

像大多数事情一样，我认为您应该在决定之前进行衡量。许多 AWS 客户非常成功地使用 Lambda 作为其 web 应用程序的后端。

关于 Lambda 延迟有很多讨论，例如：

2019 年 12 月，AWS Lambda 引入了预置并发，它改进了一些东西。见：

您应该测量代表您的应用及其使用的环境的延迟。

一些与请求延迟相关的重要因素：

冷启动 => 更高的延迟
请求模式是冷启动的重要因素
如果您需要在 VPC 中部署（附加 ENI => 更高的冷启动延迟）
使用 CloudFront --> API Gateway --> Lambda（更多层 => 更高延迟）
编程语言的选择（Java 的冷启动延迟可能最高，Go 最低）
Lambda 环境的大小（更多 RAM => 更多 CPU => 更快）
Lambda 帐户和并发限制
预热策略

2019-12 更新：见 Predictable start-up times with Provisioned Concurrency。

2021-08 更新：请参阅 Increasing performance of Java AWS Lambda functions using tiered compilation。

【讨论】：

【解决方案2】：

作为 AWS Lambda + API Gateway 用户（使用无服务器框架），我也必须处理这个问题。

我遇到的问题：

每个 lambda 每天的请求数很少（不足以让 lambda 保持温暖）
时间紧迫的应用程序（用户正在打电话，等待文字转语音应答）

我是如何解决这个问题的：

我们的想法是找到一种方法来经常调用关键 lambda，以免它们变冷。
如果您使用无服务器框架，则可以使用 serverless-plugin-warmup 插件来实现这一点。
如果没有，您可以通过创建一个工作程序来复制它的行为，该工作程序将每隔几分钟调用一次 lambda 以保持它们的温暖。为此，请创建一个 lambda，该 lambda 将调用您的其他 lambda，并安排 CloudWatch 每 5 分钟左右触发一次。确保使用自定义 event.source 调用您的 to-keep-warm lambdas，这样您就可以在不运行任何实际业务代码的情况下提前退出它们，只需将以下代码放在函数的开头：

if (event.source === 'just-keeping-warm) {
  console.log('WarmUP - Lambda is warm!');
  return callback(null, 'Lambda is warm!');
}

根据您必须保持温暖的 lamda 数量，这可能是很多“温暖”的电话。不过，AWS 每个月都会提供1.000.000 free lambda calls。

【讨论】：

换句话说，你使用了 hacks，做一些事情来让 lambda 处理不是设计用来处理的东西。
@Donato 它只是让函数保持温暖。它工作得很好，这种做法在无服务器社区中很普遍。
这可能是一个 hack，但说 lambdas 不是为处理多个请求而设计的肯定是不公平的。
我不明白你为什么要让你的 lambda 保持温暖。如果您需要always on，请使用 IIS、nginx、Apache 服务器来处理 API 调用。
@JobaDiniz AWS 的免费套餐是每月 1.000.000 次调用。然后还是很便宜。

【解决方案3】：

我们非常成功地使用了 AWS Lambda，响应时间合理且可接受。（基于 REST/JSON 的 API + AWS Lambda + Dynamo DB 访问）。

我们测量的延迟总是花在调用函数上的时间最少，花在应用逻辑上的时间最多。

上面的帖子中提到了一些热身技术。

【讨论】：