最近一段时间，“无服务器”可以说是风头正劲。但更重要的是，这个概念并非空有炒作——自诞生以来不到五年，AWS Lambda已经得到近半数AWS云服务用户的接纳。在本份统计报告中，我们跟进数千家企业的无服务器技术使用情况，旨在总结无服务器计算在现实世界中的普及水平（以及整体使用量）。

无服务器计算，强调的是一种前所未有的资源使用方式：它同样采用公有云最鲜明的按需计费模式，但交付的却是“函数”资源，而非传统的基础设施组件。顺带一提，函数是指部分特定代码段，负责根据用户请求或者其他事件的调用执行离散的业务逻辑单元。

在本份报告中，我们将主要着眼于AWS Lambda——截至目前，它仍是现有及未来潜在用户群体当中成熟度最大、使用范围最广的无服务器平台。当然，在本报告的后续迭代中，我们也会根据情况关注其他服务供应商（例如Google Cloud Platform以及微软Azure）的无服务器产品。

半数AWS用户对Lambda青眼有加

2020年初，Lambda早已不是什么小众技术。目前，我们调查的近半数AWS云服务客户都在使用Lambda。从服务采用率以及按所在行业背景划分的Lambda使用率角度来看，我们发现Lambda已经全面突破了早期云原生应用以及其他小众用例。事实上，无服务器功能目前已经在采用AWS服务的各类企业客户当中得到广泛普及。

Lambda在大型业务中的普及度较高

可能令大家意想不到的是，Lambda广泛普及的背后，依靠的并不是那些规模较小的新兴企业。相反，我们发现Lambda采用率与企业基础设施环境规模之间存在着显著的关联性。无论这类环境以传统服务器、容器还是无服务器为主导，在基础设施规模最大的企业群体当中，有超过四分之三的公司已经开始使用Lambda。

容器用户对Lambda表现出高涨的热情

事实证明，Lambda在那些立足AWS环境运行容器的企业客户中极受欢迎。截至2020年1月，在AWS上运行容器的企业中，近八成已经开始使用Lambda。尽管无服务器函数与容器属于两种截然不同的环境，但出于类似的业务改进诉求，企业对二者表现出了类似的热情——例如通过对基础设施的抽象化，简化日常运营流程。在某些用例当中，用户会将Lambda与容器直接连通（例如使用Lambda函数触发Amazon Elastic Container Service任务）；则大多数企业则以各自独立运行的方式满足不同业务需求。例如，一家企业可能将大部分应用程序运行在其容器集群当中，同时将那些突发性、仅需要短期运行的任务（例如付款处理）交由无服务器函数打理。

Amazon SQS 与DynamoDB：Lambda的好伙伴

Lambda用户可以通过多种技术选项，将各类函数与基础设施乃至应用程序组件进行对接。在被触发之后，函数往往会将产生的数据发送至消息队列，再由消息队列进一步将数据路由至其他Lambda函数、基于服务器的应用程序或者云服务处。消息队列能够帮助组织获取无服务器服务提供的“按需计费”模式。各类无服务器函数可通过消息队列进行异步调用，这就打破了只能由一项函数调用另一项函数、并在等待响应的过程中长期闲置（这会显著增加计费时长）的困境。另外，由于函数具有临时性与无状态等特征，因此通常可以面向独立的持久数据存储执行读取或写入。

在包含Lambda函数的请求当中，Amazon DynamoDB成为调用或查询比例最高的配套服务选项。很明显，这是一套云托管型自动规模伸缩数据存储方案，较低的延迟水平配合键值/文档存储机制天然适合与Lambda函数的协同需求。在Lambda用例当中，SQL数据库（包括Amazon RDS实例以及其他企业自主管理的数据库）与Amazon S3则成为第二及第三大高人气数据存储选项。Amazon SQS（简单队列服务）则成为Lambda请求中的首选消息队列方案，紧随其后的是Amazon Kinesis与Amazon SNS（简单通知服务）。

Node.js与Python在Lambda用户中占据主导地位

在Lambda用户群体之内，我们还在编程语言与框架方向上找到两大领先方案选项：Python与JavaScript（通过Node.js）。在目前已经部署的全部Lambda服务当中，有47%运行有Python代码，另有39%运行着Node.js应用程序。其中Python 3的普及度又比Python 2（已经于2020年1月停止支持）高一倍。

Python与Node.js Lambda运行时的广泛普及，反映出应用程序开发领域的最新趋势以及Lambda服务自身的前进方向。AWS于2014年首次发布Lambda预览版本，而Node.js则成为首个受到支持的运行时。在接下来的2015年中，Java与Python支持也陆续上线。在2018年的最新一轮迭代中，Lambda又迎来对C#（通过.NET Core）、Go以及Ruby的支持。

函数的中位数运行时长为800毫秒

在全部调用当中，Lambda函数的中位数运行时长为800毫秒，但持续时长也呈现出明显的长尾分布倾向。有四分之一的Lambda函数平均执行时间超过3秒，12%的函数甚至拥有10秒甚至更长的时间周期。我们之所以高度关注某些特定Lambda函数的长时间运行情况，是因为这不仅会直接影响到应用程序的性能表现，同时也决定着云资源使用成本。Lambda的定价基于“GB-秒”这一计算单位，即分配给特定函数的内存乘以调用所持续的时长。

进一步关注函数持续时长分布，可以发现近五分之一的函数会在100毫秒之内执行完毕，而且约三分之一的函数会在400毫秒内结束。

半数Lambda函数仅具有最低内存容量

如上所述，Lambda函数的调用成本由函数持续时长与内存占用量相乘而计算得出。因此，采用Lambda服务的企业当然会尽可能限制内存分配量（这是一项可配置选项，且控制难度远低于函数持续时长）。实际上，有47%的函数以128 MB最低内存容量方式运行。更重要的是，虽然AWS允许用户为每项函数分配最高3008 MB内存，但只有14%的函数拥有超过512 MB的内存分配量。

三分之二的预定义超时低于1分钟

每项Lambda函数都拥有一条可配置的超时定义，范围在1秒到15分钟之间，其上限代表着Lambda调用所允许的最长持续时间。大部分函数匹配的超时都非常短暂——根据本次调查，三分之二的超时配置不超过60秒（创建函数时的默认超时为3秒）。

之所以建议使用较短的超时配置，是因为函数闲置既会显著增加云服务成本，也不符合Lambda应用架构所通常强调的快速响应理念。用户通常会选择Amazon API Gateway在Lambda函数之前提供REST接口，其最大超时设置为29秒。因此，即使Lambda成功完成了任务，API网关后的一切Lambda函数也需要经过29秒才会被判定为出现响应超时错误。虽然这一保障措施已经相当安全，但大部分用户会为函数设置最大允许超时量——以往上限为300秒（截至2018年10月），目前的最新上限已经提升至900秒。

只有4%的函数具有预定义并发限制

在默认情况下，Lambda客户只能在特定区域内为全部函数保留1000条并发执行空间。用户可以为每项函数设置并发限制，相当于为其指定总并发池中的一定并发资源比例。如果该项函数超出并发限制量，将无法进一步占用并发资源。

目前，虽然大多数客户都很清楚并发限制选项，但只有4.2%的函数实际使用到这项限制功能。但在另一方面，有88.6%的Lambda客户在业务环境中至少对一项函数做出了并发限制。事实证明，具有并发限制的函数确实极有可能发生并发量激增情况。在为期5天的评估窗口当中，有8.3%的并发限制函数至少触发过一次限制功能；相比之下，按区域限制（而非按函数限制）的函数中仅有0.3%触发过并发限制功能。

原文链接：

https://www.datadoghq.com/state-of-serverless/

创作场景

调查了数千家企业，我们发现 Lambda 更受大型企业欢迎