作者 | 望宸

來源 | Serverless 公眾號

相比去年，國外 Serverless 的適用群體在迅速擴大，函式執行時長不斷增加，使用方式也越加成熟，開發者工具也更加開放。

本文是對 Datadog 最新的一份 Serverless 報告的解讀，歡迎大家留言討論。

每項新技術的產生和演進過程中，都會有他自己的擁躉，也會有持懷疑論者。Serverless 的美在於他可以儘可能的解放客戶在

基礎設施上的投入，只需專注於自己的業務，讓技術產生更多商業價值，同時，客戶只需要真正為使用量付費，無須讓計算資

源常駐。

“Datadog 上一半的 AWS 客戶使用了 Lambda，80% 的 AWS 容器客戶使用了 Lambda。”

是的，這個資料來自 Datadog 去年的一份調研報告，客觀反映了 Serverless 在海外市場的落地程式。一年之後，Datadog 

釋出了第二份 Serverless 調研報告，我們來一起看看 Serverless 在海外的最新進展，這對於無論是已經投入建設 Serverless，還是仍處於觀望狀態的決策者和使用者而言，也許都能獲得一些參考。

觀點 1. Lambda 的呼叫頻率比兩年前高3.5倍，執行時長達90

0小時/天

Serverless 的使用深度如何來定義？

自 2019 年以來，一直在使用 Lambda 的企業已大大提高了其使用率。平均而言， 到 2021 年初，這些公司每天呼叫函式的次數是兩年前的 3.5 倍。此外，在同一組 Lambda 使用者中，每家企業的功能平均每天平均執行達 900 個小時。 

普通雲伺服器，是按伺服器的租用配置和租用時長進行收費的，其中，租用配置是依據 vCPU 和記憶體定價。

而函式計算則不 同， 按使用過程中的呼叫次數和函式執行時長收費的。因此，呼叫次數和函式執行時長是衡量客戶使用

 Serverless 深度的指標。報 告中未提供每天呼叫次數絕對值的資訊，但我們可以依據每天執行 900 小時執行時長的資料，對

客戶在 Serverless 的消費做 一 個區間預估。

阿里雲函式計算的收費標準來計算，使用預付費模式：

1GB 計算力例項執行 1 秒所需的費用是 0.00003167 元，以記憶體規格 1GB，每天執行 900 小時來計算，預計將消費 102.6 元

，年度消費是 3.7 萬，再搭上儲存、網路、安全、資料庫等其他雲產品的消費，已經是一箇中型企業的雲上支出了。此外，函

數的呼叫次數所產生的費用通常不會太多，尤其是 Python 這類和 AI 建模相關的函式應用，阿里雲函式計算每天呼叫 100 萬

次的費用是 13.3 元。

觀點 2. Lambda 執行時長的中位數是 60 毫秒，僅為一年前的

一半

事件驅動架構下，執行時長是一個關鍵生產因素

函式的執行時長是 FaaS 領域的新概念，因為 FaaS 是事件驅動架構，實際觸發時，才會呼叫計算資源執行函式應用並進行計

費，函式應用執行時間越長，費用就會越高。不同於函式計算，普通雲伺服器則是按租用伺服器來計費，雖然普通雲伺服器也

提供自動彈性伸縮的功能，但由於本身不是事件驅動架構，導致伸縮規則上是受限的，而且，普通雲伺服器是按秒計費，而業

內的 FaaS 產品，例如 Lambda、阿里雲函式計算都已經支援按毫秒計費，計費顆粒度越細，計算成本的最佳化空間就越大。

從資料結構上我們可以看到，越來越多的 AWS 客戶正在遵循官方提供的成本最佳化最佳實踐，來縮短函式的執行時長，從而進

一步最佳化計算成本，最大程度發揮 Serverless 的成本優勢。

下圖中，函式執行時長曲線的尾巴很長，這表明 Lambda 不僅支援短期作業，而且已經在支援計算密集型的用例。雖然此份

報告沒有展示哪些計算密集型的業務場景使用了 Lambda，但從國內雲廠商宣傳的案例看，主要是音影片處理、AI 建模類的

應用。

觀點 3. 除 AWS Lambda 外，Azure Function 和 Google 

Cloud Function 的增長也很迅速

百家齊放是行業走向成熟的必經階段

AWS Lambda 是最早的 FaaS 產品，Azure 和 Google 緊隨其後，推出了 FaaS 產品，他們的增速可能得益於整個行業的成熟

度，從一年前只有 20% 的 Azure 客戶使用 Azure Function，一年後，這一資料已經增長到了 36%，而 Google 已經有 25%

 的雲上客戶在使用 Cloud Function 了。

該部分，報告中引用了 Vercel 這個案例：

Vercel 是一個很實用的網站管理和託管工具，可以快速部署網站、App，甚至不需要購買伺服器、域名、安裝與配置 Nginx、

上傳網站檔案、新增 DNS 解析項、配置網頁證照，最重要的是個人使用是永久免費。

Vercel 託管的都是一些耦合度不高的應用。很顯然， Vercel 的這一商業模式充分利用了 Serverless 技術的成本優勢，來儘可

能降低免費個人使用者帶來的伺服器成本，透過函式應用來處理來自服務端渲染、API 路由等的請求。在過去的一年裡，Vercel

每月的伺服器呼叫次數從 2.62 億次增加到每月 74 億次，增長了 28 倍。

Vercel 官網：

觀點 4. AWS Step Functions 是 Lambda 的最佳伴侶，平均

每個工作流包含 4 個函式，並逐月上升

函式應用的編排功能正在擴充函式應用的邊界

一個完整的業務邏輯通常不是一個函式應用就能完成的，需要用到多個函式應用，甚至還涉及到彈性計算、批次計算等計算單

元。這時候，透過工作流的編排能力，對各個計算任務進行順序、分支、並行等方式的分散式編排，可以簡化繁瑣的業務拼接

帶來的程式碼工作，還能視覺化監控整個業務流程中各個執行環節的狀態，一舉兩得。AWS Step Functions 就提供了這樣的功

能。

報告顯示，平均每個 Step Functions 工作流包含 4 個 Lambda 函式，並且呈現逐月增長的趨勢。說明越來越的客戶正使用工

作流來處理越來越複雜的業務邏輯。其中，執行時間在 1 分鐘內的工作流佔比 40%，但也不乏一些執行時長多於 1 小時甚至

超過 1 天的工作流，這些長時間執行的工作流以 AI 建模為主。

該部分，報告中引用了 Stedi 這一案例，這家企業是在 B2B 交易的交易領域提供結構化訊息傳送的服務，例如營銷郵件的推送

等服務，這類業務場景具備事件觸發、短時間需要呼叫海量目標郵箱郵箱的特點，Serverless + 工作流就可以很好的滿足了客

戶在成本和開發運維效率上進行最佳化的訴求。

Stedi 官網：https：//。com/

觀點  5. 四分之一的 AWS CluodFront 客戶使用 Lambda 

@Edge

邊緣正成為 Serverless 的新市場

Lambda@Edge 是 Amazon CloudFront 的一個功能，它可讓客戶在靠近應用程式使用者的地方執行程式碼，從而提高效能，降

低延遲。使用 Lambda@Edge，客戶無需在全球多個地方預置或管理基礎設施，只需按使用的計算時間付費，程式碼未執行時

不產生費用。

相當於在邊緣的場景下，網路將 Serverless 的計算能力一起提供給客戶，而無須從雲端呼叫算力，提高了那些對延遲敏感的邊

緣業務的客戶體驗，例如物聯網場景下影片監控和智慧分析、業務監測和分析等任務。

報告顯示，四分之一的 Amazon CloudFront 客戶使用了 Lambda@Edge，其中 67% 的客戶的函式執行時長不到 20 毫秒，

說明這部分應用對延遲非常敏感，這類的邊緣業務需求越多，Serverless 在邊緣端的潛力就越大。

觀點 6. 超過一半的客戶函式預留例項的資源使用率不到 80%

冷啟動是事件驅動架構下一個無法迴避的命題

尤其是在 Java/.Net 的程式設計框架下，應用的啟動會更慢，因為 Java 需要初始化其虛擬機器 (JVM) ，並將大量類載入到記憶體中，

然後才能執行使用者程式碼。業內提供了很多最佳化冷啟動的思路，例如提供函式預留例項，或者透過按需載入和更高效的儲存和算

法來提升容器映象的拉取速度，從而最佳化冷啟動速度。

本質上講，函式預留例項是避免冷啟動的一個見效很快的方式，但他並沒有從根本上解決冷啟動的問題，資源預留的越多，浪

費的就越多，這和 Serverless 主張的按需使用是背道而馳的。因此，今年的報告非常關注客戶在函式預留例項的使用率情況。

報告顯示，57% 使用函式預留例項的客戶用了不到預留例項中 80% 的資源，其中，超過 30% 的客戶僅用了不到 40% 的資

源 ；使用率達 80%-100% 的客戶超過 40%，那麼這部分客戶應當仍然會遇到冷啟動的問題。因此，不斷最佳化業務的預留實 例

設 計仍是廠商和客戶需要共同面對的命題，相關的最佳實踐會有較高的指導意義。感興趣的朋友可以看看阿里雲函式計算的這

份 最佳實踐 。

觀點 7. 開源無伺服器框架是部署函式應用的主要方式

應用拆的越細，部署難度越大

Serverless 架構下，手動部署幾個函式應用可能不太複雜，一旦當應用擴充套件到幾十、幾百個的時候，應用的部署難度就會被成

倍放大，此時透過一些部署工具來部署，可以提高部署效率。正如 Kubernetes 是用來自動部署、擴充套件和管理容器化應用程式

的，在管理容器的過程，Kubernetes 已經是必不可少的工具。

報告顯示，80% 以上的客戶使用 Serverless Framework 來部署和管理函式應用，雖然報告未給出原因，但大體離不開 

Serverless Framework 的易用性、開放性和社群屬性，報告預計基礎設施即程式碼類的部署工具在大規模部署無伺服器應用程

序方面將扮演更重要的角色，AWS 自研的三個部署工具，vanilla CloudFormation、AWS CDK 和 AWS SAM 的使用率分別

是 19%、18% 和 13%。（存在同一個客戶同時使用兩個或多個工具，因此使用率疊加後高於 100%）

回到國內，阿里雲、百度雲、華為雲、騰訊雲均提供了自家閉源的部署工具，騰訊雲和 Serverless Framework 合作，開發了

 Serverless 應用中心，阿里雲則是在去年開源了 Serverless Devs，提供函式應用的部署、運維和監控，此外，國內另一款提

供 Node.js 開發態框架的開源專案 Midway，已經獲得 4k+ 的 star，相信隨著參與 Serverless 的開發者的增加，國內開源工

具生態會越發活躍。

觀點 8. Python 是最流行的 Lambda 執行時，尤其是在大型

環境中

Serverless 天然支援多語言的開發框架。哪類程式語言最為流行呢？

報告顯示，58% 的使用者使用 Python，Node.js 則佔據了 31% 的份額，Java、Go、.NET Core 和 Ruby 的份額均未超過 10%

。但考慮到不同廠商各自的特點，阿里雲上的 Java 份額可能會更高些，Azure 上 .NET 的客戶會更多些。

有趣的是，在小型的 Lambda 執行環境中，Node.js 的份額高於 Python，隨著函式規模的增長，Python 就越來越流行，而

在企業級組織中，Python 的使用頻率是 Node.js 的 4 倍，如下圖：

雷卷在阿里雲內網分享了報告中程式語言部分的分析：大型企業在大資料、AI 等方面，使用 Python 比較多，而且他們使用的

 Lambda 量也比較大，所以在 Lambda 的數量上 Python 有絕對的優勢；Node.js 應用用不了那麼大的執行期 (多核 CPU 和

大記憶體），通常都是小型例項，另外可能是個人的 Node.js 開發者，通常也會選擇小型的 Lambda 環境。

除此之外，各類程式語言的版本的使用分佈如下，依次遞減，Python 3.x、Node.js 12、Node.js 10、Python 2.7、Java 8、

Go 1.x、.NET Core 2.1、.NET Core 3.1。

總結

整體上，相比去年，國外 Serverless 的使用群體在迅速擴大，函式執行時長不斷增加，使用方式也越加成熟，開發者工具也

更佳開放。在國內，Serverless 已經不在侷限一些離線任務或低耦合性應用，已經有不少企業客戶將 Serverless 應用於生產

環節的核心鏈路上，例如世紀聯華將交易系統、會員系統、庫存系統、後臺系統和促銷模組等核心應用均部署在函式計算上，

來減輕客戶在基礎設施上的投入；閒魚已經開始實踐對傳統巨型應用的 Serverless 化改造，去攻克在 Functions 之間程式碼復

用、對函式的依賴做統一升級等業內難題。應用的改造需要時間和視窗期，相信會有越來越的企業客戶選擇 Serverless 來解放

雙手。