Serverless中如何實現云函數冷熱啟動

本篇文章給大家分享的是有關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 函數是無狀態的，不然就會出現一些無法預測的奇怪問題。

那么什么是無狀態呢？說白了就是你的云函數不能依賴之前函數運行的狀態或者是結果，并且要盡量避免全局變量的使用！

以上就是Serverless中如何實現云函數冷熱啟動，小編相信有部分知識點可能是我們日常工作會見到或用到的。希望你能通過這篇文章學到更多知識。更多詳情敬請關注億速云行業資訊頻道。