現在“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 的文章
