前面我們在應用中創建了一個云函數，并將云函數與 Express 進行整合，配合云數據庫寫好了增刪改查的接口，但是這樣的開發方式并不是 Serverless 的最佳食用方法。

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

那可能就有人問了，不是說 Serverless 是彈性伸縮的嗎?不是說會根據業務處理的需求自動調配資源嘛?為什么還會有函數的并發限制呢?

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

FaaS 的運行機制

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

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

啟動容器：代碼下載完成后，FaaS 會根據函數的配置，啟動對應容器，FaaS 使用容器進行資源隔離。

初始化運行環境：分析代碼依賴、執行用戶初始化邏輯、初始化入口函數之外的代碼等。

運行代碼：調用入口函數執行代碼。

當函數第一次執行時，會經過完整的四個步驟，前三個過程統稱為“冷啟動”，最后一步稱為“熱啟動”。

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

考慮下面這個云函數:

在第一次調用該云函數的時候，函數返回值為 1，這是符合預期的。

但如果連續調用這個云函數，其返回值有可能是從 2 遞增，也有可能變成 1，這便是實例復用的結果：

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

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

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

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

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

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

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

前面我們已經使用過一些了，比如：tcb new 創建應用、tcb 應用部署、tcb service create 創建http 觸發器、tcb fn code update xxx 函數名增量更新代碼。

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

使用 CloudBase Framework

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

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

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

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

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

envId 字段：應用 ID

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

region：應用所在地區

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

framework 字段：name 屬性是應用名字

framework.plugins：這是我們管理應用的重點。

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

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

云函數插件

首先我們對之前寫好的云函數進行插件方式的修改：

配置完成后，修改代碼，然后進行部署測試。

靜態網站插件

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

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

配置也很簡單：