amazon-web-services - 是否有可能(或有效)使用 AWS Lambda 运行完整的后端(相对于 Elastic Beanstalk)

Question

我对服务器世界比较陌生，所以如果其中一些是基本的，请原谅我(第一段文字将是我解释我的逻辑以确保没有缺陷)。我所有的问题都将加粗，以使您的帮助更容易:)。

我一直在研究和自学一些 AWS 技术，我在他们的 Mobile Hub 中注意到，如果你想要云逻辑，他们只允许“自动”设置 Lambda 函数。在阅读和研究之后，我发现了一些指向“无服务器”架构(Lambda 的引入支持)的资源。过去，据我了解，引入 Elastic Beanstalk 是为了帮助显着简化服务器管理(尤其是移动设备)。

对于移动开发，有 2 个选项(显然更多，但为了简单起见，我们同意):

设置一个 Elastic Beanstalk，它将至少有 1 个实例 24/7 运行，并且每个 url 有多个端点

使用 API Gateway，我们可以轻松地将 url 路由到特定的 Lambda 函数。有了这个，我们可以处理任何请求(很像设置 Elastic Beanstalk 应用程序)。

所有这些让我相信，一个完整的 Lambda 后端将完全有可能并且很容易创建，而成本只是让服务器 24/7 运行的成本的一小部分。那是对的吗？

现在，假设以上是正确的，我们需要确定使用 Lambda 是否真的比 Elastic Beanstalk 更有利。

对于简单的服务器，我们可以设置一些 Lambda 函数并收工(这可能比使用 Elastic Beanstalk 更简单、更便宜(至少对于小型项目而言))。

但是，对于具有更多 url 和数据库连接的更复杂的服务器，事情会变得更有趣。

这些是我在上述情况下使用 Lambda 时看到的问题

每个 url 都有它自己的 API 网关和它自己的 Lambda 函数。如果在多个函数中使用了任何代码或模块，我们必须将其复制并粘贴到每个函数中。

管理多个 Lambda 函数(和 API 网关)比管理单个项目/repo/whatever-you-wanna-call-your-code-base 更简单。

每个需要数据库连接的函数都必须在函数内进行连接(相对于在 Node.js 应用程序中具有恒定连接)。

避免前两个问题的唯一方法(我能想到的)是创建一个强大的函数来充当调度(主函数从 API Gateway 获取参数并确定在 Lambda 函数中运行哪个文件)。

在确定使用 Lambda over Elastic Beanstalk 是否值得时，我是否缺少任何要点？

Answer 1

听起来你已经想通了。您是正确的，使用 Lambda 而不是让服务器 24/7 运行可以显着节省成本。 This article提出 claim :

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 上工作的用途，至少现在还没有。例如，我确实需要一些方法来限制可以同时运行的 Lambda 函数的实例数量，以防止最大化可用的数据库连接或达到第三方 API 的使用限制。我还真的需要 Lambda 函数在我的 VPC 中运行，但这应该很快就会实现。