函數(shù)計算 FC 首創(chuàng) GPU 實例、業(yè)內(nèi)首發(fā)實例級別可觀測和調(diào)試、率先提供端云聯(lián)調(diào)和多環(huán)境部署能力、GB 級別鏡像啟動時間優(yōu)化至秒級、VPC 網(wǎng)絡建連優(yōu)化至200ms，Serverless 應用引擎 SAE 支持微服務框架無縫遷移、無需容器化改造、業(yè)內(nèi)首創(chuàng)混合彈性策略，這些創(chuàng)新和突破，將 Serverless 領域的技術難題給解了，徹底跨越了影響 Serverless 進一步落地企業(yè)核心生產(chǎn)場景的絆腳石。
“即使云計算已經(jīng)興起，但是大家的工作仍然是圍繞服務器，不過，這個不會持續(xù)太久，云應用正在朝著無服務器的方向發(fā)展。”
這是 Ken Form 在2012年的一篇《Why The Future of Software and Apps is Serverless》文章中提出的關于未來云計算的觀點。
Serverless 與身俱來的彈性能力和容錯能力，很好的契合了企業(yè)在線業(yè)務的彈性和穩(wěn)定性的雙重訴求，成為企業(yè)云上架構演進的新方向。
時至今日，隨著越來越多的大中型企業(yè)將傳統(tǒng)后端領域?qū)U容有靈活需求的執(zhí)行單元剝離出來，運行在 Serverless 架構上，以及更注重研發(fā)和交付效率的創(chuàng)業(yè)團隊將業(yè)務全部 Serverless 化，Serverless First 的理念更加深入人心，使得越來越多的云上工作負載運行在無服務器上。
數(shù)字上的變化代表了技術的市場成熟度。
根據(jù) Datadog 今年的一份報告，Datadog 上一半的 AWS 客戶使用了 Lambda，80% 的 AWS 容器客戶使用了 Lambda，而且這些用戶每天調(diào)用函數(shù)的次數(shù)是兩年前的 3.5 倍，運行時長達900 小時/天。再看看國內(nèi)的市場，根據(jù) CNCF 今年發(fā)布的《2020中國云原生調(diào)查報告》，31% 的企業(yè)正在生產(chǎn)中使用 Serverless 技術，41% 正在評估選型，12% 計劃在未來 12 個月內(nèi)使用。
10 月 21 日，云棲大會云原生峰會現(xiàn)場，阿里云 Serverless 重磅發(fā)布了一系列技術突破，集中解決了行業(yè)面臨的難點和痛點。隨之而來的是各大企業(yè)在 Serverless 上的大規(guī)模實踐，例如網(wǎng)易云音樂使用 Serverless 技術構建離線音視頻處理平臺、南瓜電影7天全面 Serverless 化，并基于此，建立了業(yè)務的監(jiān)控、發(fā)布和彈性系統(tǒng)。
Serverless 的本質(zhì)是通過屏蔽底層的計算資源，來實現(xiàn)業(yè)務層開發(fā)的專注度和自由度。但越是往上抽象，云廠商在底層的實現(xiàn)就越是復雜。函數(shù)計算將服務進一步拆分到函數(shù)的顆粒度，這勢必會給開發(fā)、運維、交付等帶來新的挑戰(zhàn)，例如如何對函數(shù)進行端云聯(lián)調(diào)、如何對函數(shù)進行可觀測和調(diào)試、如何優(yōu)化 GB 級別的鏡像冷啟動？這些以往在服務的顆粒度時，都不是問題的事情，成了 Serverless 大規(guī)模落地企業(yè)核心生產(chǎn)業(yè)務的絆腳石。
阿里云函數(shù)計算團隊自去年進入 Forrester 領導者象限后，繼續(xù)攻克業(yè)內(nèi)的這些技術難題，并在此次云棲大會重磅發(fā)布了 7 大技術創(chuàng)新和突破。
開源近一年， Serverless 開發(fā)者平臺 Serverless Devs 2.0 版本正式發(fā)布。相比 1.0 ，2.0 在性能、使用體驗實現(xiàn)全方位提升，業(yè)內(nèi)首發(fā)桌面客戶端 Serverless Desktop，對桌面客戶端進行了精細設計兼具美感和實用主義，具備更強的企業(yè)級服務能力。
作為業(yè)內(nèi)首個支持主流 Serverless 服務/框架的云原生全生命周期管理的平臺，Serverless Devs 致力于為開發(fā)者打造 Serverless 應用開發(fā)一站式服務，Serverless Devs 2.0 提出多模式調(diào)試方案，包括打通線上線下環(huán)境；本地對接線上環(huán)境并進行調(diào)試的端云聯(lián)調(diào)方案、本地直接進行開發(fā)態(tài)調(diào)試的本地調(diào)試方案、以及云端運維態(tài)調(diào)試的在線調(diào)試/遠程調(diào)試方案等。新版本增加多環(huán)境部署部署能力，Serverless Devs 2.0 已支持一鍵部署框架 30 余種，包括 Django，Express，Koa，Egg，F(xiàn)lask，Zblog，Wordpress 等。
實例是函數(shù)資源最小的可被調(diào)度的原子單位，類比容器的 Pod。Serverless 將異構基礎資源高度抽象，因此“黑盒問題”是 Serverless 大規(guī)模普及的核心落地之痛。業(yè)內(nèi)同類產(chǎn)品均沒有透出“實例”概念，也從未在可觀測功能中將 CPU、內(nèi)存等指標透出，但可觀測就是開發(fā)者的眼睛，沒有可觀測，何談高可用呢？
函數(shù)計算重磅發(fā)布實例級別可觀測能力，對函數(shù)實例進行實時監(jiān)控和性能數(shù)據(jù)采集，并進行可視化展示，為開發(fā)者提供函數(shù)實例端到端的監(jiān)控排查路徑。通過實例級別指標，您可以查看 CPU 和內(nèi)存使用情況、實例網(wǎng)絡情況和實例內(nèi)請求數(shù)等核心指標信息，讓“黑盒”不黑。同時，函數(shù)計算將通過開放部分實例登錄權限，做到既能觀測，還能調(diào)試。
函數(shù)計算冷啟動受到多個因素影響：代碼和鏡像大小、啟動容器、語言運行時初始化、進程初始化、執(zhí)行邏輯等，這依賴用戶和云廠商的雙向優(yōu)化。云廠商會自動為每個函數(shù)分配最合適的實例數(shù)量，并進行平臺側的冷啟動優(yōu)化。但對于某些在線業(yè)務時延非常敏感，云廠商無法代替用戶進行更深層的業(yè)務優(yōu)化，如對代碼或依賴進行精簡、編程語言的選擇、進程的初始化、算法優(yōu)化等。
業(yè)內(nèi)同類產(chǎn)品普遍是采用預留固定實例數(shù)量的策略，即讓用戶配置 N 個并發(fā)值，除非手動調(diào)整，否則在分配了 N 個實例后不會再伸或者縮。這種方案只解決了部分業(yè)務高峰期的冷啟動延時，但大大增加了運維成本和資源成本，對紅包大促等帶有不定期峰谷的業(yè)務，其實并不友好。
因此，函數(shù)計算率先將部分實例資源的調(diào)度權限授予用戶，允許用戶通過固定數(shù)量、定時伸縮、按水位伸縮、混合伸縮等多維度的實例預留策略，來預留適量函數(shù)實例，分別滿足業(yè)務曲線相對平穩(wěn)（如 AI/ML 場景）、峰谷時間段明確（如游戲互娛、在線教育、新零售等場景）、突發(fā)流量無法預估（如電商大促、廣告等場景）、業(yè)務混雜（如Web后臺、數(shù)據(jù)處理等場景）等不同場景的訴求，從而降低冷啟動對時延敏感型業(yè)務的影響，真正實現(xiàn)彈性和性能兼顧的終極目標。
函數(shù)計算提供彈性實例和性能實例兩種實例類型，彈性實例規(guī)格從 128 MB 到 3 GB，隔離粒度做到了整個云生態(tài)最細，能真正實現(xiàn)普適場景下資源利用率 100%；性能實例規(guī)格區(qū)間范圍包含4 GB、8 GB、16 GB和32 GB。資源上限更高，主要適用于計算密集型場景，如音視頻處理、AI建模和企業(yè)級Java應用等場景。
隨著專用領域硬件加速的蓬勃發(fā)展，各 GPU 廠商均推出了視頻編解碼專用 ASIC，比如：英偉達從 Kepler 架構集成視頻編碼專用電路、從 Fermi 架構集成視頻解碼專用電路。
函數(shù)計算正式推出了基于 Turning 架構的 GPU 實例，使得 Serverless 開發(fā)者可以將視頻編解碼的 workload，下沉到 GPU 硬件加速，從而大大加快了視頻生產(chǎn)、視頻轉碼的效率。
所謂“無服務器”，并不是說軟件應用不需要服務器就可以運行了，而是指用戶無須關心軟件應用運行時，涉及的底層服務器的狀態(tài)、資源（比如 CPU、內(nèi)存、磁盤及網(wǎng)絡）和數(shù)量。軟件應用正常運行所需要的計算資源由云計算廠商動態(tài)提供，但實際上，用戶還是會關心云廠商的資源交付能力，以及應對突發(fā)流量場景下資源不足導致的訪問波動。
函數(shù)計算依托于阿里云強大的云基礎設施服務能力，通過神龍裸金屬資源池和 ECS 資源池雙池互備，在業(yè)務高峰期，實現(xiàn)最大交付達 2w 實例/分鐘，這近一步提升了函數(shù)計算在客戶核心業(yè)務上的交付能力。
當用戶需要在函數(shù)中訪問用戶 VPC 中的資源，例如 RDS/NAS 時，需要打通 VPC 網(wǎng)絡。業(yè)內(nèi) FaaS 產(chǎn)品普遍采用動態(tài)掛載 ENI 的方式來實現(xiàn) VPC 打通，即在 VPC 創(chuàng)建一個 ENI，掛載到 VPC 中執(zhí)行函數(shù)的機器上。該方案讓用戶能非常簡單地聯(lián)動后端云服務，但 ENI 掛載的速度一般需要10秒以上，在延時敏感業(yè)務場景下帶來極大的性能開銷。
函數(shù)計算通過將 VPC 網(wǎng)關服務化，實現(xiàn)計算和網(wǎng)絡解耦，計算節(jié)點的伸縮不再受限于 ENI 掛載的能力。該方案由網(wǎng)關服務負責 ENI 的掛載、網(wǎng)關節(jié)點的高可用和自動伸縮，而函數(shù)計算專注于計算節(jié)點的調(diào)度，最終實現(xiàn) VPC 網(wǎng)絡建連時，函數(shù)冷啟動時間降至 200 ms。
函數(shù)計算在2020年8月率先發(fā)布了容器鏡像的函數(shù)部署方式，AWS Lambda 在2020年12月Re-Invent，國內(nèi)友商在2021年6月也相繼宣布了 FaaS 支持容器的重磅功能。冷啟動一直都是 FaaS 的痛點，引入比代碼壓縮包大幾十倍的容器鏡像后，加重了冷啟動過程帶來的時延。
函數(shù)計算創(chuàng)新性的發(fā)明了 Serverless Caching，根據(jù)不同的存儲服務特點，構建數(shù)據(jù)驅(qū)動、智能高效的緩存體系，實現(xiàn)軟硬件協(xié)同優(yōu)化，將 Custom Container 體驗進一步提升。到目前為止，函數(shù)計算已經(jīng)將鏡像加速優(yōu)化到了較高的水準。我們在函數(shù)計算的公開用例（https://github.com/awesome-fc）里面，挑選了4個典型的鏡像，并將它們適配至國內(nèi)外幾個大型云廠商進行橫向?qū)Ρ?，每間隔3小時調(diào)用上述鏡像，重復數(shù)次。
實驗證明，在 GB 級別鏡像冷啟動的場景下，函數(shù)計算已經(jīng)實現(xiàn)了分鐘級到秒級的跨越。
如果說 FaaS 大規(guī)模落地企業(yè)核心生產(chǎn)業(yè)務的難題需要通過技術攻堅來解決，以 SAE 為代表 Serverless PaaS 則將更多的突破放在產(chǎn)品易用性和場景覆蓋度上。
不同于 FaaS 形態(tài)的 Serverless，SAE 以“應用為中心”，提供了面向應用的 UI 和 API，保持了服務器和經(jīng)典 PaaS 形態(tài)下的使用體驗，即應用看得見、也摸得著，避免了 FaaS 對應用的改造和可觀測、可調(diào)式相對較弱的體驗，可以做到在線應用的零代碼改造和平滑遷移。
SAE 打破了 Serverless 的落地實施邊界，使得 Serverless 不再是前端全棧、小程序的專寵，后臺微服務、SaaS服務、物聯(lián)網(wǎng)應用等一樣也可以構建在 Serverless 之上，天然適合企業(yè)核心業(yè)務的大規(guī)模落地。此外，SAE 支持 PHP 、Python 等多語言源碼包的部署，支持多運行時環(huán)境和自定義擴展，真正讓 Serverless 實現(xiàn)專用到通用。
傳統(tǒng)的 PaaS 被詬以使用復雜、遷移難、擴展麻煩，SAE 底層將虛擬化技術改造成容器技術，充分利用了容器的隔離技術，來提升啟動時間和資源利用率，實現(xiàn)應用等快速容器化，而在應用管理層，則保留了原有的 Spring Cloud/Dubbo 等微服務應用的管理范式，不必動用龐大而復雜的 K8s 來管理應用。
此外，底層計算資源池化后，其天然的 Serverless 屬性使得用戶不必再單獨購買和持續(xù)保有服務器，而是按 CPU 和內(nèi)存資源量來配置所需的計算資源，再加上經(jīng)過多年雙11考驗的高級微服務治理能力，讓容器 + Serverless + PaaS 得以合三為一，使得技術先進性、資源利用率優(yōu)化、高效的開發(fā)運維體驗可以融合在一起。因此，讓新技術落地更加簡單、平穩(wěn)。
可以說，SAE 幾乎全覆蓋了應用上云的所有場景，既是應用上云的最佳選擇，也是 All on Serverless 的典范。
單是技術的領先性，并無法推動行業(yè)的發(fā)展，Serverless 給企業(yè)客戶和開發(fā)者帶來的切身變化，這兩者組成了市場成熟度的雙輪驅(qū)動，技術在自我演進，客戶在落地反哺，這是任何一項新技術得以持續(xù)發(fā)展的正確姿勢。
創(chuàng)業(yè)公司的全棧工程師：“我的工作不再是圍繞冰冷枯燥的服務器，告別了服務器的處理時間比我寫代碼的時間還長的窘境，可以讓我把更多的時間放在業(yè)務上，并且用最熟悉的代碼來保障應用的穩(wěn)定運行?！?/p>
一個主攻前端方向的全棧工程師的日常可能是這樣的：掌握至少一門前端語言例如 Node.js 或者 Puppeteer，會寫一些 API 接口，再修改一些后端的 bug，還要花費大量的精力在服務器的運維上，公司的業(yè)務量越大，花在運維上的時間越多。
函數(shù)計算降低 Node.js 等前端語言的服務器維護門檻，只要會寫 JS 代碼就可以維護 Node 服務，而無需學習 DevOps 相關知識。
算法領域的 Java 工程師：“我不再擔心算法的增多和復雜度的增高導致的服務器規(guī)格多、采購煩雜、運維難，而是通過無限的資源池、快速的冷啟動以及預留實例，來提升彈性能力和自由度?！?/p>
網(wǎng)易云音樂已經(jīng)落地了60+的音視頻算法，100+的業(yè)務場景，用到了1000+臺不同規(guī)格的云主機和物理機。雖然通過了很多方式去簡化了內(nèi)部業(yè)務場景、算法等的對接，但越來越多夾雜存量、增量處理的算法，不同流量的業(yè)務場景規(guī)模，以及不同業(yè)務場景可能會復用同一類算法的，導致在業(yè)務上的時間越來越少。
網(wǎng)易云音樂基于函數(shù)計算升級離線音視頻處理平臺，應用于聽歌、K歌、識曲等業(yè)務場景，實現(xiàn) 10 倍速的業(yè)務落地，并大幅降低了稀疏算法的計算成本和運維成本。
游戲主程：“我不再擔心 SLB 的輪詢機制導致無法感知 Pod 的實際負載，由此引起的負載不均，函數(shù)計算的調(diào)度系統(tǒng)會合理安排每個請求，來保證戰(zhàn)斗校驗場景下的高 CPU 消耗和高彈性處理請求?！?/p>
戰(zhàn)斗校驗是莉莉絲眾多戰(zhàn)斗類游戲的必備業(yè)務場景，用來驗證玩家客戶端上傳的戰(zhàn)斗是否有作弊的情況。戰(zhàn)斗校驗一般需要逐幀計算，CPU 消耗會非常高，通常 1 隊 v 1 隊的戰(zhàn)斗需要 n 毫秒，而 5 隊 v 5 隊的戰(zhàn)斗則需要相應 5n 毫秒，對彈性要求很高。此外，容器架構下掛載的 SLB，會因為輪詢機制導致無法感知 Pod 的實際負載，由此引起的負載不均，產(chǎn)生死循環(huán)和穩(wěn)定性風險。
函數(shù)計算的調(diào)度系統(tǒng)幫助莉莉絲合理安排每個請求，對于死循環(huán)問題，也貼心的提供了超時殺進程機制。函數(shù)計算將調(diào)度系統(tǒng)的復雜性下沉到了基礎設施，廠商深度優(yōu)化后的冷啟動時延大幅下降，從調(diào)度、到獲取計算資源、再到服務啟動，基本在 1 秒+左右。
互娛行業(yè)運維工程師：我不再擔心傳統(tǒng)服務器模式下，發(fā)版慢和易出錯、環(huán)境一致性難保證、權限分配繁瑣和回滾麻煩的問題，SAE 的全套服務治理能力提升開發(fā)運維效率 70%，而彈性資源池則將業(yè)務端的擴容時間縮短 70%。
一場熱映，南瓜電影日注冊用戶突破 80w，導致流量入口 API 網(wǎng)關撐不住，緊接著后端的所有服務都面臨了極大的穩(wěn)定性挑戰(zhàn)，隨后開始緊急擴容，買 ECS，上傳腳本到服務器，運行腳本，擴容數(shù)據(jù)庫，整個過程耗時 4 小時。然而，因為這樣的熱映帶來的自然爆點并不少見，這加速了南瓜電影的技術升級思考。
南瓜電影借助 Serverless 應用引擎 SAE 7天內(nèi)全面 Severless 化，零門檻擁抱 K8s，輕松應對熱映電影的突發(fā)流量，相比傳統(tǒng)服務器運維模式，開發(fā)運維效率提升 70%，成本下降 40%，擴容效率提升 10 倍以上。
2009 年，伯克利就當時興起的云計算提出 6 點預測，包括服務的按需付費成為可能、物理硬件的利用率將大大提高等，在過去的 12 年間，這些都已成為事實。2019 年，伯克利再次預測 Serverless 計算將會成為云時代默認的計算范式，并取代 Serverful （傳統(tǒng)云）計算模式。
參照云計算這 12 年的發(fā)展歷程，Serverless 正處于驗證伯克利預測的第 3 年，剛過四分之一。這 3 年間，從云的未來的美好暢想，到云廠商倡導的 Serverless First 和大規(guī)模投入，再到企業(yè)用戶充分利用 Serverless 的優(yōu)勢來優(yōu)化現(xiàn)有架構，并客觀的面對影響 Serverless 大規(guī)模落地企業(yè)核心業(yè)務的絆腳石，再到今天，通過技術創(chuàng)新和突破來化解行業(yè)共同的痛點。這不僅需要先行一步的勇氣和魄力，更需要志在千里的使命和責任。
阿里云
專欄
閩公網(wǎng)安備 35010202001226號
