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

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

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

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

FaaS 的運(yùn)行機(jī)制

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

前面我們已經(jīng)使用過(guò)一些了，比如：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 還給我們提供了一站式管理云平臺(tái)資源的能力。

使用 CloudBase Framework

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

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

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

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

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

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

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

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

framework ：配置文件的主要配置項(xiàng)

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

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

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

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

云函數(shù)插件

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

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

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

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

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

配置也很簡(jiǎn)單：