什么场景（不）适合使用Lambda

Lambda是AWS推出的基于Function-as-a-Service(FaaS)的Serverless服务。我结合项目使用体验，发现Lambda不适合或者说不能独立支撑以下场景：

• 用户期望稳定的低延迟
• 请求需要在多个函数间跳转
• 可预期的大量调用

与此同时，Lambda和其它AWS服务结合起来能为以下场景提供良好的解决方案：

• 作为监听器异步响应Webhook (API Gateway + SQS + Lambda)
• 处理需要延时执行或指定时间执行的任务 (Step Functions + SQS + Lambda)

Lambda仅支持单请求模式，可以考虑使用AWS的App Runner或者GCP的Cloud Run替代。

背景介绍

笔者参与的项目大量使用Lambda进行开发，Lambda所承担的角色包括：作为AppServer支撑前端功能、监听第三方系统的Webhook，作为后台程序执行批处理任务，等等。在使用过程中，笔者感觉Lambda并非万能良方，有其设计和功能上的限制，所以根据项目的使用情况和体验，梳理了Lambda适合和不适合的场景，分享给大家，供大家在技术选型时进行参考。

Lambda有什么限制

• 单请求模式：一个实例一次只能处理一个请求，如果在处理完成前又有新的请求需要处理，Lambda需要创建一个新的实例来处理。
• 体积：一个函数解压后体积不能超过250MB，硬性限制；在使用Lambda时务必注意控制依赖，避免无用的依赖增大体积，并将静态文件等从代码库中抽离。特别值得注意的是Lambda运行时自带了aws-sdk，除非需要指定SDK的版本，否则请勿将SDK打入部署包中。
• 并发数量：默认的一个帐户的区域并发限制是1000，也就是说可以同时处理1000个请求；可向AWS提出申请扩展到上万。如果到达上限，新的请求会被节流。在大型项目中不同模块请务必使用不同的帐号，以隔离对并发的需求，避免单模块