[[406964]]

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

每項新技術的產生和演進過程中，都會有他自己的擁躉，也會有持懷疑論者。Serverless 的美在于他可以盡可能的解放客戶在基礎設施上的投入，只需專注于自己的業(yè)務，讓技術產生更多商業(yè)價值，同時，客戶只需要真正為使用量付費，無須讓計算資源常駐。

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

是的，這個數(shù)據(jù)來自 Datadog 去年的一份調研報告，客觀反映了 Serverless 在海外市場的落地進程。一年之后，Datadog 發(fā)布了第二份 Serverless 調研報告，我們來一起看看 Serverless 在海外的最新進展，這對于無論是已經投入建設 Serverless，還是仍處于觀望狀態(tài)的決策者和使用者而言，也許都能獲得一些參考。

觀點

觀點一：Lambda 的調用頻率比兩年前高 3.5 倍，運行時長達 900 小時 / 天

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

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

普通云服務器，是按服務器的租用配置和租用時長進行收費的，其中，租用配置是依據(jù) vCPU 和內存定價。

而函數(shù)計算則不同，按使用過程中的調用次數(shù)和函數(shù)運行時長收費的。因此，調用次數(shù)和函數(shù)運行時長是衡量客戶使用 Serverless 深度的指標。報告中未提供每天調用次數(shù)絕對值的信息，但我們可以依據(jù)每天運行 900 小時運行時長的數(shù)據(jù)，對客戶在 Serverless 的消費做一個區(qū)間預估。

以阿里云函數(shù)計算的收費標準來計算，使用預付費模式：

每 1 GB 計算力的實例運行 1 秒所需的費用是 0.00003167 元，以內存規(guī)格 1GB，每天運行 900 小時來計算，預計將消費 102.6 元，年度消費是 3.7 萬，再搭上存儲、網(wǎng)絡、安全、數(shù)據(jù)庫等其他云產品的消費，已經是一個中型企業(yè)的云上支出了。此外，函數(shù)的調用次數(shù)所產生的費用通常不會太多，尤其是 Python 這類和 AI 建模相關的函數(shù)應用，阿里云函數(shù)計算每天調用 100 萬次的費用是 13.3 元。

觀點二：Lambda 執(zhí)行時長的中位數(shù)是 60 毫秒，僅為一年前的一半

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

函數(shù)的執(zhí)行時長是 FaaS 領域的新概念，因為 FaaS 是事件驅動架構，實際觸發(fā)時，才會調用計算資源執(zhí)行函數(shù)應用并進行計費，函數(shù)應用執(zhí)行時間越長，費用就會越高。不同于函數(shù)計算，普通云服務器則是按租用服務器來計費，雖然普通云服務器也提供自動彈性伸縮的功能，但由于本身不是事件驅動架構，導致伸縮規(guī)則上是受限的，而且，普通云服務器是按秒計費，而業(yè)內的 FaaS 產品，例如 Lambda、阿里云函數(shù)計算都已經支持按毫秒計費，計費顆粒度越細，計算成本的優(yōu)化空間就越大。

從數(shù)據(jù)結構上我們可以看到，越來越多的 AWS 客戶正在遵循官方提供的成本優(yōu)化最佳實踐，來縮短函數(shù)的執(zhí)行時長，從而進一步優(yōu)化計算成本，最大程度發(fā)揮 Serverless 的成本優(yōu)勢。

下圖中，函數(shù)執(zhí)行時長曲線的尾巴很長，這表明 Lambda 不僅支持短期作業(yè)，而且已經在支持計算密集型的用例。雖然此份報告沒有展示哪些計算密集型的業(yè)務場景使用了 Lambda，但從國內云廠商宣傳的案例看，主要是音視頻處理、AI 建模類的應用。

觀點三：除 AWS Lambda 外，Azure Function 和 Google Cloud Function 的增長也很迅速

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

AWS Lambda 是最早的 FaaS 產品，Azure 和 Google 緊隨其后，推出了 FaaS 產品，他們的增速可能得益于整個行業(yè)的成熟度，從一年前只有 20% 的 Azure 客戶使用 Azure Function，一年后，這一數(shù)據(jù)已經增長到了 36%，而 Google 已經有 25% 的云上客戶在使用 Cloud Function 了。

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

Vercel 是一個很實用的網(wǎng)站管理和托管工具，可以快速部署網(wǎng)站、App，甚至不需要購買服務器、域名、安裝與配置 Nginx、上傳網(wǎng)站文件、添加 DNS 解析項、配置網(wǎng)頁證書，最重要的是個人使用是永久免費。

Vercel 托管的都是一些耦合度不高的應用。很顯然， Vercel 的這一商業(yè)模式充分利用了 Serverless 技術的成本優(yōu)勢，來盡可能降低免費個人用戶帶來的服務器成本，通過函數(shù)應用來處理來自服務端渲染、API 路由等的請求。在過去的一年里，Vercel 每月的服務器調用次數(shù)從 2.62 億次增加到每月 74 億次，增長了 28 倍。

觀點四：AWS Step Functions 是 Lambda 的最佳伴侶，平均每個工作流包含 4 個函數(shù)，并逐月上升

函數(shù)應用的編排功能正在拓展函數(shù)應用的邊界

一個完整的業(yè)務邏輯通常不是一個函數(shù)應用就能完成的，需要用到多個函數(shù)應用，甚至還涉及到彈性計算、批量計算等計算單元。這時候，通過工作流的編排能力，對各個計算任務進行順序、分支、并行等方式的分布式編排，可以簡化繁瑣的業(yè)務拼接帶來的代碼工作，還能可視化監(jiān)控整個業(yè)務流程中各個執(zhí)行環(huán)節(jié)的狀態(tài)，一舉兩得。AWS Step Functions 就提供了這樣的功能。

報告顯示，平均每個 Step Functions 工作流包含 4 個 Lambda 函數(shù)，并且呈現(xiàn)逐月增長的趨勢。說明越來越的客戶正使用工作流來處理越來越復雜的業(yè)務邏輯。其中，執(zhí)行時間在 1 分鐘內的工作流占比 40%，但也不乏一些執(zhí)行時長多于 1 小時甚至超過 1 天的工作流，這些長時間執(zhí)行的工作流以 AI 建模為主。

該部分，報告中引用了 Stedi 這一案例，這家企業(yè)是在 B2B 交易的交易領域提供結構化消息發(fā)送的服務，例如營銷郵件的推送等服務，這類業(yè)務場景具備事件觸發(fā)、短時間需要調用海量目標郵箱郵箱的特點，Serverless + 工作流就可以很好的滿足了客戶在成本和開發(fā)運維效率上進行優(yōu)化的訴求。

觀點五：四分之一的 AWS CluodFront 客戶使用 Lambda @Edge

邊緣正成為 Serverless 的新市場

Lambda @ Edge 是 Amazon CloudFront 的一個功能，它可讓客戶在靠近應用程序用戶的地方運行代碼，從而提高性能，降低延遲。使用 Lambda @ Edge，客戶無需在全球多個地方預置或管理基礎設施，只需按使用的計算時間付費，代碼未運行時不產生費用。

相當于在邊緣的場景下，網(wǎng)絡將 Serverless 的計算能力一起提供給客戶，而無須從云端調用算力，提高了那些對延遲敏感的邊緣業(yè)務的客戶體驗，例如物聯(lián)網(wǎng)場景下視頻監(jiān)控和智能分析、業(yè)務監(jiān)測和分析等任務。

報告顯示，四分之一的 Amazon CloudFront 客戶使用了 Lambda@Edge，其中 67% 的客戶的函數(shù)執(zhí)行時長不到 20 毫秒，說明這部分應用對延遲非常敏感，這類的邊緣業(yè)務需求越多，Serverless 在邊緣端的潛力就越大。

觀點六：超過一半的客戶函數(shù)預留實例的資源使用率不到 80%

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

尤其是在 Java/.Net 的編程框架下，應用的啟動會更慢，因為 Java 需要初始化其虛擬機 (JVM) ，并將大量類加載到內存中，然后才能執(zhí)行用戶代碼。業(yè)內提供了很多優(yōu)化冷啟動的思路，例如提供函數(shù)預留實例，或者通過按需加載和更高效的存儲和算法來提升容器鏡像的拉取速度，從而優(yōu)化冷啟動速度。

本質上講，函數(shù)預留實例是避免冷啟動的一個見效很快的方式，但他并沒有從根本上解決冷啟動的問題，資源預留的越多，浪費的就越多，這和 Serverless 主張的按需使用是背道而馳的。因此，今年的報告非常關注客戶在函數(shù)預留實例的使用率情況。

報告顯示，57% 使用函數(shù)預留實例的客戶用了不到預留實例中 80% 的資源，其中，超過 30% 的客戶僅用了不到 40% 的資源；使用率達 80%-100% 的客戶超過 40%，那么這部分客戶應當仍然會遇到冷啟動的問題。因此，不斷優(yōu)化業(yè)務的預留實例設計仍是廠商和客戶需要共同面對的命題，相關的最佳實踐會有較高的指導意義。感興趣的朋友可以看看阿里云函數(shù)計算的這份最佳實踐。

觀點七：開源無服務器框架是部署函數(shù)應用的主要方式

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

Serverless 架構下，手動部署幾個函數(shù)應用可能不太復雜，一旦當應用擴展到幾十、幾百個的時候，應用的部署難度就會被成倍放大，此時通過一些部署工具來部署，可以提高部署效率。正如 Kubernetes 是用來自動部署、擴展和管理容器化應用程序的，在管理容器的過程，Kubernetes 已經是必不可少的工具。

報告顯示，80% 以上的客戶使用 Serverless Framework 來部署和管理函數(shù)應用，雖然報告未給出原因，但大體離不開 Serverless Framework 的易用性、開放性和社區(qū)屬性，報告預計基礎設施即代碼類的部署工具在大規(guī)模部署無服務器應用程序方面將扮演更重要的角色，AWS 自研的三個部署工具，vanilla CloudFormation、AWS CDK 和 AWS SAM 的使用率分別是 19%、18% 和 13%。（存在同一個客戶同時使用兩個或多個工具，因此使用率疊加后高于 100%）

回到國內，阿里云、百度云、華為云、騰訊云均提供了自家閉源的部署工具，騰訊云和 Serverless Framework 合作，開發(fā)了 Serverless 應用中心，阿里云則是在去年開源了 Serverless Devs，提供函數(shù)應用的部署、運維和監(jiān)控，此外，國內另一款提供 Node.js 開發(fā)態(tài)框架的開源項目 Midway，已經獲得 4k+ 的 star，相信隨著參與 Serverless 的開發(fā)者的增加，國內開源工具生態(tài)會越發(fā)活躍。

觀點八：Python 是最流行的 Lambda 運行時，尤其是在大型環(huán)境中

Serverless 天然支持多語言的開發(fā)框架。那么問題也來了，哪類編程語言最為流行呢？

報告顯示，58% 的用戶使用 Python、Node.js 則占據(jù)了 31% 的份額，Java、Go、.NET Core 和 Ruby 的份額均未超過 10%。但考慮到不同廠商各自的特點，阿里云上的 Java 份額可能會更高些，Azure 上 .NET 的客戶會更多些。

有趣的是，在小型的 Lambda 運行環(huán)境中，Node.js 的份額高于 Python，隨著函數(shù)規(guī)模的增長，Python 就越來越流行，而在企業(yè)級組織中，Python 的使用頻率是 Node.js 的 4 倍，如下圖：

雷卷在阿里云內網(wǎng)分享了報告中編程語言部分的分析：大型企業(yè)在大數(shù)據(jù)、AI 等方面，使用 Python 比較多，而且他們使用的 Lambda 量也比較大，所以在 Lambda 的數(shù)量上 Python 有絕對的優(yōu)勢；Node.js 應用用不了那么大的運行期 (多核 CPU 和大內存），通常都是小型實例，另外可能是個人的 Node.js 開發(fā)者，通常也會選擇小型的 Lambda 環(huán)境。

此外，各類編程語言的版本的使用分布如下，依次遞減，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 的使用群體在迅速擴大，函數(shù)執(zhí)行時長不斷增加，使用方式也越加成熟，開發(fā)者工具也更佳開放。在國內，Serverless 已經不在局限一些離線任務或低耦合性應用，已經有不少企業(yè)客戶將 Serverless 應用于生產環(huán)節(jié)的核心鏈路上，例如世紀聯(lián)華將交易系統(tǒng)、會員系統(tǒng)、庫存系統(tǒng)、后臺系統(tǒng)和促銷模塊等核心應用均部署在函數(shù)計算上，來減輕客戶在基礎設施上的投入；閑魚已經開始實踐對傳統(tǒng)巨型應用的 Serverless 化改造，去攻克在 Functions 之間代碼復用、對函數(shù)的依賴做統(tǒng)一升級等業(yè)內難題。應用的改造需要時間和窗口期，相信會有越來越的企業(yè)客戶選擇 Serverless 來解放雙手。