最近一段时间，“无服务器”可以说是风头正劲。但更重要的是，这个概念并非空有炒作——自诞生以来不到五年，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% 触发过并发限制功能。

原文链接：