跨越行業絆腳石,阿里雲函式計算髮布7大技術突破

阿里雲情報局 發表於 2021-10-21

Serverless 的本質是通過遮蔽底層的計算資源,來實現業務層開發的專注度和自由度。但越是往上抽象,雲廠商在底層的實現就越是複雜。函式計算將服務進一步拆分到函式的顆粒度,這勢必會給開發、運維、交付等帶來新的挑戰,例如如何對函式進行端雲聯調、如何對函式進行可觀測和除錯、如何優化 GB 級別的映象冷啟動?這些以往在服務的顆粒度時,都不是問題的事情,成了 Serverless 大規模落地企業核心生產業務的絆腳石。

2021 雲棲大會現場,阿里巴巴研究員、阿里雲智慧雲原生應用平臺總經理丁宇(叔同)重磅釋出了函式計算的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 級別映象冷啟動的場景下,函式計算已經實現了分鐘級到秒級的跨越。

先行一步,志在千里

2009 年,伯克利就當時興起的雲端計算提出6點預測,包括服務的按需付費成為可能、物理硬體的利用率將大大提高等,在過去的12年間,這些都已成為事實。2019年,伯克利再次預測 Serverless 計算將會成為雲時代預設的計算正規化,並取代 Serverful (傳統雲)計算模式。

參照雲端計算這12年的發展歷程,Serverless 正處於驗證伯克利預測的第3年,剛過四分之一。這3年間,從雲的未來的美好暢想,到雲廠商倡導的 Serverless First 和大規模投入,再到企業使用者充分利用 Serverless 的優勢來優化現有架構,並客觀的面對影響 Serverless 大規模落地企業核心業務的絆腳石,再到今天,通過技術創新和突破來化解行業共同的痛點。這不僅需要先行一步的勇氣和魄力,更需要志在千里的使命和責任。

 


來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/69986074/viewspace-2838629/,如需轉載,請註明出處,否則將追究法律責任。