2009 年加州大學(xué)伯克利分校發(fā)表了一篇文章，預(yù)言云計算將是未來重要的技術(shù)趨勢。十年后的2019年，該校對 Serverless 技術(shù)再次進行預(yù)測，認(rèn)為 Serverless 技術(shù)是未來十年的技術(shù)趨勢。Serverless 計算被認(rèn)為是云主機、容器之后的第三代計算形態(tài)。

下圖為云計算發(fā)展的整個過程，同時也是Serverless的發(fā)展過程，共分為四個階段。

a) 物理機階段：

此時如果進行一個網(wǎng)站的開發(fā)是極為麻煩的，不僅需要購置物理機，還要手動安裝各種運行環(huán)境，開發(fā)，部署，測試，上線。除此之外，還要在物理層面上解決電，網(wǎng)，硬件磨損等各種問題。

b) IaaS階段：

IaaS指的是基礎(chǔ)設(shè)施即服務(wù)。隨著虛擬化技術(shù)的不斷發(fā)展，出現(xiàn)了很多基于虛擬化的云廠商和產(chǎn)品，如阿里云ECS。這個階段，無需自建機房，采購以及配置硬件設(shè)施，云平臺會提供這些基礎(chǔ)設(shè)施。也正因如此，那些物理層面的電，硬件磨損什么的，用戶無需關(guān)注。

c) PaaS階段：

PaaS指的是平臺即服務(wù)。所謂的平臺，其實是結(jié)合業(yè)務(wù)發(fā)展，在IaaS基礎(chǔ)上，將一些如數(shù)據(jù)庫，中間件等通用功能做成服務(wù)。虛擬化技術(shù)可以讓用戶不必關(guān)心硬件問題，后來出現(xiàn)的容器技術(shù)可以讓用戶不必關(guān)心運行環(huán)境差異的問題。容器技術(shù)出現(xiàn)后，意味著服務(wù)器上部署的不再是應(yīng)用，而是容器。當(dāng)容器多了后，可通過k8s進行管理。

d) Serverless階段：

這個階段是真正解放生產(chǎn)，專注業(yè)務(wù)的階段。在FaaS層面，應(yīng)用由諸多個獨立的函數(shù)組成，每個函數(shù)實現(xiàn)各自的業(yè)務(wù)邏輯。在數(shù)據(jù)獲取層面，BaaS 將后端能力封裝成了服務(wù)，并以接口的形式提供給FaaS。事實上，數(shù)據(jù)庫的增刪改查剛好對應(yīng)Restful API的POST/DELETE/PUT/GET。

作為未來十年云計算的重要趨勢之一，Serverless 架構(gòu)已經(jīng)展示出不俗的潛力。Forrester 認(rèn)為：Serverless 架構(gòu)的興起，讓 FaaS （Function As A Service）成為繼 IaaS、PaaS、SaaS 之后一種新的云計算能力提供方式。預(yù)計 2022 年，將會有大量主流企業(yè)的核心應(yīng)用，從原來的主機架構(gòu)遷移到 Serverless 架構(gòu)。

Serverless是什么

從單詞角度理解,server譯為服務(wù)，less譯為少，Serverless可以理解為無服務(wù)器計算。

從語義角度理解，之所以叫無服務(wù)器計算，是因為和傳統(tǒng)的PaaS(平臺即服務(wù))相比，用戶不需要關(guān)心服務(wù)器的部署與配置。但這并不意味著不需要服務(wù)器，只是這些東西皆由云平臺來提供。

從架構(gòu)角度理解，Serverless=FaaS+事件驅(qū)動+BaaS=無服務(wù)器計算(Serverless computing)

FaaS: Function as a Service,函數(shù)即服務(wù)
事件驅(qū)動：通過事件觸發(fā)的形式去完成函數(shù)的調(diào)用，處理請求和響應(yīng)（如定時任務(wù)/http請求...）
BaaS: Backend as a Service 后端即服務(wù)

Serverless 優(yōu)點

Serverless 架構(gòu)擁有零服務(wù)器運維和空閑時無計算成本等特點；其交付心智可以體現(xiàn)為將復(fù)雜留給云廠商，把便捷帶給更多開發(fā)者。綜上所述 Serverless 的優(yōu)勢可以體現(xiàn)在如下：

1）降本提效

云廠商為使用者提供服務(wù)器的管理和運維工作，為使用者提供數(shù)據(jù)庫、對象存儲等 Baas 服務(wù)，讓用戶將更多的注意力放在自身的業(yè)務(wù)邏輯上，提升研發(fā)效率，縮小項目的創(chuàng)新周期，同時 Serverless 的使用者不用更多的擔(dān)心自身的服務(wù)器運維，基礎(chǔ)設(shè)施的運維等工作，更不用為這部分有額外的費用支出，無需承擔(dān)更多的運維工作成本等；Serverless 架構(gòu)提供了較為完善、全面的按量付費模型，使用者只需要按照自己實際使用的資源量付費即可；Serverless 架構(gòu)在這一層面有較為明確的優(yōu)勢。

降低運維成本
降低人力成本
提高研發(fā)效率
降低創(chuàng)新周期
按量付費、降低支出成本

2）安全、方便、可靠

把更專業(yè)的事情交給更專業(yè)的人去做，Serverless 架構(gòu)將更多服務(wù)器運維、安全相關(guān)的事情交給云廠商來做，大規(guī)模提升項目整體的安全性；同時，Serverless 架構(gòu)明顯比其它架構(gòu)更簡單，因為更多的 Baas 服務(wù)都是云廠商提供的，使用者將會管理更少的組件，這意味著 Serverless 的使用者可以更簡單更方便的管理項目；同時 Serverless 架構(gòu)擁有著彈性能力，即自動伸縮的能力,該能力可以讓項目在流量增加的時候，自動進行擴容，在流量降低的時候，自動進行縮容，進而保證整個業(yè)務(wù)的安全、穩(wěn)定。專業(yè)團隊為用戶保障安全，保障性能，這使得 Serverless 架構(gòu)：

安全風(fēng)險更低
資源開銷更小
符合“綠色”計算思想
更加方便管理
彈性伸縮，服務(wù)更可靠

除國外幾大云計算大廠 AWS Lanmbda、Google Cloud Functions 早已布局外，國內(nèi)各大廠商也在爭先布局，包括字節(jié)、阿里、騰訊、華為、百度等。

關(guān)于阿里的投入可以參考為什么阿里要舉集團之力趟坑 Serverless?

下圖是CNCF 列出的 CNCF 列出的 Faas 平臺

云原生時代下的 Serverless

毋庸置疑，當(dāng)前已經(jīng)進入了云原生的時代，那在云原生時代下的 Serverless 的合理架構(gòu)是怎樣的呢?

答案就是 Knative！！

Knative 是谷歌開源的 Serverless 架構(gòu)方案，旨在提供一套簡單易用的 Serverless 方案，把 Serverless 標(biāo)準(zhǔn)化。Google 內(nèi)部的 Serverless 產(chǎn)品 CloudRun 就是基于 Knative 建設(shè)的。目前參與Knative的主要公司有 Google、Pivotal、IBM、Red Hat。Knative 于2018年7月24日才對外發(fā)布，2021 年剛發(fā)布了 1.0 版本。

有了 ”k8s，為什么還要 knative”

通常情況下 Serverless = Faas + Baas，F(xiàn)aas 無狀態(tài)（業(yè)務(wù)邏輯），Baas 有狀態(tài)（通用服務(wù)：數(shù)據(jù)庫，認(rèn)證，消息隊列）。

既然有了 k8s (paas), 為什么還需要 Knative (Serverless),下面從四個方面來進行解釋：資源利用率，彈性伸縮，按比例灰度發(fā)布，用戶運維復(fù)雜性

1) 資源利用率

講資源利用率之前先看下下面兩個應(yīng)用，左邊應(yīng)用 A 這個是典型的中長尾應(yīng)用，中長尾應(yīng)用就是那些每天大部分時間都沒有流量或者有很少流量的應(yīng)用。

想一下，如果用 paas(k8s) 來實現(xiàn)的話，對于應(yīng)用 A，需按照資源占用的資源最高點來申請規(guī)格，也就是 4U10G, 而且 paas 最低實例數(shù)**>=1**, 長此以往, 當(dāng)中長尾應(yīng)用足夠多時，資源利用率可想而知。有可能會出現(xiàn) 大部分邊緣集群資源被預(yù)占，但是利用率卻很低。

而 Knative，恰恰可以解決應(yīng)用A的資源占用問題，因為 Knative 可以將實例縮容為0，并根據(jù)請求自動擴縮容，縮容到零可以大大增加集群的資源利用率，因為中長尾應(yīng)用都是按需所取，不會過度空占用資源。

比較合理的是對應(yīng)應(yīng)用A 用 Knative(Serverless)，對于應(yīng)用 B 用 k8s（Paas）

2) 彈性伸縮

大家可能會想到，k8s 也有 hpa 進行擴縮容，但是 Knative 的 kpa 和 k8s 的 hpa 有很大的不同：

? Knative 支持縮容到 0 和從 0 啟動，反應(yīng)更迅速適合流量突發(fā)場景；

? K8s HPA 不支持縮容到 0 ，反應(yīng)比較保守

具體比較如下：

	Knative KPA	k8s HPA
指標(biāo)類型	可以根據(jù) 請求量擴速容	只能根據(jù) cpu memory 等指標(biāo)擴縮容（或自定義指標(biāo)）
01啟動	可以縮容到0和冷啟動	只能縮容到1（如果縮容到0，就沒有實例了，流量進不來，metrics數(shù)據(jù)永遠(yuǎn)為0，此時HPA也無能為力）
指標(biāo)獲取方式	Knative 指標(biāo)獲取有兩種方式，Activator 和queue-proxy, activator的metrics 是通過websocket 主動push 給Autoscaler的，反應(yīng)更迅速	k8s 只能是通過prometheus 輪詢獲取。
反應(yīng)速度	Knative 默認(rèn)會計算 60 秒窗口內(nèi)的平均并發(fā)數(shù)，也會計算 6 秒的恐慌窗口，6s內(nèi)達(dá)到目標(biāo)并發(fā)的 2 倍，則會進入恐慌模式。在恐慌模式下，Autoscaler 在更短、更敏感的緊急窗口上工作	而且 HPA 本身設(shè)計比較保守，有一個穩(wěn)定期（默認(rèn)5min）默認(rèn)在5min內(nèi)沒有重新擴縮容的情況下，才會觸發(fā)擴縮容。當(dāng)大流量突發(fā)過來時，如果正處在5min內(nèi)的HPA穩(wěn)定期，這個時候根據(jù)HPA的策略，會導(dǎo)致無法擴容。

3) 按比例灰度發(fā)布

設(shè)想一下，假如通過 k8s來進行灰度發(fā)布怎么做，只能是通過兩個Deployment和兩個service，如果灰度升級的話只能通過修改兩個 Deployment 的rs，一個逐漸增加，一個逐漸減少，如果想要按照百分比灰度，只能在外部負(fù)載均衡做文章，所以要想 Kubernetes 原生實現(xiàn)，至少需要一個按流量分發(fā)的網(wǎng)關(guān)，兩個 service，兩個 deployment ，兩個 ingress ， hpa，prometheus 等，實現(xiàn)起來相當(dāng)復(fù)雜。

使用 Knative 就可以很簡單的實現(xiàn)，只需一個 ksvc 即可。