Serverless特點(diǎn)及應(yīng)用
Serverless可以看做是運(yùn)行于無(wú)狀態(tài)的容器中，由事件驅(qū)動(dòng)，執(zhí)行周期很短的服務(wù)，這部分描述和FaaS很像，所以在一部分人眼里Serverless = FaaS。
馬丁大叔將Serverless與FaaS、BaaS做了一個(gè)結(jié)構(gòu)整理：
馬丁大叔意思是：
Serverless = FaaS + BaaSServerless特性包括：彈性伸縮、按需付費(fèi)特點(diǎn)。
以谷歌開源的Serverless架構(gòu)方案-Knative為例，聊聊FaaS的幾個(gè)特點(diǎn)。
Knative是構(gòu)建于K8S之上的提供基于事件驅(qū)動(dòng)的Serverless架構(gòu)的標(biāo)準(zhǔn)模式。
先看下Serverless如何實(shí)現(xiàn)彈性的。
系統(tǒng)根據(jù)當(dāng)前監(jiān)控到的流量，實(shí)現(xiàn)自動(dòng)擴(kuò)縮容，簡(jiǎn)單的公式如下：
目標(biāo)實(shí)例數(shù) = 當(dāng)前并發(fā)數(shù) / 單一實(shí)例支持的并發(fā)數(shù)如果每個(gè)實(shí)例支持10并發(fā)，那當(dāng)100個(gè)并發(fā)來(lái)了，就需要10個(gè)實(shí)例。如果當(dāng)前只有1個(gè)實(shí)例，其余9個(gè)實(shí)例需要擴(kuò)容完成。
外部請(qǐng)求先緩存在Activator，直到擴(kuò)容完其他9個(gè)實(shí)例，才會(huì)將請(qǐng)求轉(zhuǎn)交給FaaS進(jìn)行請(qǐng)求處理。實(shí)例擴(kuò)容到準(zhǔn)備好這個(gè)階段，就叫做“冷啟動(dòng)”。
如何提高冷啟動(dòng)速度呢？
云廠商為減少冷啟動(dòng)時(shí)間，一般會(huì)做一些分配算法，比如：
實(shí)際擴(kuò)容實(shí)例數(shù) = 1.2 * 期望的實(shí)例數(shù)這樣其實(shí)可以支撐120個(gè)并發(fā)，減少了一次擴(kuò)容啟動(dòng)時(shí)間。
上面的實(shí)例擴(kuò)容算法算是一種冷啟動(dòng)優(yōu)化方式，我們看看是否還有其他冷啟動(dòng)優(yōu)化的方式，實(shí)例啟動(dòng)過(guò)程大概是這樣的：
下載代碼 -> 啟動(dòng)實(shí)例 -> 代碼初始化（依賴加載）-> 函數(shù)執(zhí)行不需要擴(kuò)容實(shí)例時(shí)，過(guò)程就只剩下了最后一步了，直接函數(shù)執(zhí)行，相對(duì)應(yīng)，我們叫做“熱啟動(dòng)”。
一般“冷啟動(dòng)”時(shí)間需要上百毫秒，“熱啟動(dòng)”只需要幾毫秒。
所以優(yōu)化冷啟動(dòng)，可以從優(yōu)化冷啟動(dòng)時(shí)間和優(yōu)化冷啟動(dòng)概率上解決。
減少冷啟動(dòng)概率方式有：實(shí)例復(fù)用、實(shí)例預(yù)熱。
實(shí)例復(fù)用說(shuō)的是，函數(shù)代碼執(zhí)行結(jié)束之后，不會(huì)立馬回收實(shí)例，而是從活躍狀態(tài)變成了等待狀態(tài)，處于等待狀態(tài)的實(shí)例可以存活30s，如果期間沒(méi)有請(qǐng)求需要處理，實(shí)例才會(huì)被回收，這樣達(dá)到了30s內(nèi)實(shí)例復(fù)用的目的。
實(shí)例預(yù)熱方式簡(jiǎn)單來(lái)說(shuō)，就是提供預(yù)留實(shí)例不釋放功能，在目標(biāo)擴(kuò)容實(shí)例基礎(chǔ)上增加一定的預(yù)留buffer。
以上兩種方式對(duì)應(yīng)著實(shí)例成本，需要結(jié)合具體情況具體實(shí)現(xiàn)。
優(yōu)化啟動(dòng)時(shí)間可以從兩方面入手：優(yōu)化代碼體積、減少不必要的依賴。
代碼體積越大，下載時(shí)間越長(zhǎng)，所以可以考慮代碼打包壓縮，或者在代碼模板中刪除不需要的代碼。
如何定義一個(gè)函數(shù)的粒度是另一個(gè)使用Serverless需要考慮的地方。
有的平臺(tái)推薦將整個(gè)web服務(wù)部署在一個(gè)函數(shù)里面，有的是按代碼體積做判斷，有的還需要考慮函數(shù)執(zhí)行時(shí)對(duì)于IO、CPU、內(nèi)存消耗考慮函數(shù)粒度的拆分。
但以上幾種方式都會(huì)增加研發(fā)成本上升，這也是我懷疑Serverless是否可以帶來(lái)其所承諾的研發(fā)價(jià)值的地方。其有相當(dāng)確定的使用場(chǎng)景，不能簡(jiǎn)單粗暴使用。
驅(qū)動(dòng)函數(shù)類型的方式有很多，但大部分提倡的還是事件驅(qū)動(dòng)。
觸發(fā)FaaS運(yùn)行方式都可以抽象成事件類型，比如API網(wǎng)關(guān)事件觸發(fā)。
那如何使用一個(gè)FaaS服務(wù)呢？
可以分成如下幾步：
基于FaaS平臺(tái)選擇一個(gè)熟悉語(yǔ)言對(duì)應(yīng)的Runtime平臺(tái)，基于其完成：開發(fā)、測(cè)試過(guò)程。
代碼完成之后，上傳到FaaS平臺(tái)。
代碼上傳之后，通過(guò)API/SDK或一些其他事件源觸發(fā)函數(shù)。
FaaS平臺(tái)接收到事件觸發(fā)，基于配置并發(fā)度情況，彈性擴(kuò)容并執(zhí)行函數(shù)。
函數(shù)使用后，按資源使用情況進(jìn)行計(jì)費(fèi)。
為拉齊函數(shù)編寫與函數(shù)執(zhí)行環(huán)境的差異，F(xiàn)aaS平臺(tái)一般會(huì)提供一些研發(fā)工具。有組件式命令行Devs工具，也有注重運(yùn)維部署方面的Ops工具，提供平臺(tái)觀察函數(shù)生命周期。
通過(guò)工具，可以快速完成資源管理（代碼編寫、運(yùn)行、下載、創(chuàng)建、上傳）、快速部署、調(diào)試、工程模板、邏輯單元等工作。
有了一個(gè)個(gè)上傳到云端的函數(shù)了，就可以基于函數(shù)做工作流編排，實(shí)現(xiàn)想要的邏輯控制了。包括任務(wù)跟蹤，狀態(tài)轉(zhuǎn)換，日志查看，監(jiān)控調(diào)試等。
當(dāng)然還有函數(shù)執(zhí)行之后是可觀測(cè)性（Logging、Metric、Tracing）實(shí)現(xiàn)函數(shù)的運(yùn)維。
包含用于定位、排查、分析問(wèn)題的工具，評(píng)估風(fēng)險(xiǎn)、配置并發(fā)度等工作。
以及執(zhí)行的詳細(xì)日志：
