适合使用Lambda的场景是什么
同时，Lambda和其他AWS服务可以结合起来，为以下方案提供更好的解决方案：
作为监听程序异步响应web hook (apigatewaysqslambda ) ) ) )。
延迟运行或处理在指定时间运行的任务(Step Functions SQS Lambda ) ) )。
Lambda仅支持单请求模型，并且可以考虑使用AWS的App Runner或GCP的云run替代。
背景介绍
笔者参与的项目多采用Lambda进行开发，Lambda承担的角色有：作为AppServer支持前端功能、拦截第三方系统的Webhook、作为后台程序进行批处理在使用中，笔者觉得Lambda不是万能的，而是有其设计和功能上的限制，根据项目使用情况和体验，整理了Lambda匹配和不匹配的场景，供技术选型时参考。
Lambda有什么限制？
单请求模式：实例一次只能处理一个请求。 如果需要在处理完成之前处理新请求，Lambda必须创建并处理新实例。
体积：用一个函数解冻后的体积不得超过250MB。 硬件限制； 使用Lambda时，请注意控制依赖关系以防止无谓的依赖关系增加卷，并将静态文件等与代码库分离。 特别值得注意的是，Lambda运行时附带了aws-sdk。 除非需要指定SDK的版本，否则不要将SDK放在部署包中。
并发行数：默认单个帐户的区域并发限制为1000，可以同时处理1000个请求。 申请AWS可以扩展到上万。 一旦达到上限，新的要求就会被缩小。 在大型项目中，每个模块使用不同的帐户来隔离并发需求，以确保单个模块的工作负载波动不会影响整个系统的稳定性。 使用Reserved Concurrency可以限制一个函数的并发行数，但也减少了未设置Reserved Concurrency函数的并发上限。
超时时间：最多900秒的超时时间，不可更改； 如果Happy Path也无法确定运行时间小于900秒，则必须拆分Lambda或使用其他方案。
工具： Lambda有特定的部署方法，需要工具来确保完整的开发过程。 可用的工具包括CDK、SAM、服务器less等。Lambda的特点
生命周期
Lambda作为服务器less的计算服务的一个重要特征是按需创建实例。 这意味着在请求到来时创建并处理实例。 实例处理完成的请求将保留一段时间，以响应后续请求(热启动)。 实例空闲一段时间以上时，由Lambda回收。 AWS没有明确提到回收的等待时间。 AWS公式没有给出状态的标准名称。 这里使用非标准术语描述生命周期。 下图：
同步vs异步
Lambda函数有两种执行模式：同步和异步。 在同步模式下，当函数运行时，Lambda会创建/复用实例，等待实例运行完成，然后返回结果。 在异步模式下，Lambda将请求排队后立即返回，并在后台创建/复用处理实例。 使用异步模式时，可以设置重试次数。 如果重试失败，则可以将因设置而失败的请求发送到其他位置，如SNS主题。
许多AWS服务可以与Lambda集成，并且为了清楚如何调用Lambda，需要检查文档。 例如，API网关在同步模式下调用Lambda，而CloudWatch Event在异步模式下调用Lambda。
Lambda不适合的场景
用户希望稳定的低延迟
如果它基于Lambda的生命周期，并且有请求需要处理，则如果此时没有实例，Lambda将初始化并使用新实例。 也就是说是冷启动。 结合Lambda单请求模型的特点，一定会有相当数量的冷启动，这意味着请求的响应时间中混合了实例初始化时间，会发生延迟变动。 从项目经验来看，不复杂的NodeJS实现函数在启动时间大约1-3秒之间变动； 该区间的数值来自CloudWatch的日志输出，实际体验时间可能会更长，相应地会直接暴露给调用方。 因此，如果场景需要提供稳定的低延迟响应，同步调用Lambda是不合适的。
顺便说一下，实例的启动时间很重要，一些传统的Java APP应用程序可能需要几分钟才能启动，因此建议不要直接放置Lambda。
请求必须在多个实例之间跳转
如果一个请求需要同步跳转多个实例，最糟糕的情况是请求延迟加倍，并发数加倍。 以项目经验为例，有大于函数a -、大于函数B-、大于第三方系统访问链接的API网关-。 在测试环境(使用量少、流量波动大)中，从页面调用此接口的时间基本上在8秒以上，有时超过10秒，客户怀疑系统性能存在问题。网格结构设计的微服务模型的应用需要服务之间频繁同步通信，放置Lambda必须谨慎。
预期的大量调用
如果一个接口上有大量调用，则基于Efficiency和Cost考虑，Lambda不一定是正确的选择。
一般而言，如果一个接口上有大量调用，则为每个调用分配一个独占实例显然是不明智的选择。 这大大增加了单个实例的极限开销。 在这种情况下，增加单个实例可以同时处理的调用数可以提高系统吞吐量，从而提高整个系统的效率。
从价格上考虑，Lambda使用的是基于呼叫次数计费的模型，当呼叫次数达到一定阈值以上时，其成本有效性一定会低于基于使用资源时间计费的模型。 让我们在虚拟场景中比较Lambda和App Runner。 假设有一个接口，一天在3小时的繁忙期处理600 RPS的呼叫，12小时的非繁忙期处理60 RPS的呼叫，剩下的时间不调用。 一次呼叫时间为500ms。 两项服务的价格比较如下。
Lambda:基于128M内存的配置，如果每天调用600*60*60*3 60*60*60*12=9072000次，则每月费用为$335.76。 感兴趣的读者可以使用AWS定价计算器自己计算。
App Runner:基于1 vCPU和2G内存配置，假设每个实例可以同时处理60个请求，如果超过60个，则创建并处理新实例。 那么，每天繁忙时段的费用是$2.30，非繁忙时段的费用是$0.77，没有呼叫时段的费用是$0.34，每月的总费用是$102。 如果您对费用感兴趣，请转至App Runner Pricing页面上的example : highvolumeproductionapp。
文/蓝盟IT外包
中文
电话咨询
微信咨询
公众号
