前面我們在應(yīng)用中創(chuàng)建了一個云函數(shù)，并將云函數(shù)與 Express 進(jìn)行整合，配合云數(shù)據(jù)庫寫好了增刪改查的接口，但是這樣的開發(fā)方式并不是 Serverless 的最佳食用方法。

在我們的代碼中，是將整個后端應(yīng)用的全部業(yè)務(wù)能力寫進(jìn)了一個函數(shù)中。這樣做的好處就是方便管理，畢竟在一個應(yīng)用下只有一個云函數(shù)。但是單個云函數(shù)的并發(fā)是有限的，并行的函數(shù)實例個數(shù)由云廠商決定，而超過限制后，事件隊列就需要等待其他函數(shù)實例執(zhí)行完畢后，再生成新的函數(shù)實例。

那可能就有人問了，不是說 Serverless 是彈性伸縮的嗎?不是說會根據(jù)業(yè)務(wù)處理的需求自動調(diào)配資源嘛?為什么還會有函數(shù)的并發(fā)限制呢?

要搞清楚這一點，我們需要了解 FaaS 的運行機(jī)制。

FaaS 的運行機(jī)制

在 FaaS 平臺中，函數(shù)默認(rèn)是不運行的，也不會分配任何資源，甚至 FaaS 中都不會保存函數(shù)代碼。只有當(dāng) FaaS 接收到觸發(fā)器的事件后，才會啟動并運行函數(shù)。前面我們就是使用 HTTP 的觸發(fā)器來執(zhí)行函數(shù)代碼的，整個函數(shù)的運行過程實際上可以分為四個階段：

代碼下載：FaaS 平臺本身不會存儲代碼，而是將代碼放在對象存儲中，需要執(zhí)行函數(shù)的時候，再從對象存儲中將函數(shù)代碼下載下來并解壓，因此 FaaS 平臺一般都會對代碼包的大小進(jìn)行限制，通常代碼包不能超過 50MB。

啟動容器：代碼下載完成后，F(xiàn)aaS 會根據(jù)函數(shù)的配置，啟動對應(yīng)容器，F(xiàn)aaS 使用容器進(jìn)行資源隔離。

初始化運行環(huán)境：分析代碼依賴、執(zhí)行用戶初始化邏輯、初始化入口函數(shù)之外的代碼等。

運行代碼：調(diào)用入口函數(shù)執(zhí)行代碼。

當(dāng)函數(shù)第一次執(zhí)行時，會經(jīng)過完整的四個步驟，前三個過程統(tǒng)稱為“冷啟動”，最后一步稱為“熱啟動”。

整個冷啟動流程耗時可能達(dá)到百毫秒級別。函數(shù)運行完畢后，運行環(huán)境會保留一段時間，這個時間在幾分鐘到幾十分鐘不等，這和具體云廠商有關(guān)。如果這段時間內(nèi)函數(shù)需要再次執(zhí)行，則 FaaS 平臺就會使用上一次的運行環(huán)境，這就是“執(zhí)行上下文重用”，也叫做 “實例復(fù)用”，函數(shù)的這個啟動過程也叫“熱啟動”。“熱啟動” 的耗時就完全是啟動函數(shù)的耗時了。當(dāng)一段時間內(nèi)沒有請求時，函數(shù)運行環(huán)境就會被釋放，直到下一次事件到來，再重新從冷啟動開始初始化。

考慮下面這個云函數(shù):

在第一次調(diào)用該云函數(shù)的時候，函數(shù)返回值為 1，這是符合預(yù)期的。

但如果連續(xù)調(diào)用這個云函數(shù)，其返回值有可能是從 2 遞增，也有可能變成 1，這便是實例復(fù)用的結(jié)果：

• 當(dāng)熱啟動時，執(zhí)行函數(shù)的 Node.js 進(jìn)程被復(fù)用，進(jìn)程的上下文也得到了保留，所以變量 i 自增。
• 當(dāng)冷啟動時，Node.js 進(jìn)程是全新的, 代碼會從頭完整的執(zhí)行一遍，此時返回 1。

下面是一個函數(shù)的請求示意圖，其中 “請求1” “請求3” 是冷啟動，“請求2” 是熱啟動。

函數(shù)執(zhí)行完畢后銷毀運行環(huán)境，雖然對首次函數(shù)執(zhí)行的性能有損耗，但極大提高了資源利用效率，只有需要執(zhí)行代碼的時候才初始化環(huán)境、消耗硬件資源。并且如果你的應(yīng)用請求量比較大，則大部分時候函數(shù)的執(zhí)行可能都是熱啟動。

從函數(shù)運行的生命周期中你可以發(fā)現(xiàn)，如果函數(shù)每分鐘都執(zhí)行，則函數(shù)幾乎都是熱啟動的，也就是會重復(fù)使用之前的執(zhí)行上下文。執(zhí)行上下文就包括函數(shù)的容器環(huán)境、入口函數(shù)之外的代碼。

云平臺會根據(jù)當(dāng)前負(fù)載情況，自動控制云函數(shù)實例的數(shù)量，并且均衡地分發(fā)請求。連續(xù)的多次請求有可能由同一實例處理，也可能不是。這就是我們在上面的代碼中看到的，i 的值非常放肆，根本就找不到規(guī)律。所以，我們在編寫云函數(shù)時，應(yīng)注意保證云函數(shù)是無狀態(tài)的、冪等的，即當(dāng)次云函數(shù)的執(zhí)行不依賴上一次云函數(shù)執(zhí)行過程中在運行環(huán)境中殘留的信息。

再次回到我們的 Todo 案例中，因為我們將全部的業(yè)務(wù)邏輯放到了一個云函數(shù)中，因此，處理的并發(fā)量會受到極大的限制。當(dāng)并發(fā)量達(dá)到一定的程度時，無法創(chuàng)建更多的函數(shù)實例，也就無法分配更多的服務(wù)器資源。更好的方式是對我們的業(yè)務(wù)邏輯進(jìn)行拆分，一個云函數(shù)就對應(yīng)一個獨立的業(yè)務(wù)邏輯處理。這在小程序的云開發(fā)中就有體現(xiàn)，默認(rèn)給我們的小程序云開發(fā)模板中，就是一個小程序應(yīng)用對應(yīng)對個云函數(shù)的處理方式。

那么，隨著功能和業(yè)務(wù)的增加，函數(shù)必然會越來越多，對于開發(fā)過程中的代碼管理工作，也就顯得格外重要了。而騰訊官方提供的 cloudbase-framework 工具則給我們提供了一種方式，我們前面使用的 CloudBase CLI 命令行工具，就是使用 cloudbase-framework 的對外接口工具，也就是說，我們使用的命令行，實際就是調(diào)用了 cloudbase-framework 提供的功能。

前面我們已經(jīng)使用過一些了，比如：tcb new 創(chuàng)建應(yīng)用、tcb 應(yīng)用部署、tcb service create 創(chuàng)建http 觸發(fā)器、tcb fn code update xxx 函數(shù)名增量更新代碼。

除了這些部署代碼相關(guān)的命令，framework 還給我們提供了一站式管理云平臺資源的能力。

使用 CloudBase Framework

接下來，我們按照 Serverless 的開發(fā)模式對 Todo 案例進(jìn)行重構(gòu)。在騰訊云開發(fā) CloudBase 下，已經(jīng)給我們創(chuàng)建好了各種各樣的開發(fā)的模板，使用 tcb new 這個命令就可以看到，在選擇應(yīng)用模板時，選擇 Vue 應(yīng)用，就可以創(chuàng)建一個 Vue 云開發(fā)的項目。

項目創(chuàng)建后之后，我們能看到項目路徑下有 cloudfunctions 目錄，這就是存放云函數(shù)的地方，一個函數(shù)就是一個文件夾。

那么怎么管理這些函數(shù)呢?在項目的根路徑下，有一個 cloudbaserc.json 的文件，它就是整個應(yīng)用的 framework 的配置文件，我們可以通過這個配文件來管理我們的項目應(yīng)用。所以在開始之前，我們要先來認(rèn)識一下這個配置文件中，各個配置項的含義：

version 字段：CLI 0.9.1+ 版本引入了 2.0 新版本配置文件，支持了動態(tài)變量的特性。

在 cloudbaserc.json 中聲明 "version": "2.0" 即可啟用新的特性，新版配置文件只支持JSON 格式。動態(tài)變量特性允許在cloudbaserc.json 配置文件中使用動態(tài)變量，從環(huán)境變量或其他數(shù)據(jù)源獲取動態(tài)的數(shù)據(jù)。使用 {{}} 包圍的值定義為動態(tài)變量，可以引用數(shù)據(jù)源中的值。

envId 字段：應(yīng)用 ID

$schema ：配置模板的描述信息

region：應(yīng)用所在地區(qū)

framework ：配置文件的主要配置項

framework 字段：name 屬性是應(yīng)用名字

framework.plugins：這是我們管理應(yīng)用的重點。

Framework 是支持插件機(jī)制的，提供了多種應(yīng)用框架和云資源的插件。應(yīng)用依賴哪些插件，都在plugins 參數(shù)下配置，framework 會根據(jù) plugins 的配置來管理應(yīng)用，處理應(yīng)用中的構(gòu)建、部署、開發(fā)、調(diào)試等流程，一個應(yīng)用可以使用多個插件，使用不同的自定義屬性名字進(jìn)行管理。

官方提供的插件有很多，具體可以查看：https://docs.cloudbase.net/framework/plugins/

云函數(shù)插件

首先我們對之前寫好的云函數(shù)進(jìn)行插件方式的修改：

配置完成后，修改代碼，然后進(jìn)行部署測試。

靜態(tài)網(wǎng)站插件

云函數(shù)配置好之后，回到我們的客戶端代碼中，正常的開發(fā)部署流程是： 

在云開發(fā)中，有一個靜態(tài)站點托管的服務(wù)，我們可以借助靜態(tài)網(wǎng)站插件，一鍵完成打包上線部署的全部工作，不用再手動完成了。

配置也很簡單：