當(dāng)前位置：首頁(yè) > 编程资源 > 编程问答 >内容正文

编程问答

Serverless实战之路

發(fā)布時(shí)間：2025/3/16 编程问答 11 豆豆

生活随笔收集整理的這篇文章主要介紹了 Serverless实战之路小編覺(jué)得挺不錯(cuò)的,現(xiàn)在分享給大家,幫大家做個(gè)參考.

by yugasun from yugasun.com/post/server 本文可全文轉(zhuǎn)載，但需要保留原作者和出處。

在閱讀本文之前，需要讀者對(duì) Serverless 概念有一定的了解，如果你還不知道什么是 Serverless，也可以先閱讀本系列之前的相關(guān)文章。筆者在之前的幾篇文章，重點(diǎn)講解了很多關(guān)于如何 Serverless 化傳統(tǒng)服務(wù)和 Serverless 實(shí)戰(zhàn)經(jīng)驗(yàn)，比如如何實(shí)現(xiàn)一個(gè)后臺(tái)管理系統(tǒng)。但是在實(shí)際開(kāi)發(fā)過(guò)程中，我們不僅要考慮如何將自己的服務(wù)遷移到 Serverless 架構(gòu)上，還需要了解 Serverless 架構(gòu)相對(duì)于傳統(tǒng)架構(gòu)的區(qū)別，這樣才能夠在實(shí)際工作中，開(kāi)發(fā)出更加高效穩(wěn)定的服務(wù)。本章是筆者在 2 年的 Serverless 研發(fā)過(guò)程中，總結(jié)出來(lái)的認(rèn)為比較重要的幾點(diǎn)知識(shí)經(jīng)驗(yàn)，希望對(duì)讀者有所幫助。

本系列文章分為理論和實(shí)踐兩部分，理論部分會(huì)介紹一些 Serverless 相關(guān)概念介紹，然后在理論部分的基礎(chǔ)上總結(jié)出一些實(shí)際項(xiàng)目開(kāi)發(fā)中的一些開(kāi)發(fā)建議。

本文主要內(nèi)容：

1. Serverless 是如何實(shí)現(xiàn)自動(dòng)擴(kuò)縮容的

2. 冷啟動(dòng)的原理和優(yōu)化方法

3. 如何規(guī)劃服務(wù)函數(shù)粒度

4. 如何選擇合適的函數(shù)類型

Serverless 是如何實(shí)現(xiàn)自動(dòng)擴(kuò)縮容的

本文以 Knative 為例，介紹 Serverless 是如何實(shí)現(xiàn)自動(dòng)擴(kuò)縮容的。

Knative 是谷歌開(kāi)源的 Serverless 架構(gòu)方案，構(gòu)建在 Kubernetes 的基礎(chǔ)上，旨在為構(gòu)建和部署 Serverless 架構(gòu)和基于事件驅(qū)動(dòng)的應(yīng)用程序提供了一致的標(biāo)準(zhǔn)模式

Knative 自己實(shí)現(xiàn)了一個(gè) KPA（Knative Pod Autoscaler）算法，用于自動(dòng)擴(kuò)縮容。KPA 算法的基本思想是，系統(tǒng)依據(jù)當(dāng)前監(jiān)控到的流量（并發(fā)請(qǐng)求數(shù)）來(lái)自動(dòng)擴(kuò)縮容。簡(jiǎn)單計(jì)算公式就是：

期望的實(shí)例數(shù) = 當(dāng)前并發(fā)請(qǐng)求數(shù) / 實(shí)例支持并發(fā)數(shù)

舉個(gè) ，系統(tǒng)檢測(cè)到當(dāng)前一共有?100?個(gè)并發(fā)請(qǐng)求，單個(gè)實(shí)例支持并發(fā)數(shù)為?10，那么期望的實(shí)例數(shù)就是?100 / 10 = 10。如果當(dāng)前系統(tǒng)可用的實(shí)例數(shù)為?1，那么系統(tǒng)就會(huì)自動(dòng)新增?9?個(gè)實(shí)例，直到達(dá)到期望實(shí)例數(shù)?10。在這 9 個(gè)實(shí)例準(zhǔn)備好前，Knative 會(huì)將請(qǐng)求緩存到 Activator，直到擴(kuò)容完成（9 個(gè)實(shí)例準(zhǔn)備好）后再轉(zhuǎn)發(fā)到 FaaS（函數(shù)代碼執(zhí)行處理請(qǐng)求），而等待實(shí)例準(zhǔn)備好的過(guò)程就是人們常說(shuō)的?冷啟動(dòng)，接下來(lái)我們來(lái)聊聊冷啟動(dòng)。

注：實(shí)際上，云廠商為了減少冷啟動(dòng)，會(huì)根據(jù)優(yōu)化規(guī)則和算法分配更多的實(shí)例數(shù)量，比如實(shí)際擴(kuò)容的實(shí)例數(shù)量 = 1.2 * 期望的實(shí)例數(shù)，這樣下個(gè)檢測(cè)周期到來(lái)時(shí)，即使并發(fā)請(qǐng)求為 120，當(dāng)前活躍實(shí)例數(shù)也是夠用的，這個(gè)后面也會(huì)講到。

冷啟動(dòng)的原理和優(yōu)化方法

眾所周知，Serverless 平臺(tái)為開(kāi)發(fā)者提供了多樣化和便利的代碼運(yùn)行環(huán)境，在開(kāi)發(fā)過(guò)程中，開(kāi)發(fā)者可以不需要關(guān)心代碼運(yùn)行環(huán)境的準(zhǔn)備，因?yàn)?FaaS 在運(yùn)行時(shí)，Serverless 平臺(tái)已經(jīng)幫助我們準(zhǔn)備好了，但是 Serverless 容器實(shí)例的啟動(dòng)并不是瞬時(shí)完成的，它是需要時(shí)間準(zhǔn)備的，實(shí)例啟動(dòng)過(guò)程大致可以分為四個(gè)階段：

下載代碼 -> 啟動(dòng)實(shí)例 -> 初始化代碼（加載代碼和依賴） -> 執(zhí)行函數(shù)

注：鏡像方式部署的函數(shù)的第一步是同步鏡像。

冷啟動(dòng)的過(guò)程就是包含以上全部四個(gè)步驟，而當(dāng)容器準(zhǔn)備好后，在不需要擴(kuò)容的前提下，函數(shù)再次執(zhí)行，就不會(huì)經(jīng)歷前面三個(gè)步驟，而是直接執(zhí)行函數(shù)，這就是所謂的?熱啟動(dòng)。

通常冷啟動(dòng)的時(shí)間是百毫秒級(jí)，熱啟動(dòng)由于省去了前三個(gè)步驟，時(shí)間通常是毫秒級(jí)。所以我們應(yīng)該盡可能的減少冷啟動(dòng)。優(yōu)化函數(shù)的冷啟動(dòng)的方法，主要有兩個(gè)維度：冷啟動(dòng)的時(shí)間和冷啟動(dòng)的概率，接下來(lái)將從兩個(gè)維度分別講解。

冷啟動(dòng)的概率

減少冷啟動(dòng)的概率主要有兩個(gè)方法：實(shí)例復(fù)用和實(shí)例預(yù)熱。

1. 實(shí)例復(fù)用

函數(shù)代碼執(zhí)行結(jié)束的實(shí)例并不會(huì)不會(huì)立馬回收，而是會(huì)從活躍狀態(tài)（Active）變?yōu)榇鼱顟B(tài)（Reserve），等待下一個(gè)請(qǐng)求的到來(lái)。處在待命狀態(tài)的實(shí)例會(huì)有一個(gè)待命時(shí)長(zhǎng)（可配置，一般默認(rèn)是 30 分鐘），如果在這期間沒(méi)有請(qǐng)求需要處理，實(shí)例就會(huì)被回收。如果有請(qǐng)求需要處理，實(shí)例就會(huì)重新進(jìn)入活躍狀態(tài)然后處理請(qǐng)求，從而達(dá)到實(shí)例復(fù)用的目的。

但是如果設(shè)置待命時(shí)長(zhǎng)太長(zhǎng)，待命實(shí)例就會(huì)長(zhǎng)期得不到回收，從而造成資源浪費(fèi)，這會(huì)對(duì)云廠商成本產(chǎn)生很大影響。所以各個(gè)云廠商會(huì)根據(jù)各自產(chǎn)品情況和優(yōu)化策略，嘗試設(shè)置一個(gè)最優(yōu)值。

2. 實(shí)例預(yù)熱

實(shí)例預(yù)熱可以分為兩種類型：被動(dòng)預(yù)熱和主動(dòng)預(yù)熱。所謂被動(dòng)或者主動(dòng)，通常是指是否是用戶主動(dòng)的行為。

被動(dòng)預(yù)熱就是在進(jìn)行擴(kuò)容時(shí)，會(huì)基于實(shí)際情況擴(kuò)容大于當(dāng)前期望的實(shí)例數(shù)量，具體數(shù)量的比例是云廠商自己決定的。

主動(dòng)預(yù)熱是指開(kāi)發(fā)者依賴 Serverless 平臺(tái)提供預(yù)留實(shí)例的能力，主動(dòng)配置預(yù)留實(shí)例的數(shù)量，主動(dòng)配置的預(yù)留實(shí)例數(shù)量將不會(huì)被釋放。這樣當(dāng)請(qǐng)求到來(lái)時(shí)，已經(jīng)預(yù)留好的實(shí)例可以直接提供服務(wù)，可以有效避免冷啟動(dòng)的概率。

前面提到過(guò)，如果一直保持實(shí)例不被回收，會(huì)大大增加 Serverless 的成本，所以云廠商針對(duì)預(yù)留實(shí)例收取一定的費(fèi)用，所以需要開(kāi)發(fā)者根據(jù)自身服務(wù)特點(diǎn)，評(píng)估是否需要預(yù)留實(shí)例和預(yù)留多少實(shí)例數(shù)量。

定時(shí)預(yù)熱

以上優(yōu)化冷啟動(dòng)概率的方法都是需要依賴 Serverless 平臺(tái)提供的能力，就算是主動(dòng)預(yù)熱也是需要平臺(tái)支持預(yù)留實(shí)例功能后，開(kāi)發(fā)者才能配置。實(shí)際上，我們還可以通過(guò)主動(dòng)調(diào)用函數(shù)來(lái)實(shí)現(xiàn)實(shí)例的預(yù)熱，利用?實(shí)例空閑后隔一段時(shí)間才會(huì)被回收?的特點(diǎn)，可以通過(guò)定時(shí)觸發(fā)函數(shù)執(zhí)行的方法，來(lái)實(shí)現(xiàn)實(shí)例預(yù)熱。

比如我們?cè)趧?chuàng)建 Serverless 函數(shù)（以下簡(jiǎn)稱 FaaS）時(shí)，同時(shí)還可以給它配置上定時(shí)觸發(fā)器(通常 FaaS 可以配置多種類型的觸發(fā)器，定時(shí)觸發(fā)器是其中一種)，這個(gè)觸發(fā)器可以每隔 5 分鐘（可配置）觸發(fā)一次 FaaS 執(zhí)行，這樣就可以實(shí)現(xiàn)定時(shí)預(yù)熱。而且還可以根據(jù) FaaS 服務(wù)的情況，設(shè)置多個(gè)定時(shí)觸發(fā)器，從而應(yīng)對(duì)不同的并發(fā)場(chǎng)景。

但是 FaaS 是按照自身運(yùn)行時(shí)使用的內(nèi)存和時(shí)間收費(fèi)的，設(shè)置定時(shí)觸發(fā)運(yùn)行，是會(huì)產(chǎn)生費(fèi)用的，所以我們也不能隨便亂用。當(dāng)然還需要在 FaaS 代碼中，通過(guò)判斷獲取的事件類型為定時(shí)觸發(fā)器類型，做特殊處理，比如盡快返回結(jié)果，以便讓函數(shù)能夠以更短的時(shí)間運(yùn)行，從而減少費(fèi)用。

注：云廠商一般會(huì)限制函數(shù)可配置的觸發(fā)器個(gè)數(shù)。

冷啟動(dòng)的時(shí)間

針對(duì)冷啟動(dòng)的時(shí)間，主要是優(yōu)化前三個(gè)步驟：下載代碼、啟動(dòng)實(shí)例、初始化代碼。其中除了?啟動(dòng)實(shí)例?時(shí)間依賴平臺(tái)底層的優(yōu)化外，下載代碼?和?初始化代碼是我們開(kāi)發(fā)者可掌控的，畢竟代碼是我們自己寫(xiě)的。

1. 優(yōu)化代碼體積

在相同的網(wǎng)絡(luò)環(huán)境下，下載代碼?耗費(fèi)時(shí)間，取決于 FaaS 代碼的體積，而且代碼體積越大，下載時(shí)間越長(zhǎng)。

很多開(kāi)發(fā)者在剛開(kāi)始接觸 Serverless 開(kāi)發(fā)時(shí)，會(huì)將代碼全量上傳部署到 FaaS，于是部署到 FaaS 的代碼包括了很多不必要的代碼和依賴，這樣就會(huì)導(dǎo)致 FaaS 代碼比實(shí)際的業(yè)務(wù)代碼體積大很多，于是?下載代碼?過(guò)程就會(huì)變長(zhǎng)，自然冷啟動(dòng)時(shí)間也會(huì)變長(zhǎng)。

這里以 Express.js 應(yīng)用為例，在本地開(kāi)發(fā) Express.js 項(xiàng)目時(shí)，會(huì)安裝很多依賴包到?node_modules?目錄，其中包括生產(chǎn)環(huán)境依賴（dependencies）和開(kāi)發(fā)環(huán)境依賴(devDependencies)，這兩種依賴都是在本地開(kāi)發(fā)時(shí)必須的（比如 Jest 單元測(cè)試模塊），但是在生產(chǎn)環(huán)境中，是不需要開(kāi)發(fā)環(huán)境的依賴的。

很多開(kāi)發(fā)者為了省事，部署時(shí)，都是直接執(zhí)行?npm install?命令，將這兩種依賴同時(shí)安裝，大多數(shù)時(shí)候項(xiàng)目的開(kāi)發(fā)環(huán)境依賴的體積是大于生產(chǎn)環(huán)境依賴的，這就直接導(dǎo)致 FaaS 代碼體積過(guò)大。實(shí)際上在部署到 FaaS 前，可以通過(guò)執(zhí)行?npm install --production?命令來(lái)指定只安裝生產(chǎn)環(huán)境依賴就可以了，這樣可以大大減少部署后的 FaaS 代碼體積。

另外，有些項(xiàng)目是需要編譯的，比如基于 TypeScript 開(kāi)發(fā)的項(xiàng)目，我們可以還可以引入打包工具（比如 Webpack，Rollup），將項(xiàng)目代碼打包壓縮，甚至可以借助打包工具的?Tree Shaking?技術(shù)，將不需要的代碼刪除，都可以有效減少 FaaS 代碼體積。

2. 減少不必要的依賴

先來(lái)看一張關(guān)于 FaaS 代碼依賴模塊數(shù)對(duì)冷啟動(dòng)時(shí)間的影響的測(cè)試結(jié)果（圖片來(lái)自文章?《Serverless: Cold Start War》）：

通過(guò)上圖可以看出，依賴數(shù)量越多，冷啟動(dòng)時(shí)間越長(zhǎng)，這是因?yàn)橐蕾嚢蕉?#xff0c;代碼體積會(huì)越大，下載代碼?步驟的時(shí)間就會(huì)越長(zhǎng)，同時(shí)?初始化代碼?步驟所需要的時(shí)間也會(huì)越長(zhǎng)。

所以減少不必要的依賴變得很有必要。其實(shí)在講?優(yōu)化代碼體積?時(shí)，已經(jīng)提到如何減少項(xiàng)目依賴。除了以上提到的方法外，開(kāi)發(fā)者還可以在編寫(xiě)業(yè)務(wù)代碼時(shí)，盡量減少不必要的模塊依賴的引入。

比如在前端開(kāi)發(fā)中，項(xiàng)目的依賴目錄?node_modules?像黑洞一樣，深不可見(jiàn)，動(dòng)不動(dòng)就幾百兆，甚至上 G 的大小，這是因?yàn)樽畛?npm 在安裝模塊時(shí)是樹(shù)狀結(jié)構(gòu)，每個(gè)第三方模塊都會(huì)將各自的依賴安裝到各自的目錄的?node_modules?中，這就導(dǎo)致如果不同的第三方模塊依賴同一個(gè)模塊時(shí)，就會(huì)重復(fù)安裝到各自的?node_modules?目錄。后來(lái) npm 針對(duì)樹(shù)狀依賴結(jié)構(gòu)進(jìn)行了優(yōu)化，改成了扁平結(jié)構(gòu)，但是當(dāng)依賴的同一個(gè)第三方模塊版本不一樣時(shí)，還是會(huì)存在重復(fù)安裝的情況。而且開(kāi)源社區(qū)的第三方模塊質(zhì)量層次不齊，有時(shí)一個(gè)簡(jiǎn)單的類型判斷就需要通過(guò)安裝第三方模塊來(lái)實(shí)現(xiàn)，而且很多時(shí)候，我們只是用到了某個(gè)模塊的很小一部分功能。

在開(kāi)發(fā)項(xiàng)目時(shí)，我們應(yīng)該多思考下，如果是某個(gè)簡(jiǎn)單功能，是不是可以自己開(kāi)發(fā)實(shí)現(xiàn)，而不是在遇到問(wèn)題時(shí)，總是想著使用開(kāi)源的第三方模塊來(lái)解決。作為一名程序員自己實(shí)現(xiàn)會(huì)花費(fèi)更多時(shí)間，但是更快的提升自己，同時(shí)也能有效減少不必要的模塊依賴的引入。

如何規(guī)劃服務(wù)函數(shù)粒度

筆者在開(kāi)發(fā)一些 Serverless 后端服務(wù)時(shí)，經(jīng)常面臨一個(gè)函數(shù)粒度問(wèn)題：使用一個(gè)函數(shù)還是多個(gè)函數(shù)？

目前 Serverless 平臺(tái)對(duì)傳統(tǒng) Web 服務(wù)提供了良好的支持，而且也提供了非常便利的遷移方法，比如騰訊云的?Serveless Components?解決方案、AWS 的?SAM以及阿里云的?Serveless Devs，它們都可以通過(guò) YAML 配置的方式，快速便捷的將基于 Web 框架的服務(wù)部署到 FaaS 上。

但它們都是將整個(gè) Web 服務(wù)部署到同一個(gè)函數(shù)里，這樣可能會(huì)存在以下問(wèn)題：

Web 服務(wù)中存在需要長(zhǎng)時(shí)間運(yùn)算或者大內(nèi)存的接口，應(yīng)該如何處理？

如果 Web 服務(wù)代碼體積超過(guò)云廠商限制（通常 500M，應(yīng)該如何處理？

基于微服務(wù)拆分原則進(jìn)行拆分后，還需要考慮服務(wù)中需要長(zhǎng)時(shí)間運(yùn)算或者大內(nèi)存的接口，因?yàn)?FaaS 的收費(fèi)標(biāo)準(zhǔn)就是每次執(zhí)行的時(shí)長(zhǎng)和使用內(nèi)存大小，如果不進(jìn)行拆分，服務(wù)函數(shù)的內(nèi)存配置就需要按照大內(nèi)存來(lái)配置，這就直接導(dǎo)致整體成本的上升。所以針對(duì)這種特殊的服務(wù)接口，我們應(yīng)盡量能拆分成單獨(dú)的函數(shù)進(jìn)行處理。

超過(guò)云廠商 FaaS 的代碼體積限制的 Web 服務(wù)（前提是已經(jīng)進(jìn)行了代碼體積和依賴優(yōu)化），如果想要部署到 FaaS 上，必須進(jìn)行服務(wù)拆分的。

所以解決以上兩個(gè)問(wèn)題的方法就是拆分服務(wù)，至于如何拆分服務(wù)是軟件開(kāi)發(fā)中一直都存在的熱門話題，本文就不深入探討了，服務(wù)的拆分可以參考?微服務(wù)拆分之道。

如何選擇合適的函數(shù)類型

在選擇函數(shù)類型前，我們先來(lái)了解下，截止目前為止，Serverless 平臺(tái)支持的幾種函數(shù)類型。

事件類型

最開(kāi)始的 FaaS 的運(yùn)行方式都是事件類型，通過(guò)觸發(fā)器觸發(fā)事件，然后通過(guò) FaaS 函數(shù)來(lái)處理事件。傳統(tǒng)的 Web 服務(wù)入股偶需要遷移到事件函數(shù)，就需要在函數(shù)入口文件對(duì) API 網(wǎng)關(guān)觸發(fā)器事件進(jìn)行轉(zhuǎn)化，相關(guān)文章可以閱讀?《如何將 Web 框架遷移到 Serverless》。流程圖如下：

這種架構(gòu)有個(gè)缺陷，就是針對(duì)每次請(qǐng)求，都需要經(jīng)歷適配層的轉(zhuǎn)化，這會(huì)增加請(qǐng)求時(shí)延。由于 API 網(wǎng)關(guān)和函數(shù)之間是通過(guò) JSON 結(jié)構(gòu)體交換信息的，所以不支持原生文件類型傳輸，如果要傳輸文件類型，就需要在 API 網(wǎng)關(guān)側(cè)，對(duì)文件類型進(jìn)行編碼（比如 Base64），然后在函數(shù)側(cè)解碼。

騰訊云官方介紹?事件函數(shù)。

HTTP 類型

為了彌補(bǔ)事件類型函數(shù)的缺點(diǎn)，云廠商針對(duì) Web 專門推出了 Web 類型（騰訊云叫 Web 類型，阿里云叫 HTTP 類型）的函數(shù)，通過(guò) API 網(wǎng)關(guān)與 FaaS 的 HTTP 直通互連，開(kāi)發(fā)者在遷移 Web 服務(wù)到 FaaS 上時(shí)，不再需要添加適配層代碼來(lái)對(duì) JSON 進(jìn)行轉(zhuǎn)化，從而縮短了實(shí)際請(qǐng)求鏈路，相對(duì)于事件函數(shù)具備更好的 Web 服務(wù)性能，而且開(kāi)發(fā)者也不再需要進(jìn)行入口文件改造，只需要按照傳統(tǒng) Web 應(yīng)用開(kāi)發(fā)方式，通過(guò)監(jiān)聽(tīng)端口啟動(dòng)服務(wù)就行。可參考騰訊云官方介紹 Web函數(shù)。

更加詳細(xì)的參數(shù)對(duì)比，可參考文章?《再探 Web Function - 用數(shù)據(jù)闡釋優(yōu)勢(shì)》

鏡像函數(shù)

基于代碼部署的函數(shù)，它們依賴的執(zhí)行環(huán)境都是云廠商預(yù)先提供的，這樣就有個(gè)問(wèn)題：針對(duì)一些特殊業(yè)務(wù)需求，特別是一些視頻處理相關(guān)的函數(shù)，需要系統(tǒng)額外安裝底層庫(kù)來(lái)支持（雖然預(yù)裝環(huán)境已經(jīng)支持了大多數(shù)底層依賴，但是還是沒(méi)法滿足），但是開(kāi)發(fā)者是沒(méi)法自定義安裝這些依賴到云廠商提供的運(yùn)行環(huán)境的。

為了應(yīng)對(duì)自定義運(yùn)行環(huán)境的需求，云廠商提供了基于用戶自定義鏡像部署的 FaaS（這里只是部署方式的改變，但是 FaaS 類型依然只有事件類型和 HTTP 類型）。有了自定義鏡像的部署方式，一些依賴底層庫(kù)的應(yīng)用就可以非常方便的部署到 FaaS 了。

雖然鏡像部署方式非常方便，但是它有個(gè)缺點(diǎn)：大多數(shù)情況下，冷啟動(dòng)時(shí)間會(huì)比較長(zhǎng)。為什么說(shuō)大多數(shù)情況下呢，因?yàn)榇蠖鄶?shù)情況下鏡像比代碼包的體積大，所以在冷啟動(dòng)時(shí)，拉取鏡像的時(shí)間會(huì)比代碼的方式慢很多，從而導(dǎo)致冷啟動(dòng)時(shí)間變長(zhǎng)。當(dāng)然鏡像體積也可以優(yōu)化，比如 Node.js 應(yīng)用的基礎(chǔ)鏡像可以優(yōu)化到幾十兆，但是如果是輕量級(jí)的 Node.js 應(yīng)用，而且不需要特定的依賴（比如 Puppeteer、TensorFlow、FFmpeg...），那么我們也就沒(méi)有必要使用鏡像方式部署了，使用代碼方式部署會(huì)更加方便。

選擇適合自己的函數(shù)類型

從字面上就可以看出兩種 FaaS 類型的特點(diǎn)，事件類型更加適合事件驅(qū)動(dòng)的業(yè)務(wù)場(chǎng)景，比如視頻流處理，Kafka 消息訂閱處理等，而 HTTP 類型更加專注于 Web 應(yīng)用場(chǎng)景。至于代碼部署方式，筆者還是主要推薦代碼方式部署，除非是不得不定制化運(yùn)行環(huán)境，才會(huì)使用鏡像方式部署，畢竟鏡像方式還依賴鏡像服務(wù)，而企業(yè)版容器鏡像服務(wù)（云廠商不提供個(gè)人版 SLA 保障）還是很昂貴的，并且鏡像部署的冷啟動(dòng)時(shí)間也比較長(zhǎng)。

開(kāi)發(fā)者可根據(jù)個(gè)人需求，來(lái)靈活選擇自己 FaaS 類型和部署方式，以上分析僅供參考。

參考文獻(xiàn)

1. Knative 基本功能深入剖析：Knative Serving 自動(dòng)擴(kuò)縮容 Autoscaler

2. Serverless: Cold Start Warhttps://mikhail.io/2018/08/serverless-cold-start-war/

3. 一直在說(shuō)的冷啟動(dòng)，究竟是個(gè)啥子呦！

推薦書(shū)籍

《Serverless從入門到進(jìn)階》

推薦理由：完整介紹Serverless架構(gòu)，內(nèi)容涵蓋騰訊、阿里巴巴、亞馬遜等多個(gè)云廠商的產(chǎn)品，并對(duì)它們進(jìn)行橫向?qū)Ρ群头治觥Ｖ破脚_(tái)提供商騰訊云Serverless高級(jí)產(chǎn)品經(jīng)理和高級(jí)研發(fā)工程師聯(lián)合撰寫(xiě)，包含豐富的客戶場(chǎng)景和最佳實(shí)踐，可以為有相似需求的企業(yè)提供實(shí)戰(zhàn)參考。

目前100000+人已關(guān)注加入我們

???????

總結(jié)

以上是生活随笔為你收集整理的Serverless实战之路的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。

上一篇： NYOJ 17 单调递增最长公共子序列
下一篇： NYOJ 36 最长公共子序列