现在“Serverless”可能是一个流行术语，但是它并非空洞的存在。AWS Lambda 推出还不到 5 年的时间，就已经被近一半使用 AWS 基础设施的公司所采用。在本报告中，我们分析了数千家公司的 Serverless 使用情况，以了解在现实中他们是如何使用 Serverless（以及使用到了什么程度）。
Serverless 消除了提供和管理基础设施组件 (例如，服务器、数据库、队列，甚至容器) 的必要性，能够允许团队专注于代码，同时最小化他们的运维开销。本报告将关注 Serverless 领域的一个子集，即所谓的“函数即服务”(functions-as-a-service, FaaS)，它提供了与公共云相同的即付即用模型，但处于“函数”级别，而不是基础设施组件级别。函数只是简单的代码片段，在用户请求或其他事件调用时执行离散的业务逻辑。
对于本报告来说，我们会关注 AWS Lambda，它在 2020 年初是我们的用户群中最成熟和被广泛采用的 Serverless 平台。在该报告的未来版本中，我们可能会研究来自其他提供商的 Serverless 产品，比如 Google Cloud Platform 和 Microsoft Azure。
一半的 AWS 用户已经采用了 Lambda
在 2020 年初，Lambda 已经不再是小众的技术。使用 Amazon Web Services 的 Datadog 客户中有近一半已经采用了 Lambda。（参见文末的方法论章节以了解我们是如何定义采用 Lambda 和使用 AWS 的。）这样的采用率，再结合下面章节所讨论的根据环境分解的 Lambda 使用情况，表明 Lambda 并不局限于云原生的早期采用者和小众使用场景。相反，在采用 AWS 基础设施的各种各样的公司中，serverless 函数得到了广泛的应用。
Lambda 在大型环境中更为普遍
令人意外的是，Lambda 的广泛采用并不是由更新、更小的公司所驱动的。相反，我们看到 Lambda 的采用情况与公司基础设施环境的大小有着明显的相关性，无论环境指的是主服务器、容器，还是 serverless 函数均是如此。（参见文末的方法论章节以了解我们规模区分的详细信息。）在基础设施规模最大的那些公司中，超过四分之三的公司都采用了 Lambda。
使用容器的用户已经大面积采用 Lambda
在 AWS 中运行容器的公司特别中意于 Lambda。截至 2020 年 1 月，在 AWS 运行容器的组织中有近 80% 都采用了 Lambda。尽管 serverless 函数和容器是两个非常不同的环境，但是它们似乎基于类似的原因而被众人所接受，比如为了简化运维而抽象出基础设施的关注点。在一些使用场景中，Lambda 和容器基础设施是直接连接的（例如，使用 Lambda 函数来触发 Amazon Elastic Container Service 的任务），但是更多的组织可能正在分别运行它们，以满足不同的需求。例如，某家公司可能在一个容器集群中运行其大部分的应用程序，同时将突发的、短期运行的任务（例如支付处理）转移到 serverless 的函数中。
Amazon SQS、DynamoDB 与 Lambda 是绝配
在将函数连接至基础设施和应用程序组件时，Lambda 用户有大量可选的技术。当函数被触发时，它通常会将自己所产生的数据发送给消息队列，而消息队列可以将数据路由至其他的 Lambda 函数、基于服务器的应用程序或者云服务。消息队列能够让组织采用“仅为真正使用的内容服务”的 serverless 模式。相对于调用其他的函数并一直等待响应（占用可计费的调用时间），serverless 可以通过消息队列的方式进行异步调用。由于函数是临时的和无状态的，所以它们通常会对单独的持久化数据存储进行读写操作。
在与 Lambda 函数相同的请求中所调用或查询的服务里面，Amazon DynamoDB 名列前茅。键值和文档存储非常适合 Lambda 函数，因为它是一个托管的、可自动伸缩的数据存储，可以保证低延迟。在使用 Lambda 的场景中，数据存储方面另一个最流行的选择是 SQL 数据库（无论是 Amazon RDS 实例还是自管理数据库）和 Amazon S3。Amazon SQS（Simple Queue Service）是 Lambda 请求中消息队列的首选，其次是 Amazon Kinesis 和 Amazon SNS（Simple Notification Service）。SQS 在逻辑上非常适合 serverless 架构：它易于搭建和扩展，成本相对较低，并且提供与 Lambda 的紧密集成。
Lambda 用户中，Node.js 和 Python 占据了主导地位
在 Lambda 用户可用的语言和框架中，我们看到有两个明显占据了主导地位：Python 和 JavaScript（借助 Node.js）。在当前所有已部署的 Lambda 中，有 47% 在运行 Python，另外还有 39% 在运行 Node.js 应用。Python 3 与 Python 2 的比例是 2 比 1（Python 2 在 2020 年 1 月正式结束了其生命）。
Python 和 Node.js 的 Lambda 运行时的流行程度反映了最近应用程序开发的趋势以及 Lambda 服务本身的发展。AWS 在 2014 年首次发布 Lambda 预览版，其中 Node.js 就是第一个得到支持的运行时，2015 年又增加了对 Java 和 Python 支持。对 C#(借助.NETCore)、Go 和 Ruby 的支持则是在 2018 年新增的。
Lambda 函数运行时间的中位数是 800 毫秒
Lambda 函数运行时间的中位数约是 800 毫秒，这是在所有调用中取平均值得到的，但是延迟分布曲线的尾部很长。四分之一的 Lambda 函数平均执行时间超过 3 秒，12% 的函数执行时间超过 10 秒。一些 Lambda 函数的持续时间很长，这是值得注意的，因为 serverless 的延迟不仅影响应用程序的性能，还会影响云计算的成本。Lambda 定价是基于计算时间的“GB-seconds”：分配给函数的内存 (详细信息如下图所示)，并乘以其调用的持续时间。
我们将函数持续时间的分布放大一下可以发现，将近五分之一的函数在 100 毫秒内执行完成，大约三分之一在 400 毫秒内执行完成。
一半的 Lambda 函数具有最小的内存分配
如前所述，Lambda 调用的成本是根据持续时间和函数内存的乘积计算出来的。因此，鼓励运行 Lambda 的公司限制其函数的内存分配（这是一个可配置的设置，因此比函数的持续时间更容易控制）。实际上，47% 的函数被配置为使用最小的内存运行，即 128 MB，而只有 14% 的函数的内存分配大于 512 MB，用户可以为每个函数最多分配 3,008 MB。
三分之二的超时时间定义都在 1 分钟以下
每个 Lambda 函数都有一个可配置的超时设置，时间从 1 秒到 15 分钟不等，这是 Lambda 调用所允许的最长持续时间。大多数函数都使用了较短的超时：三分之二的超时时间配置为 60 秒或更少。(创建函数时的默认超时时间为 3 秒。)
通常来讲，建议的做法是使用较短的超时时间，因为挂起函数会增加云成本，而且 Lambda 应用程序架构经常需要快速响应。Amazon API Gateway 通常用于在 Lambda 函数前提供 REST 接口，它的最大超时设置为 29 秒。因此，API 网关后面的任何 Lambda 函数如果响应时间超过 29 秒的话，都将会导致一个错误，即使 Lambda 最终成功地完成了它的工作也是如此。尽管有这些考虑因素，但是依然有许多函数都配置为所允许超时的最大设置：当前的 900 秒限制以及之前的 300 秒限制（有效期到 2018 年 10 月）。
仅有 4% 的函数定义了并发限制
默认情况下，在每个 region 中，Lambda 客户的所有函数会有 1000 个并发执行的限制。用户可以设置每个函数的并发限制，这样的话，就能够为特定函数在总并发池中预留一部分。如果函数超过了它的并发限制，就会进行节流。
如今，在所有的函数中，尽管大多数组织都知道有这个可选限制，但是只有 4.2% 的函数配置了并发性限制。实际上，88.6% 运行 Lambda 的公司在其环境中至少为一个函数使用了并发限制。定义了并发限制的函数更有可能被限流。在 5 天的评估窗口中，具有并发限制的函数中有 8.3% 至少被限制一次，而只有 0.3% 的函数仅受到 region 的限制，而不是每个函数本身的限制。
方法论
样本
在本报告中，我们收集了 Datadog 客户群中数千家公司的使用数据。虽然 Datadog 的客户涵盖了各个公司规模和行业范围，但他们确实有一些共同的特点。首先，他们往往对软件基础设施和应用程序的性能非常重视。他们比一般的人群更倾向于采用云平台和服务。本文中的所有结果都存在偏见，因为数据来自我们的客户群，这是一个庞大但不完美的全球市场样本。
Lambda 的采用情况
在这个报告中，我们认为如果某家公司一个月里至少运行五个不同的 Lambda 函数，那么我们就认为他们采用了 Lambda。Datadog Forwarder 函数会将 S3 和 CloudWatch 日志等数据发送到 Datadog，该函数不包含在计数中。
关于对 AWS 的使用
如果一个公司在一个月内至少运行 5 个不同的 Lambda 函数或 5 个不同的 EC2 实例，那么我们就认为该公司在使用 AWS。通过这种方式，我们可以捕获 AWS 用户的基本信息，从而将它们分为专门运行 EC2 实例的公司、专门运行 serverless 函数的公司或同时运行这两种功能的公司。
环境的规模
为了评估公司基础设施环境的相对规模，我们检查了公司的 serverless 函数、容器、物理服务器、云实例和其他基础设施服务的使用情况。虽然类别（如“中型”和“大型”）之间的界限必然是人为定义的，但类别之间的趋势是明显的。
关注我并转发此篇文章，私信我“领取资料”，即可免费获得InfoQ价值4999元迷你书！
閱讀更多 InfoQ 的文章
