摘要：函式計算 FC 首創 GPU 例項、業內首發例項級別可觀測和除錯、率先提供端雲聯調和多環境部署能力、GB 級別映象

啟動時間最佳化至秒級、VPC 網路建連最佳化至200ms，Serverless 應用引擎 SAE 支援微服務框架無縫遷移、無需容器化改造、

業內首創混合彈性策略，這些創新和突破，將 Serverless 領域的技術難題給解了，徹底跨越了影響 Serverless 進一步落地

企業核心生產場景的絆腳石。

“即使雲端計算已經興起，但是大家的工作仍然是圍繞伺服器，不過，這個不會持續太久，雲應用正在朝著無伺服器的方向發

展。”

這是 Ken Form 在 2012 年的一篇《Why The Future of Software and Apps is Serverless》文章中提出的關於未來雲計

算的觀點。

Serverless First：從雲廠商主張到客戶主見

Serverless 與身俱來的彈效能力和容錯能力，很好的契合了企業線上業務的彈性和穩定性的雙重訴求，成為企業雲上架構演

進的新方向。

時至今日，隨著越來越多的大中型企業將傳統後端領域對擴容有靈活需求的執行單元剝離出來，執行在 Serverless 架構上，

以及更注重研發和交付效率的創業團隊將業務全部 Serverless 化，Serverless First 的理念更加深入人心，使得越來越多的

雲上工作負載執行在無伺服器上。

數字上的變化代表了技術的市場成熟度。

根據 Datadog 今年的一份報告，Datadog 上一半的 AWS 客戶使用了 Lambda，80% 的 AWS 容器客戶使用了 Lambda，

而且這些使用者每天呼叫函式的次數是兩年前的 3.5 倍，執行時長達 900 小時/天。再看看國內的市場，根據 CNCF 今年釋出

的《2020中國雲原生調查報告》，31%  的企業正在生產中使用 Serverless 技術，41%  正在評估選型，12% 計劃在未來 

12 個月內使用。

10月21日，雲棲大會雲原生峰會現場，阿里雲 Serverless 重磅釋出了一系列技術突破，集中解決了行業面臨的難點和痛點。

隨之而來的是各大企業在 Serverless 上的大規模實踐，例如網易雲音樂使用 Serverless 技術構建離線音影片處理平臺、南

瓜電影7天全面 Serverless 化，並基於此，建立了業務的監控、釋出和彈性系統。

從 First 到 Faster，FC 7大技術突破，跨越影響 Serverless 

發展的絆腳石

Serverless 的本質是透過遮蔽底層的計算資源，來實現業務層開發的專注度和自由度。但越是往上抽象，雲廠商在底層的實

現就越是複雜。函式計算將服務進一步拆分到函式的顆粒度，這勢必會給開發、運維、交付等帶來新的挑戰，例如如何對函

數進行端雲聯調、如何對函式進行可觀測和除錯、如何最佳化 GB 級別的映象冷啟動？這些以往在服務的顆粒度時，都不是問

題的事情，成了 Serverless 大規模落地企業核心生產業務的絆腳石。

阿里雲函式計算團隊自去年進入 Forrester 領導者象限後，繼續攻克業內的這些技術難題，並在此次雲棲大會重磅釋出了7大

技術創新和突破。

 Serverless Devs 2.0：業內首發 Desktop，支援端雲聯

調、多環境部署

開源近一年， Serverless 開發者平臺 Serverless Devs 2.0 版本正式釋出。相比 1.0 ，2.0在效能、使用體驗實現全方位提

升，業內首發桌面客戶端 Serverless Desktop，對桌面客戶端進行了精細設計兼具美感和實用主義，具備更強的企業級服務

能力。

作為業內首個支援主流 Serverless 服務/框架的雲原生全生命週期管理的平臺，Serverless Devs 致力於為開發者打造 

Serverless 應用開發一站式服務，Serverless Devs 2.0 提出多模式除錯方案，包括打通線上線下環境；本地對接線上環境並

進行除錯的端雲聯調方案、本地直接進行開發態除錯的本地除錯方案、以及雲端運維態除錯的線上除錯/遠端除錯方案等。

新版本增加多環境部署部署能力，Serverless Devs 2.0 已支援一鍵部署框架 30 餘種，包括 Django，Express，Koa，Egg，

Flask，Zblog，Wordpress 等。

業內首發例項級別可觀測和除錯

例項是函式資源最小的可被排程的原子單位，類比容器的 Pod。Serverless 將異構基礎資源高度抽象，因此“黑盒問題”

是 Serverless 大規模普及的核心落地之痛。業內同類產品均沒有透出“例項”概念，也從未在可觀測功能中將 CPU、內

存等指標透出，但可觀測就是開發者的眼睛，沒有可觀測，何談高可用呢？

函式計算重磅釋出例項級別可觀測能力，對函式例項進行實時監控和效能資料採集，並進行視覺化展示，為開發者提供函

數例項端到端的監控排查路徑。透過例項級別指標，您可以檢視 CPU 和記憶體使用情況、例項網路情況和例項內請求數等核

心指標資訊，讓“黑盒”不黑。同時，函式計算將透過開放部分例項登入許可權，做到既能觀測，還能除錯。

業內首發固定數量、定時、水位自動伸縮的例項預留策略

函式計算冷啟動受到多個因素影響：程式碼和映象大小、啟動容器、語言執行時初始化、程式初始化、執行邏輯等，這依賴用

戶和雲廠商的雙向最佳化。雲廠商會自動為每個函式分配最合適的例項數量，並進行平臺側的冷啟動最佳化。但對於某些線上業

務時延非常敏感，雲廠商無法代替使用者進行更深層的業務最佳化，如對程式碼或依賴進行精簡、程式語言的選擇、程式的初始化、

演算法最佳化等。

業內同類產品普遍是採用預留固定例項數量的策略，即讓使用者配置 N 個併發值，除非手動調整，否則在分配了 N 個例項後不

會再伸或者縮。這種方案只解決了部分業務高峰期的冷啟動延時，但大大增加了運維成本和資源成本，對紅包大促等帶有不

定期峰谷的業務，其實並不友好。

因此，函式計算率先將部分例項資源的排程許可權授予使用者，允許使用者透過固定數量、定時伸縮、按水位伸縮、混合伸縮等多維度的例項預留策略，來預留適量函式例項，分別滿足業務曲線相對平穩（如AI/ML場景）、峰谷時間段明確（如遊戲互娛、線上教育、新零售等場景）、突發流量無法預估（如電商大促、廣告等場景）、業務混雜（如Web後臺、資料處理等場景）等不同場景的訴求，從而降低冷啟動對時延敏感型業務的影響，真正實現彈性和效能兼顧的終極目標。

業內率先推出 GPU 例項

函式計算提供彈性例項和效能例項兩種例項型別，彈性例項規格從 128 MB 到 3 GB，隔離粒度做到了整個雲生態最細，

能真正實現普適場景下資源利用率 100%；效能例項規格區間範圍包含4 GB、8 GB、16 GB和32 GB。資源上限更高，主

要適用於計算密集型場景，如音影片處理、AI建模和企業級Java應用等場景。

隨著專用領域硬體加速的蓬勃發展，各 GPU 廠商均推出了影片編解碼專用 ASIC，比如：英偉達從 Kepler 架構整合影片編

碼專用電路、從 Fermi 架構整合影片解碼專用電路。

函式計算正式推出了基於 Turning 架構的 GPU 例項，使得 Serverless 開發者可以將影片編解碼的 workload，下沉到 

GPU 硬體加速，從而大大加快了影片生產、影片轉碼的效率。

最高可交付 2w 例項/分鐘

所謂“無伺服器”，並不是說軟體應用不需要伺服器就可以執行了，而是指使用者無須關心軟體應用執行時，涉及的底層服務

器

的狀態、資源（比如 CPU、記憶體、磁碟及網路）和數量。軟體應用正常執行所需要的計算資源由雲端計算廠商動態提供，但

實際上，使用者還是會關心雲廠商的資源交付能力，以及應對突發流量場景下資源不足導致的訪問波動。

函式計算依託於阿里雲強大的雲基礎設施服務能力，透過神龍裸金屬資源池和 ECS 資源池雙池互備，在業務高峰期，實現

最大交付達 2w 例項/分鐘，這近一步提升了函式計算在客戶核心業務上的交付能力。

VPC 網路建連最佳化：從 10s 最佳化至 200ms

當使用者需要在函式中訪問使用者 VPC 中的資源，例如 RDS/NAS 時，需要打通 VPC 網路。業內 FaaS 產品普遍採用動態掛

載 ENI 的方式來實現 VPC 打通，即在 VPC 建立一個 ENI，掛載到 VPC 中執行函式的機器上。該方案讓使用者能非常簡單

地聯動後端雲服務，但 ENI 掛載的速度一般需要10秒以上，在延時敏感業務場景下帶來極大的效能開銷。

函式計算透過將 VPC 閘道器服務化，實現計算和網路解耦，計算節點的伸縮不再受限於 ENI 掛載的能力。該方案由閘道器服

務負責 ENI 的掛載、閘道器節點的高可用和自動伸縮，而函式計算專注於計算節點的排程，最終實現 VPC 網路建連時，函式

冷啟動時間降至 200 ms。

GB 級別映象啟動：從分鐘級最佳化至秒級

函式計算在 2020 年 8 月率先發布了容器映象的函式部署方式，AWS Lambda 在 2020 年 12 月 Re-Invent，國內友商在

 2021 年 6 月也相繼宣佈了 FaaS 支援容器的重磅功能。冷啟動一直都是 FaaS 的痛點，引入比程式碼壓縮包大幾十倍的容器

映象後，加重了冷啟動過程帶來的時延。

函式計算創新性的發明了 Serverless Caching，根據不同的儲存服務特點，構建資料驅動、智慧高效的快取體系，實現軟

硬體協同最佳化，將 Custom Container 體驗進一步提升。到目前為止，函式計算已經將映象加速最佳化到了較高的水準。我

們在函式計算的公開用例（[]()）裡面，挑選了 4 個

典型的映象，並將它們適配至國內外幾個大型雲廠商進行橫向對比，每間隔3小時呼叫上述映象，重複數次。

實驗證明，在 GB 級別映象冷啟動的場景下，函式計算已經實現了分鐘級到秒級的跨越。

從專用到通用，從複雜到簡單，SAE 讓 All on Serverless 

成為可能

如果說 FaaS 大規模落地企業核心生產業務的難題需要透過技術攻堅來解決，以 SAE 為代表 Serverless PaaS 則將更多

的突破放在產品易用性和場景覆蓋度上。

從專用到通用，SAE 天然適合企業核心業務的大規模落地

不同於 FaaS 形態的 Serverless，SAE 以“應用為中心”，提供了面向應用的 UI 和 API，保持了伺服器和經典 PaaS 形態

下的使用體驗，即應用看得見、也摸得著，避免了 FaaS 對應用的改造和可觀測、可調式相對較弱的體驗，可以做到線上應

用的零程式碼改造和平滑遷移。

SAE 打破了 Serverless 的落地實施邊界，使得 Serverless 不再是前端全棧、小程式的專寵，後臺微服務、SaaS 服務、物

聯網應用等一樣也可以構建在 Serverless 之上，天然適合企業核心業務的大規模落地。此外，SAE 支援 PHP 、Python 等

多語言原始碼包的部署，支援多執行時環境和自定義擴充套件，真正讓 Serverless 實現專用到通用。

從複雜到簡單，SAE 天然適合企業應用快速容器化

傳統的 PaaS 被詬以使用複雜、遷移難、擴充套件麻煩，SAE 底層將虛擬化技術改造成容器技術，充分利用了容器的隔離技術，

來提升啟動時間和資源利用率，實現應用等快速容器化，而在應用管理層，則保留了原有的 Spring Cloud/Dubbo 等微服

務應用的管理正規化，不必動用龐大而複雜的 K8s 來管理應用。

此外，底層計算資源池化後，其天然的 Serverless 屬性使得使用者不必再單獨購買和持續保有伺服器，而是按 CPU 和記憶體資

源量來配置所需的計算資源，再加上經過多年雙 11 考驗的高階微服務治理能力，讓容器 + Serverless + PaaS 得以合三為

一，使得技術先進性、資源利用率最佳化、高效的開發運維體驗可以融合在一起。因此，讓新技術落地更加簡單、平穩。

可以說，SAE 幾乎全覆蓋了應用上雲的所有場景，既是應用上雲的最佳選擇，也是 All on Serverless 的典範。

4 大變化，Serverless 加速企業現代應用架構革新

單是技術的領先性，並無法推動行業的發展，Serverless 給企業客戶和開發者帶來的切身變化，這兩者組成了市場成熟度的

雙輪驅動，技術在自我演進，客戶在落地反哺，這是任何一項新技術得以持續發展的正確姿勢。

變化一：伺服器 vs 程式碼

創業公司的全棧工程師：“我的工作不再是圍繞冰冷枯燥的伺服器，告別了伺服器的處理時間比我寫程式碼的時間還長的窘境，

可以讓我把更多的時間放在業務上，並且用最熟悉的程式碼來保障應用的穩定執行。”

一個主攻前端方向的全棧工程師的日常可能是這樣的：掌握至少一門前端語言例如 Node.js 或者 Puppeteer，會寫一些 API

 介面，再修改一些後端的bug，還要花費大量的精力在伺服器的運維上，公司的業務量越大，花在運維上的時間越多。

函式計算降低 Nodejs 等前端語言的伺服器維護門檻，只要會寫 JS 程式碼就可以維護 Node 服務，而無需學習 DevOps 相關

知識。

變化二：計算叢集 vs 計算資源池

演算法領域的 Java 工程師：“我不再擔心演算法的增多和複雜度的增高導致的伺服器規格多、採購煩雜、運維難，而是透過無

限的資源池、快速的冷啟動以及預留例項，來提升彈效能力和自由度。”

網易雲音樂已經落地了 60+ 的音影片演算法，100+ 的業務場景，用到了 1000+ 臺不同規格的雲主機和物理機。雖然透過了

很多方式去簡化了內部業務場景、演算法等的對接，但越來越多夾雜存量、增量處理的演算法，不同流量的業務場景規模，以及

不同業務場景可能會複用同一類演算法的，導致在業務上的時間越來越少。

網易雲音樂基於函式計算升級離線音影片處理平臺，應用於聽歌、K 歌、識曲等業務場景，實現 10 倍速的業務落地，並大

幅降低了稀疏演算法的計算成本和運維成本。

變化三：負載 vs 排程

遊戲主程：“我不再擔心 SLB 的輪詢機制導致無法感知 Pod 的實際負載，由此引起的負載不均，函式計算的排程系統會合

理安排每個請求，來保證戰鬥校驗場景下的高 CPU 消耗和高彈性處理請求。”

戰鬥校驗是莉莉絲眾多戰鬥類遊戲的必備業務場景，用來驗證玩家客戶端上傳的戰鬥是否有作弊的情況。戰鬥校驗一般需

要逐幀計算，CPU 消耗會非常高，通常1隊v1隊的戰鬥需要n毫秒，而5隊v5隊的戰鬥則需要相應 5n 毫秒，對彈性要求很

高。此外，容器架構下掛載的 SLB，會因為輪詢機制導致無法感知 Pod 的實際負載，由此引起的負載不均，產生死迴圈和

穩定性風險。

函式計算的排程系統幫助莉莉絲合理安排每個請求，對於死迴圈問題，也貼心的提供了超時殺程式機制。函式計算將排程系

統的複雜性下沉到了基礎設施，廠商深度最佳化後的冷啟動時延大幅下降，從排程、到獲取計算資源、再到服務啟動，基本在

 1s+ 左右。

變化四：指令碼 vs 自動化

互娛行業運維工程師：我不再擔心傳統伺服器模式下，發版慢和易出錯、環境一致性難保證、許可權分配繁瑣和回滾麻煩的問

題，SAE 的全套服務治理能力提升開發運維效率70%，而彈性資源池則將業務端的擴容時間縮短70%。

一場熱映，南瓜電影日註冊使用者突破 80w，導致流量入口 API 閘道器撐不住，緊接著後端的所有服務都面臨了極大的穩定性

挑戰，隨後開始緊急擴容，買 ECS，上傳指令碼到伺服器，執行指令碼，擴容資料庫，整個過程耗時 4 小時。然而，因為這樣的

熱映帶來的自然爆點並不少見，這加速了南瓜電影的技術升級思考。

南瓜電影藉助 Serverless 應用引擎 SAE 7 天內全面 Severless 化，零門檻擁抱 K8s，輕鬆應對熱映電影的突發流量，相比

傳統伺服器運維模式，開發運維效率提升70%，成本下降 40%，擴容效率提升 10 倍以上。

 先行一步，志在千里

2009 年，伯克利就當時興起的雲端計算提出 6 點預測，包括服務的按需付費成為可能、物理硬體的利用率將大大提高等，在

過去的12年間，這些都已成為事實。2019 年，伯克利再次預測 Serverless 計算將會成為雲時代預設的計算正規化，並取代 

Serverful （傳統雲）計算模式。

參照雲端計算這12年的發展歷程，Serverless 正處於驗證伯克利預測的第3年，剛過四分之一。這3年間，從雲的未來的美好暢

想，到雲廠商倡導的 Serverless First 和大規模投入，再到企業使用者充分利用 Serverless 的優勢來最佳化現有架構，並客觀的

面對影響 Serverless 大規模落地企業核心業務的絆腳石，再到今天，透過技術創新和突破來化解行業共同的痛點。這不僅需

要先行一步的勇氣和魄力，更需要志在千里的使命和責任。