我对服务器世界比较陌生,所以请原谅我,如果其中一些是基本的(我的第一部分文字将解释我的逻辑以确保它没有缺陷).我的所有问题都会加粗,让你的帮助更容易:).
我一直在研究和教授自己的一些AWS技术,我注意到在他们的移动中心,如果你想要云逻辑,他们只允许"自动"设置Lambda功能.在阅读和研究之后,我发现了一些指向"无服务器"架构的资源(Lambda支持的引入).在过去,我的理解是Elastic Beanstalk被引入以帮助使服务器管理(尤其是移动设备)显着简化.
对于移动开发者,有两个选项(显然更多,但为了简单起见,我们会同意):
设置一个Elastic Beanstalk,它至少有一个实例24/7运行并且每个url有多个端点
使用API Gateway,我们可以轻松地将URL路由到特定的Lambda函数.有了这个,我们可以处理任何请求(就像设置Elastic Beanstalk应用程序一样).
所有这一切都让我相信,一个完整的λ后端是完全有可能的,容易在有全天候运行的服务器成本的一小部分来创建.那是对的吗？
现在,假设上述情况正确,我们需要确定使用Lambda是否真的比Elastic Beanstalk更有益.
对于简单的服务器,我们可以设置一些Lambda函数并将其称为一天(与使用Elastic Beanstalk相比,它可能更简单,更便宜(至少对于小型项目而言).
但是,对于具有更多URL和数据库连接的更复杂的服务器,事情变得更有趣.
这些是我在上述情况下使用Lambda时遇到的问题
每个网址都有自己的API网关,并拥有自己的Lambda功能.如果在多个函数中使用任何代码或模块,我们必须将其复制并粘贴到每个函数中.
管理多个Lambda函数(和API网关)比管理单个项目/ repo /无论你想要调用你的代码库更加重要.
每个需要数据库连接的函数都必须在函数内连接(比如说,在Node.js应用程序中有一个连续的连接).
避免前两个问题的唯一方法(我能想到的)是创建一个充当调度的强大函数(main函数从API网关获取一个参数并确定在Lambda函数中运行哪个文件).
我是否缺少任何要点来确定是否值得使用Lambda而不是Elastic Beanstalk？
听起来你已经弄清楚了.你是正确的,使用Lambda而不是让服务器全天候运行可以节省大量成本.本文提出索赔:
它为亚马逊的一些客户节省了大笔资金,至少有一位快乐的Lambda客户可以节省80%的云账单.
您可能希望查看管理一些难点的无服务器框架.
我认为随着亚马逊为Lambda添加更多功能以及为其构建更多第三方工具,许多痛点将随之消失.我不断发现Lambda的新用途,但我也经常发现一开始看起来很合适的用途,但至少还没有真正用于Lambda.例如,我真的需要一些方法来限制可以并发运行的Lambda函数的实例数,以防止最大化可用的数据库连接或达到第三方API的使用限制.我也非常需要Lambda函数在我的VPC中运行,但这应该很快就会到来.
正如其他人已经指出的那样,运行Lambda vs Elastic Beanstalk或您自我管理的EC2实例有一些好处.
AWS支持Elastic Beanstalk和EC2的Auto-Scaling.总是应该至少运行两个故障转移行为实例.运行两个"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秒或更长时间.这些实例在请求之间被冻结.如果实例暂时不使用,则需要更长时间才能再次唤醒.增加内存可以减少预热和唤醒时间.但是,主要问题可能是访问外部数据源.由于实例在请求之间被冻结,因此不支持正确的连接池.如果你进行连接池,你最终可能会得到过时的连接.根据数据库和驱动程序的打开和关闭,连接可能非常昂贵.
如上所述,不直接支持连接池,这通常是数据库访问或访问其他系统的问题.如果您使用框架来加速开发,则可能不适合在Lambda中使用.
Mark B提到的限制现在已经消失.如今Lambdas可以在VPC内运行.即使我不知道限制并发实例数量的官方方法,如果您使用VPC,您可以限制可用IP的子网,并且每个Lambda将需要IP,以便您可以间接限制Lambda实例的数量.
如果一个人不太关心一致的性能,Lambda便宜且可扩展.非常合适的是小批量加工.
问题实际上是FAAS与PAAS.Lambda /无服务器架构可以被视为一种功能即服务,而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(一种所谓的"无服务器"架构)与PAAS区分开来.
京公网安备 11010802040832号 | 京ICP备19059560号-6 