本文帶大家來了解一下云函式的冷熱啟動程序,以及面對云函式這種冷熱啟動模式,開發者需要注意哪些問題,
本文來自 Serverless 社區用戶「乂乂又又」投稿
效果展示
云函式被第一次呼叫(冷啟動)

云函式被多次連續呼叫(熱啟動)

云函式的冷、熱啟動模式
先跟大家講下這里的云函式冷熱啟動模式是什么意思,
- 冷啟動是指你在服務器中新開辟一塊空間供一個函式實體運行,這個程序有點像你把這個函式放到虛擬機里去運行,每次運行前都要先啟動虛擬機加載這個函式,這是比較耗時的一個程序,所以云函式需要盡量減少自身冷啟動的次數,
- 熱啟動則是說如果一個云函式被持續觸發,那我就先不釋放這個云函式實體,下次請求仍然由之前已經創建了的云函式實體來運行,就好比我們打開虛擬機運行完這個函式之后沒有關閉虛擬機,而是讓它待機,等待下一次被重新觸發呼叫運行,這樣做的好處就是省去了給虛擬機「開機」的一個耗時環節,缺點是要一直維持這個虛擬機的激活狀態,系統開銷會大一些,
當然這里的云函式資源分配的問題并不需要我們操心,云函式的底層會通過演算法自行調配,
在騰訊云云函式檔案里的簡介 里有這么一段描述:
騰訊云云函式是騰訊云提供的 Serverless 執行環境,您只需撰寫簡單的、目的單一的云函式即可將它與您的騰訊云基礎設施及其他云服務產生的事件關聯,
使用云函式時,您只需使用平臺支持的語言(Python、Node.js、PHP、Golang 及 Java)撰寫代碼,騰訊云將完全管理底層計算資源,包括服務器 CPU、記憶體、網路和其他配置/資源維護、代碼部署、彈性伸縮、負載均衡、安全升級、資源運行情況監控等,但這也意味著您無法登錄或管理服務器、無法自定義系統和環境,
云函式自動地在同一地域內的多個可用區部署,同時提供極高的容錯性,云函式在執行時將根據請求負載擴縮容,從每天幾個請求到每秒數千個請求,都由云函式底層自行伸縮,您無需人工配置和介入,只需為運行中的云函式付費,即可滿足不同情景下服務的可用性和穩定性,若云函式未運行,則不產生任何費用,
您可以自定義運行云函式的時機,例如,在 COS Bucket 上傳時、洗掉檔案時運行云函式、應用程式通過 SDK 呼叫時運行云函式,或指定云函式定期執行,您可以使用云函式作為 COS 服務的資料處理觸發程式輕松實作 IFTTT 邏輯,您也可以通過構建靈活的定時自動化任務,用于覆寫手工完成的操作,輕松構建靈活可控的軟體架構,
大家注意這一句
云函式在執行時將根據請求負載擴縮容,從每天幾個請求到每秒數千個請求,都由云函式底層自行伸縮,
可以看到云函式的函式實體個數在系統底層是通過演算法自行伸縮的,
我們再往下看
在 Serverless 2.0 中,我們不僅在控制流和資料流的模塊、虛擬化層、網路層、調度層都做了徹底的重構優化,還在安全性、可用性以及性能方面也進行了全面升級,通過采用輕量級虛擬化技術、VPC Proxy 轉發方案等多種優化手段使用統一的底層架構,針對實時自動擴縮容核心的能力進行優化,徹底規避了傳統無服務器架構中飽受詬病的冷啟動問題,
云函式不再限制運行時長,支持更豐富的應用場景,例如:
服務型函式不限制單次請求的時長,當請求持續到來時,服務會保持一個長運行的模式,無溫、冷啟動時延,
服務型函式支持 WebSocket 長連接,
Event Function(觸發器函式)具備單次呼叫時長限制,但在請求持續到來時,服務是保持長運行模式,并無溫、冷啟動時延,
注意這句:
觸發器函式具備單次呼叫時長限制,但在請求持續到來時,服務是保持長運行模式,并無溫、冷啟動時延,
也就是說我們通過各種方式來觸發的云函式實體,并不都是完全冷啟動的,也有可能是之前呼叫的云函式的實體,
下面我們一起來做一個實驗
import json
global_v=1
# api網關回復訊息格式化
def apiReply(reply, code=200):
return {
"isBase64Encoded": False,
"statusCode": code,
"headers": {'Content-Type': 'application/json', "Access-Control-Allow-Origin": "*"},
"body": json.dumps(reply, ensure_ascii=False)
}
def main_handler(event, context):
global global_v
global_v+=1
return apiReply({
'ok': True,
'message': global_v-1
})
上面是一個簡單的 python 云函式,我們給它添加一個 API 網關觸發器來試驗一下它會回傳什么結果:
- 第一次呼叫,回傳了1,說明我們的云函式被冷啟動了

- 繼續呼叫,發現這次回傳了2,說明我們的云函式是在上一個實體的基礎上被熱啟動的:

再試幾次我們發現有的是被熱啟動,有的依然是被冷啟動:



但是這種表現顯然是與我們的預期不符的,我們期望前面的請求是不會影響到后面云函式運行結果的,這就是問題所在,
好,我們現在再去看一下官方檔案是怎么說的
SCF 是否會重復使用函式實體?
為了提高性能,SCF 會在一定時間內保留您的函式實體,將其再用于服務后續請求,但您的代碼不應假設此操作總是發生,
為何要保持 SCF 函式無狀態?
保持函式的無狀態性可使函式按需要盡可能多地啟動多個實體,從而滿足請求的速率,
也就是說,我們在編輯云函式時一定要保證 SCF 函式是無狀態的,不然就會出現一些無法預測的奇怪問題,
那么什么是無狀態呢?說白了就是你的云函式不能依賴之前函式運行的狀態或者是結果,并且要盡量避免全域變數的使用!
因為就像我們之前實驗中那樣,全域變數的值會在云函式的冷熱啟動程序中變得無法預測,這在我們后續的函式調測程序中,無疑是一場災難~
更多關于騰訊云云函式 SCF 使用的常見問題,可參考官方檔案
Serverless Framework 30 天試用計劃
我們誠邀您來體驗最便捷的 Serverless 開發和部署方式,在試用期內,相關聯的產品及服務均提供免費資源和專業的技術支持,幫助您的業務快速、便捷地實作 Serverless!
詳情可查閱:Serverless Framework 試用計劃
One More Thing
3 秒你能做什么?喝一口水,看一封郵件,還是 —— 部署一個完整的 Serverless 應用?
復制鏈接至 PC 瀏覽器訪問:https://serverless.cloud.tencent.com/deploy/express
3 秒極速部署,立即體驗史上最快的 Serverless HTTP 實戰開發!
傳送門:
- GitHub: github.com/serverless
- 官網:serverless.com
歡迎訪問:Serverless 中文網,您可以在 最佳實踐 里體驗更多關于 Serverless 應用的開發!
推薦閱讀:《Serverless 架構:從原理、設計到專案實戰》
轉載請註明出處,本文鏈接:https://www.uj5u.com/qita/3904.html
標籤:其他
