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

下圖為云計(jì)算發(fā)展的整個(gè)過(guò)程，同時(shí)也是Serverless的發(fā)展過(guò)程，共分為四個(gè)階段。

a) 物理機(jī)階段：

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

b) IaaS階段：

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

c) PaaS階段：

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

d) Serverless階段：

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

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

Serverless是什么

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

從語(yǔ)義角度理解，之所以叫無(wú)服務(wù)器計(jì)算，是因?yàn)楹蛡鹘y(tǒng)的PaaS(平臺(tái)即服務(wù))相比，用戶不需要關(guān)心服務(wù)器的部署與配置。但這并不意味著不需要服務(wù)器，只是這些東西皆由云平臺(tái)來(lái)提供。

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

Serverless 優(yōu)點(diǎn)

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

1）降本提效

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

2）安全、方便、可靠

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

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

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

下圖是CNCF 列出的 CNCF 列出的 Faas 平臺(tái)

云原生時(shí)代下的 Serverless

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

答案就是 Knative！！

Knative 是谷歌開(kāi)源的 Serverless 架構(gòu)方案，旨在提供一套簡(jiǎn)單易用的 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日才對(duì)外發(fā)布，2021 年剛發(fā)布了 1.0 版本。

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

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

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

1) 資源利用率

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

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

而 Knative，恰恰可以解決應(yīng)用A的資源占用問(wèn)題，因?yàn)?Knative 可以將實(shí)例縮容為0，并根據(jù)請(qǐng)求自動(dòng)擴(kuò)縮容，縮容到零可以大大增加集群的資源利用率，因?yàn)橹虚L(zhǎng)尾應(yīng)用都是按需所取，不會(huì)過(guò)度空占用資源。

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

2) 彈性伸縮

大家可能會(huì)想到，k8s 也有 hpa 進(jìn)行擴(kuò)縮容，但是 Knative 的 kpa 和 k8s 的 hpa 有很大的不同：

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

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

具體比較如下：

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

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

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

4) 用戶運(yùn)維復(fù)雜性

使用 Knative 免運(yùn)維，低成本：用戶只關(guān)心業(yè)務(wù)邏輯，由工具和云去管理資源，復(fù)雜性由平臺(tái)去做：容器鏡像構(gòu)建，Pod 的管控，服務(wù)的發(fā)布，相關(guān)的運(yùn)維等。

k8s 本質(zhì)上還是基礎(chǔ)設(shè)施的抽象，對(duì)應(yīng)Pod的管控、服務(wù)的發(fā)布、鏡像的構(gòu)建等等需要上層的包裝。

Knative究竟是什么，這些涉及本質(zhì)、方法、原理和實(shí)踐的問(wèn)題，需要一個(gè)權(quán)威、前沿和系統(tǒng)的回答。幸好有位大神寫(xiě)了一本書(shū)，而我們也剛剛把這本書(shū)翻譯了過(guò)來(lái)。