Fargate vs Lambda，什么时候用哪个？
Fargate vs Lambda, when to use which?
我对整个无服务器环境还很陌生，我正在思考何时使用 Fargate 与 Lambda。
我知道 Fargate 是 ECS 的无服务器子集，而 Lambda 也是无服务器的，但由事件驱动。但我希望能够用简单的术语向其他熟悉容器但不太熟悉 AWS 和无服务器的人解释这两种范例。
目前我们有几台物理服务器负责接收文本文件，解析它们，并用结果填充几个数据库表。根据我的理解，我认为这将是一个更适合 Lambda 的用例，因为解析文本文件的过程是由计划触发的，时间不长 运行，并且在不使用时会逐渐下降。
但是，如果我们要移植接收 API 调用的服务器之一，我们可能希望使用 Fargate，因为我们总是需要至少一个图像实例 运行.
就容器而言，用非常笼统的术语来说，如果容器设计用于：
docker run <some_input>
那就是Lambda的工作了。
但是如果容器被设计用来做类似的事情：
docker run --expose 80
那么这是 Fargate 的工作。
这个比喻好吗？
这是一个很好的类比的开始。然而，Lambda 在可用 CPU 和 RAM 方面也有限制，并且每次调用的最长 运行 时间为 15 分钟。因此，任何需要更多资源或需要 运行 超过 15 分钟的东西都更适合 Fargate。
此外，我不确定您为什么说某些东西更适合 Fargate，因为您“总是需要至少一个实例 运行ning”。 Lambda+API 网关非常适合 API 调用。 API 网关始终准备好接收 API 调用，然后它将调用 Lambda 函数来处理它（如果尚未缓存响应）。
请务必注意，使用 Lambda，您无需构建、保护或维护容器。你只需要担心代码。现在如前所述，Lambda 有最大 运行 时间限制和 3GB 内存限制（CPU 按比例增加）。此外，如果它偶尔使用，可能需要预热（按计划调用）以获得额外的性能。
Fargate 管理 docker 个容器，您需要定义、维护和保护这些容器。如果您需要更多地控制代码 运行s 所在环境中可用的内容，您可能会使用容器（或服务器），但这又与管理有关。您还有更多关于 Memory/CPU 大小和 运行 可以花费 运行 的时间长度的选项。
即使对于您提到的 API 服务器，您也可以将 API 网关放在前面并调用 Lambda。
正如 Mark 已经提到的，您可以通过 Lambda + API 网关将您的 lambda 函数公开为 API。
但是 lambda 在函数执行方面有很大的局限性。支持的编程语言、内存消耗和执行时间都有限制（最近从之前的 5 分钟增加到 15 分钟）。这就是 AWS Fargate 可以提供容器世界和无服务器 (FaaS) 世界优势的地方。在这里，您只需担心容器（它的 CPU、内存要求、IAM 策略..），然后通过选择 Fargate 启动类型将其余部分留给 Amazon ECS。 ECS 将选择正确的实例类型，管理您的集群，自动缩放，最佳利用率。
这是正确的类比，但它并不是能够解释这两种范式的详尽清单。
总的来说，Lambda更适合serverless应用。它的本质是功能即服务（FaaS）。它只是完成简单的任务，仅此而已。不要期望太多。
它应该被视为无服务器模块的第一个选项。但它有更多的局限和限制。从功能和非功能需求、周围的基础设施和许多其他因素阐述的模块架构。
要做出最低限度的决定，您必须查看限制列表，例如：
- 便携性
- 环境控制
- 触发器类型
- 响应时间
- 响应大小
- 处理时间
- 内存使用
这些是主要因素。但该列表并未涵盖这两种无服务器技术之间需要考虑的所有因素和限制。
想要了解更多我推荐这篇文章https://greenm.io/aws-lambda-or-aws-fargate/
我对整个无服务器环境还很陌生，我正在思考何时使用 Fargate 与 Lambda。
我知道 Fargate 是 ECS 的无服务器子集，而 Lambda 也是无服务器的，但由事件驱动。但我希望能够用简单的术语向其他熟悉容器但不太熟悉 AWS 和无服务器的人解释这两种范例。
目前我们有几台物理服务器负责接收文本文件，解析它们，并用结果填充几个数据库表。根据我的理解，我认为这将是一个更适合 Lambda 的用例，因为解析文本文件的过程是由计划触发的，时间不长 运行，并且在不使用时会逐渐下降。
但是，如果我们要移植接收 API 调用的服务器之一，我们可能希望使用 Fargate，因为我们总是需要至少一个图像实例 运行.
就容器而言，用非常笼统的术语来说，如果容器设计用于：
docker run <some_input>
那就是Lambda的工作了。
但是如果容器被设计用来做类似的事情：
docker run --expose 80
那么这是 Fargate 的工作。
这个比喻好吗？
这是一个很好的类比的开始。然而，Lambda 在可用 CPU 和 RAM 方面也有限制，并且每次调用的最长 运行 时间为 15 分钟。因此，任何需要更多资源或需要 运行 超过 15 分钟的东西都更适合 Fargate。
此外，我不确定您为什么说某些东西更适合 Fargate，因为您“总是需要至少一个实例 运行ning”。 Lambda+API 网关非常适合 API 调用。 API 网关始终准备好接收 API 调用，然后它将调用 Lambda 函数来处理它（如果尚未缓存响应）。
请务必注意，使用 Lambda，您无需构建、保护或维护容器。你只需要担心代码。现在如前所述，Lambda 有最大 运行 时间限制和 3GB 内存限制（CPU 按比例增加）。此外，如果它偶尔使用，可能需要预热（按计划调用）以获得额外的性能。
Fargate 管理 docker 个容器，您需要定义、维护和保护这些容器。如果您需要更多地控制代码 运行s 所在环境中可用的内容，您可能会使用容器（或服务器），但这又与管理有关。您还有更多关于 Memory/CPU 大小和 运行 可以花费 运行 的时间长度的选项。
即使对于您提到的 API 服务器，您也可以将 API 网关放在前面并调用 Lambda。
正如 Mark 已经提到的，您可以通过 Lambda + API 网关将您的 lambda 函数公开为 API。 但是 lambda 在函数执行方面有很大的局限性。支持的编程语言、内存消耗和执行时间都有限制（最近从之前的 5 分钟增加到 15 分钟）。这就是 AWS Fargate 可以提供容器世界和无服务器 (FaaS) 世界优势的地方。在这里，您只需担心容器（它的 CPU、内存要求、IAM 策略..），然后通过选择 Fargate 启动类型将其余部分留给 Amazon ECS。 ECS 将选择正确的实例类型，管理您的集群，自动缩放，最佳利用率。
这是正确的类比，但它并不是能够解释这两种范式的详尽清单。
总的来说，Lambda更适合serverless应用。它的本质是功能即服务（FaaS）。它只是完成简单的任务，仅此而已。不要期望太多。
它应该被视为无服务器模块的第一个选项。但它有更多的局限和限制。从功能和非功能需求、周围的基础设施和许多其他因素阐述的模块架构。
要做出最低限度的决定，您必须查看限制列表，例如：
- 便携性
- 环境控制
- 触发器类型
- 响应时间
- 响应大小
- 处理时间
- 内存使用
这些是主要因素。但该列表并未涵盖这两种无服务器技术之间需要考虑的所有因素和限制。
想要了解更多我推荐这篇文章https://greenm.io/aws-lambda-or-aws-fargate/