Serverless的相關知識點有哪些

這篇文章主要介紹“Serverless的相關知識點有哪些”的相關知識，小編通過實際案例向大家展示操作過程，操作方法簡單快捷，實用性強，希望這篇“Serverless的相關知識點有哪些”文章能幫助大家解決問題。

Serverfull 到 Serverless 的演變

上圖是 MVC 架構的 Web 應用部署之后的典型情況。上圖中的整個藍色部分就是服務端的邊界，它是負責應用或代碼的線上運維。而 Serverless  要解決的問題的邊界就是服務端的邊界，也就是服務端運維。

那么下面我們先來看一下服務端運維的發展史，也就是從一開始到 Serverless 的發展史。假設有一個 Web 應用，這個 Web  應用的研發涉及到兩個角色：研發工程師和運維工程師。研發工程師只關心應用的業務邏輯。具體來說就是，整個 MVC 架構 Web  應用的開發都歸他負責，也就是從服務端界面 View 層，到業務邏輯 Control 層，再到數據存儲 Model 層，整個 Web 應用的版本管理和線上 bug  修復都歸研發工程師。運維工程師則只關心應用的服務端運維事務。他負責部署上線小程的 Web  應用，綁定域名以及日志監控。在用戶訪問量大的時候，他要給這個應用擴容;在用戶訪問量小的時候，他要給這個應用縮容;在服務器掛了的時候，他還要重啟或者換一臺服務器。

• Serverfull  時代。最開始的時候，研發工程師不用關心任何部署相關的事情。研發工程師每次發布新的應用后，運維工程師都負責部署上線最新的代碼。運維工程師需要管理好迭代版本的發布，分支合并，將應用上線，遇到問題回滾。如果線上出了故障，還需要抓取日志發給研發工程師。

Serverfull  時代將研發和運維完全隔離開來了。這種完全隔離開來的好處很明顯：研發工程可以專心做好自己的業務，但是運維工程師就成了工具人了，就困在大量的運維工作中，處理大量瑣碎的雜事。

• DevOps  時代。運維工程師發現有很多事情都是重復性的工作，線上出故障了還得自己抓日志發給研發工程師，效率很低。因此運維工程師就開發了一套運維控制臺，將部署上線和日志抓取的工作讓研發工程師處理。

這樣，運維工程師可以稍微輕松點了，但是優化架構和擴縮容資源方案還是得負責。而研發工程師除了開發的任務，還要自己通過運維控制臺發布新版本和解決線上故障。這個時候是研發兼運維  DevOps，研發工程師兼任了部分運維工程師的工作，但是這部分的工作就應該是研發工程負責的(比如版本控制、線上故障等)，而且運維工程師將這部分工作工具化了，更加高效了，有  less 的趨勢了。

• 工業時代。運維工程師又基于研發工程師的開發流程，將運維控制臺進一步提升，可以實現代碼自動發布：代碼掃描-測試-灰度驗證-上線。這樣一來，研發工程師只需要將最新的代碼合并到  Git 倉庫指定的 develop 分支，剩下的就由代碼自動發布的流水線來負責了。這個時候研發工程師也不需要運維了，免運維  NoOps，研發工程師也就回到了當初，只需要關心自己的應用業務就可以了。

同時，運維工程師發現資源優化和擴縮容方案也可以利用性能監控+流量估算解決。這樣運維工程師的運維工作也全都自動化了。那么對于研發工程師來說，運維工程師的存在感越來越弱，需要運維工程師干的事情越來越少，都由自動化工具替代了。這就是  Serverless。

• 未來。實現了免運維之后，運維工程師要轉型去做更底層的服務，做基礎架構的建設，提供更加智能、更加節省資源、更加周到的服務。而研發工程師可以完全不被運維的事情困擾，專注做好自己的業務，提升用戶體驗，思考業務價值。

免運維 NoOps 并不是說服務端運維就不存在了，而是通過全知全能的服務，覆蓋研發部署需要的所有需求，讓研發工程師對它的感知越來越少。另外，NoOps  是理想狀態，因為我們只能無限逼近 NoOps，所以說是 less，而不是 ServerZero。

Serverless 的 Server 限定了 Serverless 解決問題的邊界，即服務端運維;less 說明了 Serverless  解決問題的目的，即免運維 NoOps。所以，Serverless 應該叫做服務端免運維，這也就是 Serverless 要解決的問題。

什么是 Serverless

Serverless  要解決的就是將運維工程師的工作徹底透明化;而研發工程師只關心業務邏輯，不用關心部署運維和上線的各種問題。而要實現這種狀態，那么就意味要對整個互聯網服務端的運維工作進行極端抽象。而越抽象的東西，由于蘊含的信息量越大，所以越難定義。

但是，總的來說 Serverless 的含義有這兩種：

• 狹義 Serverless(最常見)是指 Serverless computing 架構 = FaaS 架構 =  Trigger(事件驅動)+FaaS(Function as a Service，函數即服務)+BaaS(Backend as a  Service，后端即服務，持久化或第三方服務)=FaaS + BaaS。

• 廣義 Serverless 是指服務端免運維，也就是具有 Serverless 特性的云服務。

狹義的 Serverless

我們日常工作提到的 Serverless 都是指狹義的 Serverless。

而這主要是因為歷史原因，2014 年 11 月份，亞馬遜推出了真正意義上的第一款 Serverless FaaS  服務：Lambda。從此，Serverless 的概念才進入大多數人的視野，因此 Serverless 曾經一度就等于  FaaS。FaaS，函數即服務，它還有個名稱叫作 Serverless Computing，它可以讓我們隨時隨地創建、使用、銷毀一個函數。

通常函數的使用過程：需要先從代碼加載到內存，也就是實例化，然后被其他函數調用時執行。FaaS 中也是一樣的，函數也需要實例化，然后被觸發器 Trigger  調用。這兩個最大的區別就是在 Runtime，也就是函數的上下文。FaaS 的 Runtime  是預先設置好的，都是云服務商提供的，我們可以使用但是無法控制。并且 FaaS 的 Runtime 是臨時的，當 FaaS  的函數調用完之后，云服務商就會銷毀這個實力，回收資源，也就意味著這個臨時的 Runtime 會和函數一起銷毀。因此，FaaS  推薦無狀態的函數，也就是一個函數只要參數固定，那么返回的結果也必須是固定的。

那么將一開始的 MVC 架構的 Web 應用變成 Serverless 的話，那應該是怎樣的呢?View  層是客戶端展示的內容，通常并不需要函數算力;Control 層，就是函數的典型使用場景。在 MVC 架構中，一個 HTTP 的數據請求往往對應著一個  Control 函數，因此這個 Control 函數完全可以被 FaaS 函數代替。在 HTTP 的數據請求量大的時候，FaaS  函數會自動擴容多實例同時運行;在 HTTP 的數據請求量小的時候，又會自動縮容;當沒有 HTTP 請求的時候，還會縮容至 0 實例。如下圖所示：

Control 函數變成了無狀態的，并且函數的實例在不停地擴容縮容，那么此時想要持久化一些數據怎么辦?當然 Control  函數中還是可以以操作數據庫的命令方式來實現。但是，這種方式并不合理，因為 Control 層的方式變了，假如 Model  層還是以之前的那種方式，那么這種架構肯定是要散架。此時，就需要 BaaS 了，也就是將 Model 層進行 BaaS 化，BaaS 就是專門配合 FaaS  用的。下面 Model 層以 MySQL 為例，Model 層最好將操作數據庫的命令封裝成 HTTP 的 OpenAPI，提供給 FaaS 調用，自己控制這個  API 的請求頻率以及限流降低等。這個 Model 層本身則可以通過連接池、MySQL 集群等方式去優化。如下圖所示：

至此，基于 Serverless 架構，傳統的 MVC 架構完完全全被轉化為了 View + FaaS + BaaS 的組合了。Serverless  毋庸置疑是因為 FaaS 架構才流行起來的。我們常見的 Serverless 都是指 Serverless Computing 架構，也就是由  Trigger、FaaS、BaaS 架構組成的應用。

廣義的 Serverless

廣義的 Serverless 其實就是指服務端免運維，也是未來的趨勢。要想達到 NoOps，需要具備：

• 無需用戶關心服務端的事情(容錯、容災、安全驗證、自動擴縮容、日志調試)

• 按使用量(調用次數、時長等)付費，低費用和高性能并行，大多數場景下節省開支。

• 快速迭代&試錯能力(多版本控制、灰度、CI&CD 等等)。

為什么需要 Serverless 呢

在 2009 年的時候，有兩種相互競爭的云虛擬化方法：

• Amazon EC2，EC2 實例看起來很像物理硬件，用戶可以從內核向上控制整個軟件棧。

• Google App Engine，是另一個針對特定領域的應用平臺，它是一種將 stateless 計算層和 stateful  的存儲層分類開來的一種應用程序結構。

最終市場使用了 Amazon 這種針對云計算的 low-level 虛擬機方式，而這種 low-level  虛擬機成功的主要原因是，早起的云計算用戶希望在云中可以重新創建一個與本地計算機上相同的計算環境，以簡化將其負載遷移到云上的工作。很明顯，這種實際需求比為云重新編寫新的程序更重要，尤其是在當時云計算能否成功尚不明確的情況下。

然后這種方式的缺點是，開發人員必須自己管理虛擬機，所以要么成為系統管理員，要么與它們一起設置環境。這些促使那些只使用簡單化應用的客戶向云服務商提出新要求，希望能有更簡單的方式來運行這些簡單應用。例如，假設應用希望將圖片從手機端應用發送到云上，這需要創建極小的圖片并將其放在  web 上，完成這個任務可能只需要幾十行 JavaScript 代碼，這與設置適當的服務器環境來運行這段代碼相比，這個代碼的開發是很微不足道的。

在這些需求的驅使下，Amazon 在 2015 年推出了一個名為 AWS Lambda service  的新服務。用戶只需要編寫代碼，服務器供應和任務管理問題都由服務提供商來負責。編寫的代碼被打包為 FaaS(Function as a service)，代表了  Serverless 計算的核心，但是云平臺還提供了專門的 Serverless 框架，以滿足特定的程序需求，如 BaaS(Backend as a  Service)。簡單地說，無服務計算定義如下：Serverless Computing = FaaS +  BaaS。同時，服務被視為無服務的話，那么必須能夠自動擴縮容，并且根據實際使用情況計費。

★Cloud functions (i.e., FaaS) provide general compute and are complemented by  an ecosystem of specialized Backend as a Service (BaaS) offfferings such as  object storage, databases, or messaging.

”Serverless VS Serverful

在 Serverless  中，用戶只需要使用高級語言編寫云函數，選擇觸發云函數運行的事件就可以了。例如，加載一個圖像到云存儲中，或者向數據庫添加一個很小的圖片時，用戶只需要編寫相應的代碼，而剩下的全都由  Serverless 系統來處理，比如選擇實例、擴縮容、部署、容錯、監控、日志、安全補丁等等。下面，總結了 Serverless  和傳統方式的差異，我們將傳統方式稱為 Serverful。

Serverless 和 Serverful計算最關鍵的三個不同之處在于：

1. **將計算與存儲解耦。**存儲和計算資源是分開提供的，相當于這兩種資源的分配和計價都是獨立的，通常來說存儲資源是由一個獨立的云服務來提供的，并且計算是無狀態的。

2. **執行代碼而不需要管理資源分配。**與傳統云計算用戶需要請求資源的方式不同，serverless  是用戶提交一段代碼，云會自動給這段代碼分配資源并執行。

3. **以實際使用的資源量付費，而不是根據分配的資源數。**serverless  計費是根據一系列與執行相關的因素來計算的，例如代碼的執行時間，而不實根據云平臺，例如分配的 VM 的大小和數量

假如使用匯編語言和高級語言來形容的話，Serverful 計算類似于使用低級匯編語言進行編程，而 Serverless 計算類似于使用高級語言(例如  python)進行編程。例如，c = a + b 的簡單表達式的匯編程序員必須顯示選擇一個或者多個寄存器，將值加載到這些寄存器中，執行運算，然后存儲結果。這跟  Serverful  云編程的幾個步驟是類似的：首先提供資源或者標識可用的資源，然后用必要的代碼和數據加載這些資源，執行計算，返回或者存儲結果，最終管理資源釋放。而  Serverless 則提供了類似于高級編程語言的便捷性，Serverless 和高級編程語言也很相似性。比如，高級語言的自動內存管理不用再管理內存資源，而  Serverless 計算使程序員也不用再管理服務器資源。

Attractiveness of Serverless Computing

對云服務提供商來說

• Serverless 可以促進業務的增長，因為它使得云計算更容易編程，進而有助于吸引新客戶并幫助現有客戶更多地使用云計算。例如，最近的調查發現，大約  24% 的 Serverless 計算用戶是云計算的新用戶，30% 現有的 serverful 用戶也使用了 Serverless 計算。

• 短的運行時間、較小的內存占用和無狀態特性使得云提供商更容易找到那哪些未使用的資源來運行這些任務，從而改進了資源復用。

• 可以利用不太流行的計算機(實例類型由云提供商決定)，比如對 serverful 云客戶吸引較小的舊服務器。

★后面的兩點可以最大化現有的資源并提高收益。”

對用戶來說

• 從編程效率的提高中獲益，對于新手來說不需要理解云基礎設施的前提下部署函數，老用戶可以節省出部署的時間并聚焦于應用本身的問題。

• 節約成本，因為云服務提供商將底層服務器的利用率提高了，并且函數只有在事件發生時才會計費，而且是細粒度的計費(通常是 100  毫秒)，那么也就意味著只需要支付他們實際使用的部分而不是為他們預留的部分。

FaaS 是怎么運行的

在 Serverless 出現之前，我們要部署這樣一個"Hello World"應用得何等繁瑣。

1. 我們要購買虛擬機服務;

2. 初始化虛擬機運行環境，安裝我們需要的應用運行環境，盡量和本地開發環境保持一致;

3. 緊接著為了讓用戶能夠訪問我們剛剛啟動的應用，我們需要購買域名，用虛擬機 IP 注冊域名，配置 Nginx，啟動 Nginx;

4. 最后我們還需要上傳應用代碼;

5. 啟動應用;

采用 Serverless 之后，只需要簡單的 3 步。Serverless 相當于對服務端運維體系進行了極端的抽象(抽象意味著用戶請求 HTTP  數據請求的全鏈路，并沒有質的改變，只是將全鏈路的模型簡化了)。

• 之前在服務端構建代碼的運行環境---函數服務

• 之前需要負載均衡和反向代理--- HTTP 函數觸發器

• 上傳代碼和啟動應用---函數代碼

整個啟動過程如下圖所示：

• 用戶第一次訪問 HTTP 函數觸發器時，函數觸發器會 Hold 住用戶的 HTTP 請求，并產生一個HTTP Request 事件通知函數服務;

• 函數服務檢查有沒有閑置的函數實例，如果沒有函數實例，則去函數代碼倉庫拉取你的代碼，初始化并啟動一個函數實例;之后再傳入 HTTP Request  對象作為函數的參數，執行函數。

• 函數執行的結果 HTTP Response 返回函數觸發器，函數觸發器再將結果返回給等待的用戶客戶端。

★FaaS 和 PaaS 平臺對比，最大的區別在于資源利用率。這也是 FaaS 最大的創新點，FaaS 的應用實例可以縮容到 0，而 PaaS  平臺至少要維持一臺服務或容器。這主要是因為 FaaS 可以做到極速啟動函數實例，而 PaaS  創建實例通常需要幾十秒，為了保證你的服務可用性，必須一直維持至少一臺服務器運行你的應用實例。

FaaS 的極速啟動

FaaS  中的冷啟動是指從調用函數開始到函數實例準備完成的整個過程。冷啟動關注的是啟動時間，啟動時間越短，對資源的利用率就越高。現在的云服務商，基于不同的語言特性，冷啟動平均耗時基本在  100～700 毫秒之間。

下面這張圖是 FaaS  應用冷啟動的過程。其中，藍色部分是云服務商負責的，紅色部分是用戶負責的。云服務商會不停地優化自己負責的部分，畢竟啟動速度越快對資源的利用率就越高，例如冷啟動過程中耗時較長的是下載函數代碼。所以一旦你更新代碼，云服務商就會偷偷開始調度資源，下載你的代碼構建函數實例的鏡像。請求第一次訪問時，云服務商就可以利用構建好的緩存鏡像，直接跳過冷啟動的下載函數代碼步驟，從鏡像啟動容器，這個也叫預熱冷啟動。除此之外，還有預留實例策略也可加速或繞過冷啟動時間。

★FaaS 服務從 0 開始，啟動并執行完一個函數，只需要 100 毫秒。這也是為什么 FaaS 敢縮容到 0  的主要原因。通常我們打開一個網頁有個關鍵指標，響應時間在 1 秒以內，都算優秀。這么一對比，100  毫秒的啟動時間，對于網頁的秒開率影響真的極小。”為什么應用托管平臺 PaaS 做不到極速啟動呢?因為應用托管平臺 PaaS  為了適應用戶的多樣性，必須支持多語言兼容，還要提供傳統后臺服務，例如 MySQL、Redis。這也就意味著，PaaS  在初始化環境時，有大量依賴和多語言版本需要兼容，而且兼容多種用戶的應用代碼往往也會增加應用構建過程的時間。

而 FaaS 設計之初就犧牲了用戶的可控性和應用場景，來簡化代碼模型，并且分層結構進一步提升了資源的利用率。

FaaS 的分層

FaaS 實例執行時，就如下圖所示，至少是 3 層結構：容器、運行時 runtime、具體的函數代碼。

• 目前的 FaaS 實現方案中，容器方案可能是 Docker 容器、VM 虛擬機，甚至 Sandbox 沙盒環境。

• 運行時 Runtime，就是你的函數執行時的上下文 context。Runtime 的信息包括代碼運行的語言和版本，例如 Node.js  v10，Python3.6;可調用對象，例如 aliyun SDK;系統信息，例如環境變量等等。

這樣分層的好處就是，容器層適用性更廣，云服務商可以預熱大量的容器實例，將物理服務器的計算碎片化。Runtime 的實例適用性較低，可以少量預熱。容器和  Runtime 固定后，下載你的代碼就可以執行了。通過分層，我們就可以做到資源統籌優化，讓你的代碼快速低成本地被執行。

另外，一旦容器 & Runtime  啟動后，就會維持一段時間，這段時間內的這個函數實例就可以直接處理用戶數據請求。當一段時間內沒有用戶請求事件發生(各個云服務商維持實例的時間和策略不同)，則會銷毀這個函數實例。

FaaS 進程模型

從運行函數實例的進程角度來看，有兩種模型：

用完即毀型：函數實例準備好后，執行完函數就直接結束。FaaS 最純正的用法。

常駐進程型：函數實例準備好后，執行完函數不結束，而是返回繼續等待下一次函數被調用。即使 FaaS  是常駐進程型，如果一段時間沒有事件觸發，函數實例還是會被云服務商銷毀。

★從下面這張圖其實可以看到觸發器就是一個常駐進程模型，只不過這個觸發器由云服務商處理罷了。”

假設我們要部署的是一個 MVC 架構的 Web 服務，那么：

• 在之前，假設沒有 FaaS，我們要將應用部署到托管平臺 PaaS 上;啟動 Web 服務時，主進程初始化連接  MongoDB，初始化完成后，持續監聽服務器的 80 端口，直到監聽端口的句柄關閉或主進程接收到終止信號;當 80 端口和客戶端建立完 TCP 鏈接，有  HTTP 請求過來，服務器就會將請求轉發給 Web 服務的主進程，這時主進程會創建一個子進程來處理這個請求。

• 而在 FaaS 常駐進程型模式下，首先我們要改造一下代碼，Node.js 的 Server 對象采用 FaaS Runtime 提供的 Server  對象;然后我們把監聽端口改為監聽 HTTP 事件;啟動 Web 服務時，主進程初始化連接 MongoDB，初始化完成后，持續監聽 HTTP  事件，直到被云服務商控制的父進程關閉回收。

當 HTTP 事件發生時，我們的 Web 服務主進程跟之前一樣，創建一個子進程來處理這個請求事件。主進程就如我們上圖中繪制的那個藍色的圓點，當 HTTP  事件發生時，它創建的子進程就是藍色弧形箭頭，當子進程處理完后就會被主進程回收。

通過上面的例子，可以看到：常駐進程型就是為了傳統 MVC 架構部署上 FaaS 專門設計的(顯得很不自然，FaaS  原生的還是用完即毀型)。當然也可以使用用完即毀型來部署 MVC 架構的 Web 服務，但是不推薦這么做，因為用完即毀型對傳統 MVC 改造的成本太大。

★從可控性和改造成本角度來看 Web 服務，服務端部署方案最適合的還是托管平臺 PaaS 或者自己搭服務跑在 IaaS 上。正如我上一講所說，使用  FaaS 就必須在 FaaS 的條件限制內使用，最佳的做法應該是一開始就選用 FaaS 開發。”用完即毀型適用的場景：數據編排和服務編排。

數據編排

目前最成功最廣泛的設計模式就是 MVC 模式。但隨著前端 MVVM 框架越來越火，前端 View 層逐漸前置，發展成 SPA 單頁應用;后端  Control 和 Model 層逐漸下沉，發展成面向服務編程的后端應用。這種情況下，前后端更加徹底地解耦了，前端開發可以依賴 Mock  數據接口完全脫離后端限制，而后端的同學則可以面向數據接口開發，但這也產生了高網絡 I/O 的數據網關層。

Node.js 的異步非阻塞和 JavaScript 天然親近前端工程師的特性，自然地接過數據網關層。因此誕生了 Node.js 的 BFF 層  (Backend For Frontend)，BFF  層充當了中間膠水層的角色，粘合前后端。將后端數據和后端接口編排，適配成前端需要的數據結構，提供給前端使用。

★未經加工的數據，我們稱為元數據 Raw  Data，對于普通用戶來說元數據幾乎不可讀。所以我們需要將有用的數據組合起來，并且加工數據，讓數據具備價值。對于數據的組合和加工，我們稱之為數據編排。”

BFF 層通常是由善于處理高網絡 I/O 的 Node.js 應用負責。傳統的服務端運維 Node.js  應用還是比較重的，需要我們購買虛擬機，或者使用應用托管 PaaS 平臺。但是，由于 BFF 層只是做無狀態的數據編排，所以我們完全可以用 FaaS  用完即毀型模型替換掉 BFF 層的 Node.js 應用，也就是最近圈子里老說的 SFF(Serverless For Frontend)。

現在我們再串下新的請求鏈路邏輯。前端的一個數據請求過來，函數觸發器觸發我們的函數服務;我們的函數啟動后，調用后端提供的元數據接口，并將返回的元數據加工成前端需要的數據格式;我們的  FaaS 函數完全就可以休息了。

• 服務編排

服務編排和數據編排很像，主要區別是服務編排是對云服務商提供的各種服務進行組合和加工(也就是說服務商提供了一些 API ，我們對這些 API  進行整合來實現我們想要的功能)。

在 FaaS 出現之前，就有服務編排的概念，但服務編排受限于服務支持的 SDK 語言版本。我們要使用這些服務或  API，都要通過自己熟悉的編程語言去找對應的 SDK，在自己的代碼中加載 SDK，使用秘鑰調用 SDK 方法進行編排。如果沒有  SDK，則需要自己根據平臺提供的接口或協議實現 SDK。

但是，有了 FaaS 之后，我們就方便很多了。假如我們服務商沒有給我們提供我們熟悉的語言的  SDK，那么我們可以使用其他語言編寫一個編排的程序，這個編排的程序會對服務商的服務進行編排。之后，我們再去調用這個編排的程序即可，而這個編排的程序就可以使用用完即毀的方式。比如，我們的  Web 服務需要發送驗證碼郵件。我們查看阿里云的郵件服務文檔，發現阿里云只提供了 Java、PHP 和 Python 的 SDK，而沒有 Node.js 的  SDK。這個時候，我們可以參考郵件服務的 PHP 文檔，就用 PHP 的 SDK 創建一個 FaaS 服務來發送郵件(發送郵件的功能是很單一的)。

這個也是 FaaS 的一個亮點：語言無關性。它意味著你的團隊不再局限于單一的開發語言了，你們可以利用 Java、PHP、Python、Node.js  各自的語言優勢，混合開發出復雜的應用。FaaS 服務編排被云服務商特別關注正是因為它具備的這種開放性。使用 FaaS  可以創造出各種各樣復雜的服務編排場景，而且還與語言無關，這大大增加了云服務商各種服務的使用場景。當然，這對開發者也提出了要求，它要求開發者去更多地了解云服務商提供的各種服務。

關于“Serverless的相關知識點有哪些”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識，可以關注億速云行業資訊頻道，小編每天都會為大家更新不同的知識點。