Question

我正在了解AWS Lambda，并且担心同步实时请求。 lambda具有“冷启动”的事实，对于处理GET请求来说听起来并不好。

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

Answer 1

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

我遇到的问题：

每个lambda每天很少的请求（不足以使lambda保持温暖）
时间紧迫的应用程序（用户正在通话中，等待文本语音转换为答案）

我如何解决此问题：

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

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

根据需要保暖的lamda数量，这可能是很多“加温”的呼叫。 AWS每月都会提供1.000.000 lambda calls。

Answer 2

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

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

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

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

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

Answer 3

我们已经以合理和可接受的响应时间非常成功地使用了AWS Lambda。（基于REST / JSON的API + AWS Lambda + Dynamo数据库访问）。

我们测量的延迟总是在调用功能上花费的时间最少，而在应用程序逻辑中花费的时间却很多。

以上文章中提到了一些热身技术。

AWS Lambda是否适合实时API Rest？

3 个答案: