No.1 Serverless背景

從“硬體”到“Serverless”的變革之路

在“雲”的概念還沒有產生之前，開發者購買物理機，並在其上部署應用程式，企業將購買的機器放置資料中心，其網路、安全配置均需要專業的技術人員管理，在這種高成本運營模式下，虛擬化技術應運而生。

首先映入眼簾的是虛擬機器，依託物理機的網路、計算、儲存能力，一臺物理機上可執行多個虛擬機器，因此很大程度上提升了資源利用率。在虛擬機器成為當時的主流後，供應商想到了以程式設計的方式租用物理機，透過伺服器池釋放更大的靈活性，這些也漸漸成為了往後IaaS的基礎。在2006年8月，由AWS推出的EC2（Elastic Compute Cloud）為IaaS開闢了先河，引領了公有云的迅速發展，隨後Microsoft、Google等廠商也緊追步伐並佔據了一定的公有云市場份額，與此同時，私有云也漸漸浮出水面，其中不乏像OpenStack這樣優秀的跨時代開源平臺。

IaaS讓開發者可以按需購買伺服器資源，並靈活的部署應用程式，為開發者帶來了便利，但針對伺服器上作業系統的安裝、升級、打補丁、監控等仍需開發者管理和維護。作為開發者來講，最終目是成功的部署應用，對於伺服器的維護通常不應視為必須，為了解決這個難題，PaaS技術出現了，其執行在IaaS之上並抽象掉了硬體和作業系統細節，為應用程式提供了部署平臺，讓開發者只需關注自己的應用程式。

 Openshift、CloudFoundry開源PaaS框架在早期一度獨領風騷，後來隨著容器技術的崛起， CaaS（Container as a Service）的概念被人提出，憑藉容器輕量級、移植性強、快速部署的特點，企業漸漸將應用程式由虛擬機器遷移至容器環境中部署，並將容器託管至公有云平臺或使用開源容器編排工具Kubernetes來管理容器。

經歷了IaaS、PaaS、CaaS之後，開發者雖然已經遠離物理機執行應用程式的模式，但仍然非常依賴物理機的CPU、記憶體、儲存、網路或其它元件，即便在使用Kubernetes管理容器時，開發者也需要為容器執行時指定硬體要求，如果管理不當，將無法做適當擴充套件[7]。是否有一種模式，可讓開發者不對伺服器進行管理，在需要執行應用時伺服器啟動，不需要時將其關閉，從而可減輕開發者的負擔並專注於自己的應用實現呢？

2012年，Serverless的概念由雲基礎施服務提供商Iron.io的副總裁Ken Fromm在《Why the future of software and apps is serverless》[1]首次提出，Serverless是一種新的雲端計算模式，它並不是不需要伺服器，而是不需要開發者去管理伺服器，其責任劃分模式為雲廠商提供對伺服器的全面託管，開發者只需專注於應用程式設計，並按應用程式的執行次數向雲廠商付費。

目前公有云Serverless使用最為廣泛的為AWS Lambda，從2014年推出至今依然保持著非常高的熱度，除了AWS Lambda外，Google Cloud Functions、Miscrosoft Azure、IBM Cloud Functions也相繼推出了FaaS平臺。國內市場上，騰訊[8]、阿里[9]、華為[10]這些大廠也緊追Serverless的步伐並各自推出了雲函式解決方案。

另一方面，Serverless技術也驅動了許多開源FaaS平臺的產生，按照Github上的熱度（排名不分先後），目前主要以OpenFaaS、Fission、OpenWhisk、Knative、Kubeless為代表, 值得注意的是，隨著雲原生概念的普及和Serverless自身的特點，這些開源FaaS平臺中絕大多數都支援在Kubernetes上進行部署。

No.2 Serverless定義

2016年8月，martinfowler.com網站上發表的《Serverless》[2] 一文中對Serverless概念做了詳細闡述，簡單來說，Serverless可以理解為以下內容：

Serverless可在不考慮伺服器的情況下構建並執行應用程式和服務，它使開發者避免了基礎設施管理，例如叢集配置、漏洞修補、系統維護等。Serverless並非字面理解的不需要伺服器，只是伺服器均交由第三方管理。

Serverless通常可分為兩種實現方式，BaaS（Backend as a Service）後端即服務和FaaS（Functions as a Service）函式即服務 [6]。

1.BaaS

開發者進行移動應用開發時，後端經常遇到一些重複、複雜、費時的工作，例如針對不同移動端的推送通知、社交網站登入等，BaaS的出現解決了這些難題，BaaS主要用於將後端複雜重複的邏輯外包給第三方處理，開發者只需編寫和維護前端，所以BaaS是一種Serverless模式，下圖為Cloudflare提供BaaS示意圖[11]：

圖1 BaaS示意圖

可以看出BaaS供應商提供了各種服務端功能，例如資料庫管理、遠端更新、推送通知、雲端儲存等，而前端完全由開發者管理，前後端通訊問題透過BaaS提供的API解決。另外從上圖也可以看出，BaaS提供的服務對前端是不可見的。

BaaS公司主要為移動應用開發者提供服務，目前比較知名的公司有 Back4App, Firebase, Backendless, Kinvey等。

BaaS與SaaS的區別

透過《BaaS vs SaaS: What’s the difference? 》[3]一文中瞭解到兩者區別主要體現為以下兩點：

1、實現服務功能不同

BaaS應用程式致力於幫助開發者建立重複的程式碼功能，賣點多為特定的後端場景服務，而SaaS應用程式可以在各種場景下使用，賣點多為雲軟體，從實現功能層面看，SaaS更容易成為主流。

2、使用群體不同

BaaS專注於平臺開發，是為開發人員設計的，而SaaS是為上層使用者設計的，其提供的是現成的軟體解決方案，所以兩者的面向群體不一樣。

2.FaaS

FaaS是Serverless主要的實現方式，開發者透過編寫一段程式碼，並定義何時以及如何呼叫該函式，隨後該函式在雲廠商提供的服務端執行，全程開發者只需編寫並維護一段功能程式碼即可。

另外，FaaS本質上是一種事件驅動並由訊息觸發的服務，事件型別可能是一個http請求，也可能是一次上傳或儲存操作，事件源與函式的關係如下圖所示： 

圖2 FaaS事件源觸發示意圖

FaaS典型代表為AWS的lambda，為了便於理解，下述為一個簡單的lambda python處理函式：

import json

def lambda_handler(event, context):

# TODO implement

return {

   'statusCode': 200,

'body': json.dumps('Hello from Lambda!')
}

不難看出，這段程式碼匯入了JSON python庫並定義了一個lambda_handler函式，需要注意的是, 為了讓lambda可以識別處理函式，通常函式名稱需要遵循name_handler的格式，此外，該函式需接收兩個引數，分別為event和context，其中event引數包含此函式收到的事件源資訊，引數型別通常是python 的dict型別，也可以是list、str、int、float等型別，context引數包含此函式相關的執行時上下文資訊。

下面兩張圖分別為傳統的服務端應用部署和FaaS應用部署，我們看看FaaS有什麼不同：

圖3  傳統服務端應用部署簡易圖

圖4  FaaS應用部署簡易圖

由圖3可以看出，當應用程式部署在物理機、虛擬機器、容器中時，它實際是一個系統程式，並且由許多不同的函式構成，這些函式之間有著相互關聯的操作，一般需要長時間在作業系統中執行；圖4可看出，FaaS透過抽離虛擬機器例項和應用程式程式改變了傳統的部署模式，使開發者只關注單個操作或功能，函式在第三方託管平臺上執行，當有事件觸發時執行，開發者為使用的資源進行付費。

No.3Serverless優勢

Serverless責任劃分的原則實際已經幫助開發者降低了許多已知風險，這些都是Serverless為我們帶來的優勢，下面將從成本、風險、應用擴充套件、交付時長四個方面對Serverless的優勢進行說明。

1.降低成本

由於Serverless無需對服務端進行管理的特性，類似認證授權、系統升級、安全、程式監控、告警等操作幾乎全託管至第三方雲廠商，因此對於開發者來說就意味著更少量的運維工作。FaaS平臺的運營模式就是一個很好的例子，當建立應用時，開發者只需向FaaS平臺提供函式程式碼，對於函式對應的映象構建、函式執行時、函式啟停及應用的自動化擴充套件操作均不需要開發者參與，因此相比傳統模式，時間、開發、運維成本都將大大降低。

另外，傳統的應用程式部署在服務端，往往是非常浪費主機資源的，因為它始終線上，但實際應用程式在數天或數週中可能只會被呼叫幾次，有一些閒置數個月的應用甚至連開發者都忘記曾經部署過，Serverless設計模式擺脫了這種資源浪費，讓應用程式可以按需呼叫，因此又節省了資源成本。

2.降低風險

從安全形度而言，Serverless的設計模式實際上在一定程度上降低了安全風險。傳統模式下，我們考慮安全架構設計覆蓋方方面面，其中需要耗費極大的人力與時間成本，且需要專業的安全團隊去處理，在Serverless中，服務端的安全完全可以交由第三方雲廠商管理，而開發者只需確保自己上傳的程式碼是安全的即可。

目前，公有云廠商在各自的Serverless解決方案中均配套了相應的安全服務，比如AWS的API閘道器可以作為函式呼叫前的過濾器，過濾掉DDoS、異常引數的惡意請求等，KMS（Key Management Service）服務可以建立並管理加密金鑰，控制金鑰在Serverless函式中的使用；開源的FaaS平臺多選擇在Kubernetes上部署也是依託其豐富的安全配置。

3.自動化彈性擴充套件

資源的自動化彈性伸縮是Serverless的一大特性，且由開發者管理，在需求量達到高峰時，可透過彈性伸縮自動增加例項數量以保證效能不受影響，在需求量較低時，又可自動減少例項數量以降低成本，相比傳統的部署模式，開發者省去了手動部署的煩惱，變化的是開發者需要為增加的例項及呼叫頻次支付相應費用。

4.降低交付時長

傳統的應用交付模式需要開發人員與運維人員合力完成，其中開發週期長、人員溝通效率低下通常為阻礙交付進展的主要因素，隨著容器技術的出現，DevOps和敏捷開發在一定程度上改善了這一問題，但對於缺乏經驗的工程師仍需要幾個月的時間去交付一個專案，Serverless的出現遮蔽了容器技術這一必要條件，讓開發者只關注於函式程式碼實現，並且在數天之內就可以獨立完成交付，Serverless的這一優勢不僅大大降低了交付時長，還讓交付這一本身複雜的事情變得更容易了。

No.4Serverless侷限性

每種新技術的出現都是為了讓人類解決事情變得更簡單，但凡事都具有兩面性，Serverless的出現也必然伴隨著一定的侷限性，下面將從Serverless自身架構模式和執行時侷限性兩方面進行說明。

1.固有侷限性

雖然Serverless作為一種雲端計算模式應用非常廣泛，但在使用場景上還是有一定的侷限性，CNCF釋出的Serverless白皮書v1.0版本中[4]對Serverless的使用場景進行了介紹，如下圖所示：

圖5  CNCF Serverless使用場景

由上圖我們可以看出Serverless比較適用於非同步併發、短暫、無狀態的應用的場景，並且Serverless一直秉持著節約成本的原則，因此也適用於應對突發或服務使用量不可預測的場景。

下面我們對Serverless固有侷限性分別進行說明。

不適用於有狀態服務

為了滿足“雲”的特點—— 靈活自行擴縮容，Serverless為無狀態應用提供了執行平臺，對於像資料庫這種有狀態的服務是不易在Serverless上部署的，即使部署成功也喪失了靈活性，因此Serverless天然不適於部署有狀態的應用。

目前針對Serverless函式涉及資料儲存主要透過公有云廠商各自的儲存服務實現，比如AWS Lambda可將資料儲存至S3、DynamoDB、Kinesis、SNS等服務中。

延遲高

傳統的應用程式元件間通訊可透過資料格式、網路協議、地理位置進行最佳化，但Serverless固有的設計模式使得應用程式天然具備高度分散式、低耦合的特徵，這種模式下應用程式間如果涉及通訊，必然會帶來延遲，並且延遲會隨應用程式的增加而增加。

本地測試受限

Serverless將許多基礎設施從平臺內部抽離出來，這種設計模式雖然給開發者減輕了服務端的工作量，但也同時增加了本地測試難度，尤其對於服務端的模擬常常是一件棘手的事情，另外Serverless分散式的特點也使應用程式的測試變得困難。

2.執行時侷限性

FaaS平臺作為Serverless的主要實現模式在執行時也具有一定的侷限性，像冷啟動、供應商鎖定、開發和安全工具限制等。

冷啟動

目前，許多像AWS Lambda、Google Cloud Functions、Microsoft Azure Functions等FaaS平臺都面臨冷啟動的問題，冷啟動主要分兩種，第一種是開發者將應用部署完成後，從某個函式進行第一次呼叫到該函式被執行期間的這段延遲，具體的講，這段延遲主要指第三方雲廠商將函式打包成映象並執行為容器所花費的初始化時間；第二種是函式經歷第一次呼叫後很長時間再次被呼叫時例項化所花費的時間。

冷啟動到底有多慢呢？各大雲廠商均提供了各自官方的冷啟動持續時間，雖然每家都聲稱自己很快，但為了準確性，下面參照了國外一篇熱度非常高的針對冷啟動研究的文章《Comparison of Cold Starts in Serverless Functions across AWS, Azure, and GCP》[5], 其中作者透過對AWS Lambda, Azure Functions, Google Cloud Functions三家FaaS平臺提供的常見語言冷啟動時間進行了比較，其中顏色較暗範圍為啟動執行時花費時間，顏色較亮範圍為總共持續時間如下圖所示：

圖6  主流公有云FaaS平臺常用語言冷啟動時間對比圖1

可以看出，AWS Lambda以絕對優勢領先於其它廠商，冷啟動持續時間均低於1秒，Google Cloud Functions啟動通常需要1至4秒，Azure Functions啟動執行時時長與Google Cloud Functions幾乎一樣，但Azure Functions整體的冷啟動時長較慢，平均下來也基本在8至9秒左右。

冷啟動的快慢也與部署檔案大小有著緊密聯絡，在《Comparison of Cold Starts in Serverless Functions across AWS, Azure, and GCP》文章中，作者透過增加部署檔案的大小測試了冷啟動延遲時間對比，如下圖所示：

圖7  主流公有云FaaS平臺常用語言冷啟動時間對比圖2

可以看出冷啟動時間隨部署檔案大小的增加呈穩步上升趨勢，AWS Lambda同樣在這次比較中以絕對優勢獲勝。

針對冷啟動問題，各大雲廠商都在積極應對。目前公有云FaaS平臺通常的處理思路為函式被首次呼叫後，應用例項將保持一段時間的活動狀態再被回收，這樣優點是對後續請求可進行持續響應並減少不必要的冷啟動，缺點是可能會造成一定的資源浪費，所以雲廠商也試圖在這兩者之間做權衡。

供應商鎖定

由於各大廠商均有各自的Serverless解決方案，且各自的基礎架構元件都不一樣，這樣就會導致開發者在A供應商使用的Serverless功能可能無法平滑遷移至B供應商，例如開發者使用AWS Lambda，透過DynamoDB來處理資料，也許AWS Lambda和Microsoft Azure Functions之間區別不大，但是很難將Microsoft Azure Functions的東西遷移至AWS Lambda上，所以想要完成適配，就得需要一套標準，但該標準的建立非常難，因為可能需要對整個基礎架構進行遷移，如果沒有一個完美的理由或利益驅動，各大雲廠商是很難達成共識的。

安全工具限制

所謂術業有專攻，傳統的應用程式在部署完成後有專業的Web應用防火牆，入侵檢測及防護裝置對其進行防護，但在Serverless中這些安全裝置功能卻因供應商鎖定問題全部由雲廠商實現了，第三方安全裝置很難整合至服務端，所以開發者不得不依賴服務端的安全機制，這也是傳統安全裝置在Serverless環境中的侷限性所在。

No.5總結

Serverless作為一種新的雲端計算模式，具有諸多優點，在過去幾年積累了一大批擁簇者，在開發者享受新技術為其帶來便利的同時也對實用性提出了新的要求和挑戰，尤其在FaaS平臺中，我們要清楚在這當中既有寶藏 ——良好的伸縮性和低成本；也有廢墟——本地除錯和冷啟動。

當然，技術也是不斷進展的，面對Serverless現有的侷限性，各大雲廠商也在努力改進。例如，Serverless的監控能力在幾年前較弱，如今各大雲廠商已經有了各自的監控服務，AWS Lambda的CloudWatch，Azure Function的Azure Monitor ，Google Cloud Functions的Google Stackdriver等均受到了開發者的一致好評；而開源FaaS平臺像Fission v1.0版本已支援Opentracing和Jaeger，Openfaas也啟動了對Prometheus的支援。所以，有些瓶頸一定只是暫時的，不因噎廢食是對新技術的態度。

    ·    參考連結    ·    

[1]https://readwrite.com/2012/10/15/why-the-future-of-software-and-apps-is-serverless/

[2]https://martinfowler.com/bliki/Serverless.html

[3]https://medium.com/@george_51059/baas-vs-saas-whats-the-difference-back4app-blog-195f9b3d3e2#:~:text=BaaS%20is%20focused%20specifically%20on,a%20wide%20range%20of%20situations

[4]https://github.com/cncf/wg-serverless/raw/master/whitepapers/serverless-overview/cncf_serverless_whitepaper_v1.0.pdf

[5]https://mikhail.io/serverless/coldstarts/big3/

[6]https://mp.weixin.qq.com/s/hTi1HmYjYO3BN_hUwvEH0A

[7]OReilly Serverless Security

[8]https://cloud.tencent.com/product/scf

[9]https://serverless.aliyun.com/

[10]https://www.huaweicloud.com/product/functionstage.html

[11]https://www.cloudflare.com/img/learning/serverless/glossary/backend-as-a-service-baas/what-is-backend-as-a-service.svg