是否有可能（或有效）运行 使用 AWS Lambda 的完整后端（相对于 Elastic Beanstalk）
Is it possible (or efficient) to run a complete backend with AWS Lambda (vs say, Elastic Beanstalk)
我对服务器世界还比较陌生，所以请原谅我，如果其中有一些是基本的（文本的第一部分将是我解释我的逻辑以确保它没有缺陷）。我所有的问题都会以粗体显示，以使您的帮助更容易:)。
我一直在研究和自学一些 AWS 技术，我注意到在他们的 Mobile Hub 中，如果您需要云逻辑，他们只允许 "automatic" 设置 Lambda 函数。在阅读和研究之后，我发现了一些指向 "serverless" 架构（Lambda 的引入支持）的资源。过去，据我了解，引入 Elastic Beanstalk 是为了帮助简化服务器管理（尤其是针对移动设备）。
对于移动开发，有 2 个选项（显然更多，但为了简单起见，我们同意）：
- 设置一个至少有 1 个实例 运行ning 24/7 并且每个 url
有多个端点的 Elastic Beanstalk
- 使用 API 网关，我们可以轻松地将 url 路由到特定的 Lambda 函数。有了这个，我们可以处理任何请求（就像设置 Elastic Beanstalk 应用程序一样）。
所有这些让我相信，一个完整的 Lambda 后端完全有可能并且很容易创建，而成本只是拥有服务器 运行ning 24/7 的一小部分。对吗？
现在，假设以上是正确的，我们需要确定使用 Lambda 是否真的优于 Elastic Beanstalk。
对于简单的服务器，我们可以设置一些 Lambda 函数并收工（而且它可能比使用 Elastic Beanstalk 更简单、更便宜（至少对于小型项目而言））。
然而，对于具有更多 url 和数据库连接的更复杂的服务器，事情会变得更有趣。
这些是我在上述情况下使用 Lambda 时遇到的问题
- 每个 url 都有自己的 API 网关和自己的 Lambda 函数。如果在多个函数中使用了任何代码或模块，我们必须将其复制并粘贴到每个函数中。
- 管理多个 Lambda 函数（和 API 网关）比管理单个 project/repo/whatever-you-wanna-call-your-code-base.
简单得多。
- 每个需要数据库连接的函数都必须在函数内进行连接（相对于在 Node.js 应用程序中具有持续连接）。
避免前两个问题的唯一方法（我能想到）是创建一个强大的函数作为调度（主函数从 API 网关获取一个参数并确定要发送哪个文件运行 在 Lambda 函数中）。
我是否缺少任何要点来确定在 Elastic Beanstalk 上使用 Lambda 是否值得？
听起来你已经想通了。您是正确的，使用 Lambda 而不是拥有服务器 运行ning 24/7 可以节省大量成本。 This article 提出索赔：
And it's saving some of Amazon's customers big bucks, with at least
one happy Lambda customer saving 80% off their cloud bills.
您可能想查看 Serverless Framework 来解决一些痛点。
我认为随着亚马逊向 Lambda 添加更多功能并为其构建更多第三方工具，许多痛点会及时消失。我不断地发现 Lambda 的新用途，但我也不断地发现一开始似乎很适合但实际上不适用于 Lambda 的用途，至少现在还不行。例如，我确实需要一些方法来限制可以同时 运行ning 的 Lambda 函数实例的数量，以防止可用数据库连接达到最大值或达到第三方 API 的使用限制。我也真的需要 Lambda 函数到我的 VPC 中 运行，但这应该很快就会出现。
问题实际上是 FAAS 与 PAAS。 Lambda/Serverless 架构可以被认为是功能即服务，而 Beanstalk 属于平台即服务。
FAAS 和 PAAS 之间存在很多混淆。许多人说 FAAS 也是一种 PAAS。我想指出 FAAS 和 PAAS 之间的区别。
比如说，我有一个 CRUD 应用程序，它具有 创建、读取、更新和删除 操作。通常，Web 应用程序在 Read 操作上会收到更多流量。
+---------------------------------------------+--------------------------------------------------------+
| FAAS | PAAS |
+---------------------------------------------+--------------------------------------------------------+
| In case of traffic, it scales that specific | But it scales the whole application, |
| function handling the read operation. | a separate auto-scaled instance in case of bean stalk. |
+---------------------------------------------+--------------------------------------------------------+
| Pay one and only when your function | Have to pay for atleast a single instance, |
| is invoked. | even though there is no traffic. |
+---------------------------------------------+--------------------------------------------------------+
在我看来，这两点将 FAAS（一种所谓的 "serverless" 架构）与 PAAS 区分开来。
正如其他人已经指出的那样，运行宁 Lambda 与 Elastic Beanstalk 或您自己管理的 EC2 实例相比有一些好处。
费用
虽然 AWS 支持 Elastic Beanstalk 和 EC2 的自动缩放。一个人总是应该 运行 至少两个故障转移行为实例。 运行 两个 "nano" 实例作为故障转移的最低成本，每个实例的成本（没有预留实例折扣）：VM 0.0059 美元 * 24 * 30.5 = 4.31 美元，0.05 美元 * 8 GB = 0.40 美元。所以一个实例是 4.81 美元，两个实例是 9.62 美元。但是，要使 AutoScaling 正常工作，您需要一个负载均衡器，让您至少损失 0.0225 美元 * 24 * 30.5 = 16.47 美元（忽略 LCU 费用）。 Load-Balancer 可以被多个服务共享。对于这个计算，我只是人为地将它分成 10，得出的结论是使用 Eleastic Beanstalk 或 EC2 的一个微服务将花费你 9.62 美元 + 1.65 美元 = 11.27 美元。
那与 Lambda 相比如何呢？使用 Lambda，您需要为每次调用和每 GB 秒付费。我忽略了通话费用，因为它是每 100 万个请求 0.20 美元。 100 万个请求是一个月内每秒 0.4 个请求。如果您有更高的负载，您还必须支付 Load Balancer LCU 成本。
Lambda 的定价为每 GB 秒 0.00001667 美元。
Elastic Beanstalk 和 EC2 都将消耗部分 nanos 512 MB 内存用于操作系统和容器。我只是假设 256 MB 实际上是可用的。如果有两个实例，这将是 2 * 256 MB/1024MB * 60 * 60 * 24 * 30.5 = 1317600 GB 秒。这个 GB 秒数将花费您 1317600 * 0.00001667 美元 = 21.96 美元。虽然这听起来更昂贵，但请记住您的流量可能不会均匀分布，因此您可能需要更多实例，从而增加成本。使用 Lambda，您只需支付实际使用的费用。
缩放
Lambda 按需扩展，如前所述，您只需支付实际需要的费用，而不是未充分利用的基线。
不可预测的表现
Lambda 的一个陷阱是不可预测的性能。虽然容器将被重用，但它们需要对每个新实例进行一些预热。第一次请求通常会很慢，尤其是在使用 Java 时。 Node.js 应该在启动期间更轻，但在执行期间更慢。例如，当创建一个新的 128 MB 低内存 Java 实例并且您的 Lambda 中有一些库时，第一次调用可能需要 30 秒或更长时间。请求之间的实例数为 freezed。如果实例有一段时间未使用，则需要更长的时间才能再次唤醒。增加内存可以减少预热和唤醒时间。然而，一个主要问题可能是对外部数据源的访问。由于实例在请求之间被冻结，因此不支持适当的连接池。如果你无论如何都做连接池，你最终可能会得到过时的连接。根据数据库和驱动程序打开和关闭连接可能会非常昂贵。
其他限制
如上所述，不直接支持连接池，这通常会成为数据库访问或访问其他系统的问题。
如果您使用框架来加速开发，它们可能不适合在 Lambda 中使用。
Mark B 提到的限制现已消失。如今，Lambda 可以 运行 在一个 VPC 中。尽管我不知道限制并发实例数量的官方方法，但如果您使用 VPC，则可以限制可用 IP 的子网，并且每个 Lambda 都需要一个 IP，因此您可以间接限制 Lambda 实例的数量。
好的用例
如果不太关心一致的性能，Lambda 是便宜且可扩展的。非常适合小批量加工。
查看 DynamoDB DAX 客户端以了解您的 lambda 函数。如果您关心连接数据库的速度，它可以将延迟从毫秒降低到微秒。
我对服务器世界还比较陌生，所以请原谅我，如果其中有一些是基本的（文本的第一部分将是我解释我的逻辑以确保它没有缺陷）。我所有的问题都会以粗体显示，以使您的帮助更容易:)。
我一直在研究和自学一些 AWS 技术，我注意到在他们的 Mobile Hub 中，如果您需要云逻辑，他们只允许 "automatic" 设置 Lambda 函数。在阅读和研究之后，我发现了一些指向 "serverless" 架构（Lambda 的引入支持）的资源。过去，据我了解，引入 Elastic Beanstalk 是为了帮助简化服务器管理（尤其是针对移动设备）。
对于移动开发，有 2 个选项（显然更多，但为了简单起见，我们同意）：
- 设置一个至少有 1 个实例 运行ning 24/7 并且每个 url 有多个端点的 Elastic Beanstalk
- 使用 API 网关，我们可以轻松地将 url 路由到特定的 Lambda 函数。有了这个，我们可以处理任何请求（就像设置 Elastic Beanstalk 应用程序一样）。
所有这些让我相信，一个完整的 Lambda 后端完全有可能并且很容易创建，而成本只是拥有服务器 运行ning 24/7 的一小部分。对吗？
现在，假设以上是正确的，我们需要确定使用 Lambda 是否真的优于 Elastic Beanstalk。
对于简单的服务器，我们可以设置一些 Lambda 函数并收工（而且它可能比使用 Elastic Beanstalk 更简单、更便宜（至少对于小型项目而言））。
然而，对于具有更多 url 和数据库连接的更复杂的服务器，事情会变得更有趣。
这些是我在上述情况下使用 Lambda 时遇到的问题
- 每个 url 都有自己的 API 网关和自己的 Lambda 函数。如果在多个函数中使用了任何代码或模块，我们必须将其复制并粘贴到每个函数中。
- 管理多个 Lambda 函数（和 API 网关）比管理单个 project/repo/whatever-you-wanna-call-your-code-base. 简单得多。
- 每个需要数据库连接的函数都必须在函数内进行连接（相对于在 Node.js 应用程序中具有持续连接）。
避免前两个问题的唯一方法（我能想到）是创建一个强大的函数作为调度（主函数从 API 网关获取一个参数并确定要发送哪个文件运行 在 Lambda 函数中）。
我是否缺少任何要点来确定在 Elastic Beanstalk 上使用 Lambda 是否值得？
听起来你已经想通了。您是正确的，使用 Lambda 而不是拥有服务器 运行ning 24/7 可以节省大量成本。 This article 提出索赔：
And it's saving some of Amazon's customers big bucks, with at least one happy Lambda customer saving 80% off their cloud bills.
您可能想查看 Serverless Framework 来解决一些痛点。
我认为随着亚马逊向 Lambda 添加更多功能并为其构建更多第三方工具，许多痛点会及时消失。我不断地发现 Lambda 的新用途，但我也不断地发现一开始似乎很适合但实际上不适用于 Lambda 的用途，至少现在还不行。例如，我确实需要一些方法来限制可以同时 运行ning 的 Lambda 函数实例的数量，以防止可用数据库连接达到最大值或达到第三方 API 的使用限制。我也真的需要 Lambda 函数到我的 VPC 中 运行，但这应该很快就会出现。
问题实际上是 FAAS 与 PAAS。 Lambda/Serverless 架构可以被认为是功能即服务，而 Beanstalk 属于平台即服务。
FAAS 和 PAAS 之间存在很多混淆。许多人说 FAAS 也是一种 PAAS。我想指出 FAAS 和 PAAS 之间的区别。
比如说，我有一个 CRUD 应用程序，它具有 创建、读取、更新和删除 操作。通常，Web 应用程序在 Read 操作上会收到更多流量。
+---------------------------------------------+--------------------------------------------------------+
| FAAS | PAAS |
+---------------------------------------------+--------------------------------------------------------+
| In case of traffic, it scales that specific | But it scales the whole application, |
| function handling the read operation. | a separate auto-scaled instance in case of bean stalk. |
+---------------------------------------------+--------------------------------------------------------+
| Pay one and only when your function | Have to pay for atleast a single instance, |
| is invoked. | even though there is no traffic. |
+---------------------------------------------+--------------------------------------------------------+
在我看来，这两点将 FAAS（一种所谓的 "serverless" 架构）与 PAAS 区分开来。
正如其他人已经指出的那样，运行宁 Lambda 与 Elastic Beanstalk 或您自己管理的 EC2 实例相比有一些好处。
费用
虽然 AWS 支持 Elastic Beanstalk 和 EC2 的自动缩放。一个人总是应该 运行 至少两个故障转移行为实例。 运行 两个 "nano" 实例作为故障转移的最低成本，每个实例的成本（没有预留实例折扣）：VM 0.0059 美元 * 24 * 30.5 = 4.31 美元，0.05 美元 * 8 GB = 0.40 美元。所以一个实例是 4.81 美元，两个实例是 9.62 美元。但是，要使 AutoScaling 正常工作，您需要一个负载均衡器，让您至少损失 0.0225 美元 * 24 * 30.5 = 16.47 美元（忽略 LCU 费用）。 Load-Balancer 可以被多个服务共享。对于这个计算，我只是人为地将它分成 10，得出的结论是使用 Eleastic Beanstalk 或 EC2 的一个微服务将花费你 9.62 美元 + 1.65 美元 = 11.27 美元。
那与 Lambda 相比如何呢？使用 Lambda，您需要为每次调用和每 GB 秒付费。我忽略了通话费用，因为它是每 100 万个请求 0.20 美元。 100 万个请求是一个月内每秒 0.4 个请求。如果您有更高的负载，您还必须支付 Load Balancer LCU 成本。 Lambda 的定价为每 GB 秒 0.00001667 美元。 Elastic Beanstalk 和 EC2 都将消耗部分 nanos 512 MB 内存用于操作系统和容器。我只是假设 256 MB 实际上是可用的。如果有两个实例，这将是 2 * 256 MB/1024MB * 60 * 60 * 24 * 30.5 = 1317600 GB 秒。这个 GB 秒数将花费您 1317600 * 0.00001667 美元 = 21.96 美元。虽然这听起来更昂贵，但请记住您的流量可能不会均匀分布，因此您可能需要更多实例，从而增加成本。使用 Lambda，您只需支付实际使用的费用。
缩放
Lambda 按需扩展，如前所述，您只需支付实际需要的费用，而不是未充分利用的基线。
不可预测的表现
Lambda 的一个陷阱是不可预测的性能。虽然容器将被重用，但它们需要对每个新实例进行一些预热。第一次请求通常会很慢，尤其是在使用 Java 时。 Node.js 应该在启动期间更轻，但在执行期间更慢。例如，当创建一个新的 128 MB 低内存 Java 实例并且您的 Lambda 中有一些库时，第一次调用可能需要 30 秒或更长时间。请求之间的实例数为 freezed。如果实例有一段时间未使用，则需要更长的时间才能再次唤醒。增加内存可以减少预热和唤醒时间。然而，一个主要问题可能是对外部数据源的访问。由于实例在请求之间被冻结，因此不支持适当的连接池。如果你无论如何都做连接池，你最终可能会得到过时的连接。根据数据库和驱动程序打开和关闭连接可能会非常昂贵。
其他限制
如上所述，不直接支持连接池，这通常会成为数据库访问或访问其他系统的问题。 如果您使用框架来加速开发，它们可能不适合在 Lambda 中使用。
Mark B 提到的限制现已消失。如今，Lambda 可以 运行 在一个 VPC 中。尽管我不知道限制并发实例数量的官方方法，但如果您使用 VPC，则可以限制可用 IP 的子网，并且每个 Lambda 都需要一个 IP，因此您可以间接限制 Lambda 实例的数量。
好的用例
如果不太关心一致的性能，Lambda 是便宜且可扩展的。非常适合小批量加工。
查看 DynamoDB DAX 客户端以了解您的 lambda 函数。如果您关心连接数据库的速度，它可以将延迟从毫秒降低到微秒。