我对服务器世界比较陌生，所以请原谅我，如果其中一些是基本的（并且第一部分文字将是我解释我的逻辑以确保它没有缺陷）。我的所有问题都会加粗，以便您的帮助更容易：）。
我一直在研究和教授自己的一些AWS技术，我注意到在他们的移动中心，如果你想要云逻辑，他们只允许“自动”设置Lambda功能。在阅读和研究之后，我发现了一些指向“无服务器”架构的资源（Lambda支持的引入）。在过去，我的理解是Elastic Beanstalk被引入以帮助使服务器管理（尤其是移动设备）更加简单。
对于移动开发者，有两种选择（显然更多，但为了简单起见，我们会同意）：
所有这些让我相信完整的Lambda后端将完全成为可能并且易于创建，而成本只是服务器全天候运行的一小部分。这是正确的吗？
现在，假设上述情况正确，我们需要确定使用Lambda是否真的比Elastic Beanstalk更有用。
对于简单的服务器，我们可以设置一些Lambda函数并将其调用一天（与使用Elastic Beanstalk相比，它可能更简单，更便宜（至少对于小型项目而言）。
但是，对于具有更多网址和数据库连接的更复杂的服务器，事情会变得更有趣。
这些是我在上述情况下使用Lambda看到的问题
避免前两个问题的唯一方法（我能想到的）是创建一个充当调度的强大函数（main函数从API网关获取一个参数并确定在Lambda函数中运行哪个文件）
我是否有任何重点要确定是否值得使用Lambda而不是Elastic Beanstalk？
答案 0 :(得分：12)
听起来你已经弄清楚了。你是正确的，使用Lambda而不是让服务器全天候运行可以节省大量成本。 This article提出索赔：
至少可以为亚马逊的一些客户节省大笔资金 一位快乐的Lambda客户可以节省80％的云账单。
你可能想看一下管理一些痛点的Serverless Framework。
我认为随着亚马逊为Lambda添加更多功能以及为其构建更多第三方工具，许多痛点将随之消失。我不断发现Lambda的新用途，但我也经常发现一开始看起来很合适的用途，但至少还没有真正用于Lambda。例如，我真的需要一些方法来限制可以并发运行的Lambda函数的实例数，以防止最大化可用的数据库连接或达到第三方API的使用限制。我也非常需要Lambda函数在我的VPC中运行，但这应该很快就会到来。
答案 1 :(得分：7)
正如其他人已经指出的，运行Lambda与Elastic Beanstalk或您自我管理的EC2实例有一些好处。
虽然AWS支持Elastic Beanstalk和EC2的自动扩展。总是应该至少运行两个故障转移行为实例。运行两个“nano”实例作为故障转移的最小值，每个实例都会花费您（没有预留实例折扣）：$ 0.0059 * 24 * 30.5 = VM为$ 4.31，$ 0.05 * 8 GB = $ 0.40。所以一个实例是4.81美元，两个实例是9.62美元。但是，要使AutoScaling正常工作，您需要一个Load-Balancer设置，至少需要支付0.0225 * 24 * 30.5 = 16.47美元（忽略LCU费用）。 Load-Balancer可以由多个服务共享。对于这个计算，我只是人为地将它拆分为10，并得出结论：使用Eleastic Beanstalk或EC2的一个微服务将花费你9.62美元+ 1.65美元= 11.27美元。
那么与Lambda相比如何呢？使用Lambda，您可以按每次通话付费，每千兆字节付费。我忽略了通话费用，因为它是每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提到的限制现在已经消失。如今Lambdas可以在VPC内运行。即使我不知道限制并发实例数量的官方方法，如果您使用VPC，您可以限制可用IP的子网，并且每个Lambda将需要IP，以便您可以间接限制Lambda实例的数量。
如果一个人不太关心一致的性能，Lambda便宜且可扩展。非常合适的是小批量加工。
答案 2 :(得分：6)
问题实际上是FAAS与PAAS。 Lambda /无服务器架构可以被视为功能即服务，而Beanstalk属于平台即服务。
FAAS和PAAS之间存在很多混淆。许多人说FAAS也是PAAS。我想指出 FAAS和PAAS之间的区别特征。
说，我有一个CRUD应用程序，它具有创建，读取，更新和删除操作。通常，网络应用会在读取操作中获得更多流量。
+---------------------------------------------+--------------------------------------------------------+
| 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（一种所谓的“无服务器”架构）与PAAS区分开来。
答案 3 :(得分：0)
签出DynamoDB DAX客户端以获取lambda函数。如果您担心连接数据库的速度，它将延迟从毫秒降低到微秒。