為滿足不同情境下的使用者需求,Function Compute提供事件函數、Web函數、任務函數和GPU函數四種函數類型。針對不同開發流程,Function Compute提供內建運行、自訂運行時和自訂鏡像三種運行時環境。根據不同業務的資源使用率高低和使用者對付費模式的預期差別,Function Compute針對CPU函數僅提供彈性執行個體,針對GPU函數提供彈性執行個體、常駐執行個體和常駐執行個體+彈性執行個體(混合模式)三種執行個體類型。本文將介紹Function Compute提供的功能特性及其適用情境,協助您進行技術選型。
選型概述
使用Function Compute時,您可以根據業務情境和技術棧偏好,選擇合適的函數類型和運行環境,並結合執行個體使用類型最佳化效能和成本。
Web應用和API服務:推薦使用Web函數結合自定义运行时,該函數支援多種流行的Web應用程式框架,可以通過瀏覽器訪問,或由URL直接調用。
檔案處理和資料流處理:推薦使用事件函數結合内置运行时。您可以配置事件觸發,整合多種阿里雲產品(如Object Storage Service、雲訊息佇列 RocketMQ 版、Log ServiceSLS等)。
Chatbot和文生圖等AI推理情境:推薦使用GPU函數結合自定义镜像,基於流行AI專案(如ComfyUI、RAG、TensorRT等)的容器鏡像,快速構建AI模型推理服務。
非同步任務:推薦使用任務函數結合内置运行时,處理定時任務、音視頻轉碼等情境。
内置运行时和自定义运行时都以程式碼封裝形式部署至函數,適合輕量級應用。
容器化部署,需選擇自定义镜像,GPU 函数僅支援使用自定义镜像。
函數類型選型
對比項 | 事件函数 | Web 函数 | 任务函数 | GPU 函数 |
功能 | 支援流行的Web應用程式框架,可以通過瀏覽器訪問,或通過URL調用。 | 用於處理非同步請求,能夠追蹤並儲存非同步呼叫各個階段的狀態。 | 支援流行AI專案(如Stable Diffusion WebUI、ComfyUI、RAG、TensorRT)的容器鏡像,快速構建AI模型推理服務。 | |
適用情境 |
|
|
|
|
運行時環境 | 推薦使用內建運行時 | 推薦使用自訂運行時 | 推薦使用內建運行時 | 僅支援自訂鏡像 |
預設關閉 | 預設關閉 | 預設開啟 | 預設關閉 |
運行時環境選型
對比項 | 內建運行時 | 自訂運行時 | 自訂鏡像 |
開發流程 | 按照Function Compute定義的介面編寫請求處理常式。 | 基於Web應用程式框架模板開發應用,通過公網訪問地址即時看到結果。 | 將自訂鏡像上傳至ACR然後使用鏡像,或者使用ACR中已有的鏡像。 |
支援的執行個體類型 | CPU執行個體 | CPU執行個體 | CPU執行個體和GPU執行個體 |
不支援 | 支援 | 支援 | |
最快。程式碼封裝中不包含運行時,冷啟動最快。 | 較快。程式碼封裝為HTTP Server,體積較大但無需拉取鏡像,因此冷啟動較快。 | 較慢。需要拉取鏡像,冷啟動較慢。 | |
代碼交付物格式 | ZIP、JAR(Java)、檔案夾 | 容器鏡像 | |
部分地區(如杭州)最大500 MB,其他地區最大100MB。 說明 您可以配置層添加依賴,以減少程式碼封裝體積。 |
說明 對於AI推理應用,您可以將大尺寸模型儲存在NAS或OSS,以減少鏡像體積。 | ||
支援的程式設計語言 | Node.js、Python、PHP、Java、C#、Go | 無限制 | 無限制 |
執行個體類型選型
針對CPU函數,僅支援彈性執行個體。針對GPU函數,您可以根據業務資源使用率、對延時敏感程度和對費用的穩定性要求,選擇適合的執行個體類型,支援在三種執行個體類型之間進行無損切換。
僅支援為Ada、Ada.2、Ada.3、Hopper和Xpu.1系列卡型的GPU函數綁定常駐執行個體。
彈性執行個體
如果設定函數的最小執行個體數為0,將按請求量自動Auto Scaling,無請求後執行個體自動回收,即按使用量計費,不使用不收費,能夠做到最大程度降本。業務請求越頻繁,資源使用率越高,相對虛擬機器彈性的降本幅度越高。
是否存在冷啟動
是。針對時延敏感業務,為瞭解決冷啟動問題,可以設定最小執行個體數≥1,提前鎖定彈性資源,當請求到達時,迅速喚醒執行個體執行請求。
計費說明(後付費)
函數的使用費用由彈性執行個體(活躍)和彈性執行個體(淺休眠(原閑置))費用構成,如果設定最小執行個體數≥1,建議開啟淺休眠(原閑置)模式開關。彈性執行個體(淺休眠(原閑置))狀態下vCPU資源使用不收費,GPU資源使用僅收1/5費用,使用費用遠遠小於彈性執行個體(活躍)狀態的費用。
關於彈性執行個體(活躍)和彈性執行個體(淺休眠(原閑置))的情境劃分,請參見彈性執行個體。
常駐執行個體
僅適用於GPU函數。使用者需提前購買常駐資源集區,然後基於常駐資源集區為指定函數分配指定數量和卡型的常駐執行個體,從而實現使用成本的可控與固定。適用於業務資源使用率高、時延要求高或對費用穩定性有較高要求的情境。
按月購買常駐資源集區後,在預付費常駐執行個體的額度基礎上,平台會分配一定額度的boost執行個體額度,boost執行個體額度不計費。
是否存在冷啟動
否。使用常駐執行個體時,函數最多可以同時處理的請求數=被分配的常駐執行個體數×執行個體並發數+boost額度的,超出的請求將被流控,而未超出的請求,可以實現即時響應,徹底消除冷啟動。
計費說明(預付費)
函數費用包括已購買的所有常駐資源集區的預付費費用,boost執行個體額度不計費。
常駐執行個體+彈性執行個體(混合模式)
僅適用於GPU函數。結合了常駐執行個體和彈性執行個體的優勢,適用於業務流量有明顯峰穀波動的情境。系統優先使用常駐資源集區承載穩態流量,當請求量超過常駐資源集區的承載上限時,自動觸發彈性執行個體擴充,從而在保證保底容量穩定性的同時,有效應對突發流量。
是否存在冷啟動
部分存在。在常駐資源集區(最小執行個體數)覆蓋的容量範圍內,請求實現即時響應,無冷啟動;當流量觸發彈性擴充並彈出新執行個體時,彈出的彈性執行個體部分存在冷啟動。
計費說明
混合模式的費用由預付費和後付費兩部分組成:
常駐部分:通過已購買的常駐資源集區額度進行抵扣。
彈性部分:超出常駐資源集區額度後自動彈出的執行個體按照後付費模式,和彈性執行個體活躍、淺休眠(原閑置)費用保持一致。