以下內容來自「騰訊雲 Serverless Web Function」徵稿活動的使用者原創稿，已獲得授權。
01。 前言
最近騰訊雲 SCF 雲函式 ， 公測了 Web 函式 ，這種函式型別專注於 Serverless Web 服務場景。
相比於原先的事件 （Event） 函式 ， Web 函式轉換鏈路短，效能損耗也較低。
原先 Even t函式：ApI 閘道器 HTTP 請求轉換成 SCF 函式事件，事件再在 SCF 內部轉化成 HTTP 請求交給 Web 框架處理；
現在 Web 函式：在 API 閘道器那裡，直接把 HTTP 請求透傳了。函式可以直接透過 HTTP 請求觸發，這造就了它在 Web 場景的天然的優勢。
在此，筆者針對
相同程式碼
的
Event 函式
，
Web 函式
， 部署了
8
個用例，不斷提升併發量進行壓力測試，以探究不同的函式型別和 Runtime 對
QPS
，
TPS
，
Latency
的影響。
02。 測試用例
[event-node10]
： 使用
serverless express
部署的一個
node10。15
event 型別 SCF；
[event-node12]
： 使用
serverless express
部署的一個
node12。16
event 型別 SCF；
[web-node10]
： 使用
serverless scf
部署的一個
node10。15
web 型別 SCF；
[web-node12]
： 使用
serverless scf
部署的一個
node12。16
web 型別 SCF；
[web-custom-image-node10]
： 使用自定義映象
node10
部署的一個 web 型別 SCF；
[web-custom-image-node12]
： 使用自定義映象
node12
部署的一個 web 型別 SCF；
[web-custom-image-node14]
： 使用自定義映象
node14
部署的一個 web 型別 SCF；
[web-custom-image-node16]
： 使用自定義映象
node16
部署的一個 web 型別 SCF；
注：使用的 Web 框架為
nodejs
最泛用的
Express
，只含有計算不含
IO
操作 ， 自定義映象的
node。js
都使用的
alpine
版本。
其中，函式的預製併發例項都為
10
， 並提前做好
warm up
，記憶體都為
128MB
（自定義映象不同，有自己的
記憶體規則
），本地壓測程式碼都是相同的配置：
每個函式壓測時間為
10s
， 併發數以
10
為一梯度，累加到
100
。
Fire Request
為 Get 請求。
03。 測試結果資料圖表
本圖表可互動 （建議用 PC開啟，筆者沒有做移動端相容）
訪問地址：
https：//icebreaker。top/chart/scf-event-vs-web-vs-custom-image/
1. 平均 QPS (Avg Req/Sec)
Req_Sec 平均折線圖
從下方折線圖中，我們可以看出，隨著併發量的增加， 每秒處理過的請求一直在提升。同時也能看到 Web 函式隨著併發量變大，逐漸和 Event 函式，拉開差距。
Req_Sec 平均累加柱狀圖
從下方累加柱狀圖中，可以明顯看出 Web 型別的平均 QPS 同比 高於 Event 型別。其中 Runtime 使用 Node12 也比 Node10 高一點點，可能高版本的 Node。js 做了一些最佳化吧。
2. 平均 TPS (Avg Bytes/Sec)
Bytes_Sec 吞吐量 (KB) 平均折線圖
從下方折線圖中，我們可以看出，隨著併發量的增加，吞吐量也一直在提升。同時也能看到 Web 函式隨著併發量變大，也逐漸和 Event 函式，拉開差距，不過這個差距相比 QPS 要小很多。
Bytes_Sec 吞吐量 (KB) 平均累加柱狀圖
從下方累加柱狀圖中，可以明顯看出 Web 型別的平均 TPS 高於 Event 型別，但差距相對來說不是那麼大。同樣 Node12 也比 Node10 高一點點。
3. 平均延遲 (Avg Latency)
Latency 延遲平均折線圖
從下圖中，我們可以明顯看出，隨著併發量的增加， 延遲並沒有增加，逐漸趨於穩定。平均延遲都在
30-50ms
左右，其中 Web 型別的平均延遲，也明顯要比 Event 型別要低。
這意味著，函式響應使用者請求也更快，同樣 Node12 也比 Node10 稍稍快一點點（可忽略不計）。
04。 總結
1. 效能的提升
SCF 單個函式 承受的併發量，和 QPS，TPS 正比例相關（自動伸縮擴容）；
Web 函式和 Event 函式相比， 在處理 HTTP 請求上， 隨著併發量的增長，優勢越大；
Web 函式處理 HTTP 請求的延遲比 Event 函式 更低；
Node。js 的 Runtime 版本也有影響，Node。js12。16 在各方面數值均優於 Node10。15；
2. 開發者體驗的提升
Web 函式 也大大提升了，我們開發者在本地的開發和除錯體驗。
Before
我們原先部署一個 Event 函式 來處理 http請求 ， 往往需要寫程式碼來匯出一個某某框架例項（比如
express
，
koa
，
nuxt
，
next
。。。） 交給 Serverless 元件進行部署，然而不同的 Web 框架，往往部署時需要不同的墊片（事件轉化 HTTP），這導致了「Event 函式」和「Serverless 元件」的高耦合度。
After
而 Web 函式 就不需要和 那些 Web 框架 做強關聯了， 它只需要被告知一個監聽的埠號，不在乎我們開發者到底使用什麼框架來 Host 我們的 Web 服務。我們可以隨意在本地安裝任何的框架進行部署，而不用再去尋找對應框架的 Serverless 元件了。
同時，它對於部分現有系統的遷移非常的友好，甚至可以簡單到，只改個監聽埠號，就能一鍵式部署上雲，減少了大量花在運維部署上的時間。
這麼看來 Web 函式 也是一次革命！
它讓那些原先基於 event 的 Serverless Components Web 元件們變得
useless
，是時候拋棄他們，擁抱 Web 函數了。
一句話概括：
假如我們開發者要
編寫
或
遷移
一個 Web 服務 到 Serverless ，那麼騰訊雲 SCF
Web函式
就是你的首選！
附言
筆者非專業的測試，所有測試結果僅供參考，也歡迎專業人員提供建議和意見。
此次也測試了一下
Web 函式 + 自定義映象
的方式部署，不過測試結果比較雜亂，沒找到規律，後續會針對這個場景進行進一步的測試。
新技術是飛速發展的，本文寫於 2021。07。08 ，存在一定的歷史侷限性，如一定時間後，結果有所不同，也難免正常。
相關連結
部署程式碼和壓測程式碼
圖表地址
基於 event 的serverless components web 框架地址
Web Function 體驗官招募令
驚喜福利滿滿，點選檢視活動詳情
Web Function 使用體驗
Web Function 產品文件：
https：//cloud。tencent。com/document/product/583/56123
Web Function 快速體驗連結：
https：//console。cloud。tencent。com/scf/list-create？rid=16&ns=default&keyword=WebFunc
當前已在國內各大區域釋出上線，歡迎體驗使用！
One More Thing
立即體驗騰訊雲 Serverless Demo，領取 Serverless 新使用者禮包
騰訊雲 Serverless 新手體驗
歡迎訪問：
Serverless 中文網
！
