Fargate和Lambda，在什么情况下使用哪个？

Question

我对Serverless领域还比较新，正在努力理解何时使用Fargate和Lambda。

我知道Fargate是ECS的无服务器子集，而Lambda也是无服务器的，但由事件驱动。但我想能够用简单的术语向熟悉容器但不熟悉AWS和无服务器的其他人解释这两种范例。

当前我们有几台物理服务器负责接收文本文件，将它们解析并用结果填充几个数据库表。根据我的理解，我认为这将更适合使用Lambda，因为解析文本文件的过程是由时间表触发的，不需要长时间运行，并在不使用时缩减。

然而，如果我们要移植接收API调用的服务器之一，我们可能会希望使用Fargate，因为我们始终需要至少一个图像实例正在运行。

以容器为基础，非常通俗易懂的说，如果容器的设计目的是：

docker run <some_input>

那么这就是 Lambda 的工作了。

但如果容器的设计目的是执行一些操作，例如：

docker run --expose 80

那么这就是Fargate的工作了。

这个类比合适吗？

- janDro

Answer 1

这是一个好比喻的开端。然而Lambda在可用CPU和RAM方面存在限制，并且每次调用最多运行15分钟。因此，任何需要更多资源或需要运行超过15分钟的内容都更适合于Fargate。

此外，我不确定为什么你说某些内容“总是需要至少一台实例在运行”，就更适合Fargate。Lambda+API网关非常适合API调用。API网关准备好接收API调用并将调用Lambda函数进行处理（如果响应尚未缓存）。

- Mark B

---

谢谢，马克。我之前也误以为Lambda是为容器而设计的，事实并非如此。还有很多需要学习的地方！ - janDro

截至2018年10月，Lambda支持每次调用最长达15分钟的函数。 - Matt

@janDro，它们在后台中运行于 Docker 中，但我们无法访问它们，因为它们是“语言 Docker”。这就是 Fargate 的用武之地。 - Mojimi

Answer 2

重要的是要注意，使用Lambda时无需构建、保护或维护容器。你只需要担心代码。如前所述，Lambda具有最大运行时间限制和3GB内存限制（CPU按比例增加）。此外，如果它被零星使用，可能需要预热（按计划调用）以获得额外的性能提升。

Fargate管理Docker容器，您需要定义、维护和保护这些容器。如果您需要更多地控制代码运行的环境中可用的内容，可能可以使用容器（或服务器），但这又涉及到管理问题。您还可以选择更多的内存/CPU大小选项以及运行的持续时间。

即使对于像您提到的API服务器，您也可以在其前面放置API网关并调用Lambda。

- Pedro Graber

---

值得一提的是，即使有lambda的限制，您仍然可以安排一个lambda来调用其他几个lambda，比如下载和调整一些图像，这样您就可以轻松地绕过限制并拥有相当快的流程。 - Mojimi

@Mojimi 调用一个调用另一个调用的 lambda，哦耶，我想看看这在一个有多个开发人员的大型项目中能否正常工作。不可能。 - Daniel Viglione

Answer 3

正如马克已经提到的那样，您可以使用Lambda + API Gateway将Lambda函数公开为API。 但是，Lambda在功能执行方面存在重大限制。支持的编程语言、内存消耗和执行时间都有限制（最近从之前的5分钟增加到了15分钟）。这就是AWS Fargate可以帮助解决问题的地方，它同时提供容器世界和无服务器（FaaS）世界的好处。在这里，您只需要关心容器（其CPU、内存需求、IAM策略等），并通过选择Fargate启动类型将其余部分留给Amazon ECS。ECS将选择正确的实例类型，管理您的集群，进行自动缩放和最佳利用。

- vkumars

Answer 4

这是正确的比喻，但它不是一个详尽的列表，无法解释这两种范例。通常，Lambda更适合无服务器应用程序。它的本质是函数即服务（FaaS）。它只执行简单的任务，仅此而已。不要期望太多。

它应该被视为无服务器模块的首选选项。但它有更多的限制和约束。模块架构是从功能和非功能要求、周围基础设施和许多其他因素中阐述的。

为了做出决定，你必须至少查看限制列表，例如：

1. 可移植性
2. 环境控制
3. 触发器类型
4. 响应时间
5. 响应大小
6. 处理时间
7. 内存使用量

这些是主要因素。但列表并没有涵盖所有需要考虑的因素和限制这两种无服务器技术之间的差异。

想要了解更多，请参考这篇文章：https://greenm.io/aws-lambda-or-aws-fargate/

- okiri