隨著2014年AWS Lambda的發布和流行，近年來有關Serverless的話題和討論越來越頻繁。究竟什么是Serverless?為什么需要Serverless? Serverless是否意味著從此不再需要服務器了？Serverless究竟能為開發運維帶來哪些便利呢?

[[215205]]

回溯本源

讓我們先來回顧一下常見的應用服務開發上線流程。

一、直接使用物理設備

開發者將應用程序開發測試完畢后，直接將程序和相關軟件部署在物理設備上。服務器直接使用物理機。這種方式將不可避免地需要大量人工運維和重復勞動。比方說，用戶數量逐漸增長時，我們需要擴容物理設備以應對更高的網站訪問壓力。這時候我們需要購置更多的物理服務器，并且搬運到機房的對應機架機柜中。然后，我們需要手動為新購置的物理服務器安裝各種運行軟件，填寫好配置文件，手動部署啟動好需要運行的應用程序。這些大量的重復運維勞動造成產品上線慢，迭代周期長。其次，使用物理設備直接部署應用程序將導致資源浪費。如今的物理服務器的配置越來越強大，64核128G在今天看來也不過是普通配置。很難想象你買了一臺32核的物理機，卻只想搭建個人博客。此外，電商行業經常為了應對促銷秒殺等活動準備大量的物理資源，然而在非促銷等流量低谷時段，大量物理資源處理閑置狀態，不利于節約成本。

最后，為了解決資源浪費的問題，我們很容易想到，可以將多個應用程序部署在同一臺服務器上來充分利用資源。但由此又導致了新的麻煩，不同的應用程序經常會搶占CPU，磁盤IO，內存，難以做到隔離資源，各行其是，互不干擾。

二、IaaS托管硬件

虛擬化技術的成熟直接解決了上述直接使用物理設備的幾個痛點。

首先，使用IaaS平臺，服務器由物理機變成了虛擬機。申請服務器資源僅需要調用IaaS平臺的API或者點擊控制臺頁面就可以輕松完成。CPU個數，內存大小，網絡帶寬，存儲磁盤大小都可以按需指定，隨心所欲。虛擬機被玩壞了也不需要重裝系統修復，刪除重建新虛擬機即可。擴容服務器不再需要大量的重復人工運維勞動，加速了產品上線和迭代。

其次，使用IaaS平臺一定程度上減輕了資源浪費。在IaaS平臺上很容易申請和刪除虛擬機，升降帶寬配置等操作，這樣當業務低谷時段直接刪除多余的虛擬機，降低帶寬購買配額，就能節約不少成本。

最后，IaaS平臺解決了資源隔離的問題。不同虛擬機之間有獨立CPU，內存，磁盤，網卡，不同虛擬機之間的程序不會進行資源搶占。

然而，IaaS平臺僅僅為開發者做好了硬件托管的工作。開發者依然需要為虛擬機安裝操作系統和各種軟件，填寫配置并部署應用;依然需要關注服務器，帶寬，存儲等資源的使用量和擴容縮容。此外，IaaS平臺沒有完全解決資源浪費的問題，實際上，大量虛擬機在日常運行中依然存在超低負載運行的情況。

三、 PaaS托管應用

使用PaaS平臺，開發者無需關注服務器的申請采購、系統安裝和資源容量。PaaS服務提供商為開發者提供好了操作系統和開發環境以及支持的SDK和API，還能自動調整資源來幫助應用服務更好的應對突發流量。有了PaaS平臺，開發者僅僅需要把應用開發好，然后在PaaS平臺完成服務部署，應用服務即可上線。

相比IaaS平臺，PaaS平臺能更加精準地為應用程序所消耗的資源計費。IaaS平臺僅僅依據用戶申請的資源量，如CPU核心數，網絡帶寬來計費，而不關注用戶是否實際真正充分使用到了其所申請到的資源。PaaS平臺則可以通過統計應用程序所占用的CPU使用率和內存使用率來做的更精準的計費，甚至可以實現應用層面的計費，比如服務響應時間，或者應用所消耗的事務。

1. 什么是Serverless?

Serverless指的是由開發者實現的服務端邏輯運行在無狀態的計算容器中，它由事件觸發， 完全被第三方管理，其業務層面的狀態則被開發者使用的數據庫和存儲資源所記錄。

以上圖為例，圖中上半部分描述的是互聯網應用傳統架構的模型：用戶客戶端APP與部署在服務器端的常駐進程通信，服務端進程處理該應用的大部分業務邏輯流程。下半部分則描述了Serverless架構模型。與傳統架構模型最大的不同在于，互聯網應用的大部分業務邏輯流程被轉移到客戶端上，客戶端通過調用第三方服務接口來完成諸如登錄、鑒權、讀取數據庫等通用業務場景;高度定制化的業務邏輯則通過調用第三方FaaS平臺執行自定義代碼來完成。總體上看，Serverless架構將傳統架構中的服務器端的整串后臺流程拆分成在客戶端上執行一個個第三方服務調用或FaaS調用。

回顧之前所述，無論是直接使用物理服務器設備部署程序，還是基于IaaS平臺托管硬件，或者使用PaaS平臺托管應用，開發部署互聯網應用都離不開傳統的客戶端-服務器模式，即客戶端向服務端發送請求，服務器運行處理各種業務邏輯，并響應來自客戶端的請求。至于物理機，IaaS乃至PaaS，歸根結底只是服務器程序的部署模式不同。

而在Serverless架構中，軟件開發者和運維工程師們不在需要關心服務器的部署、架設、伸縮，這些問題交給云平臺商來解決，程序員們得以將精力投入用代碼來實現業務邏輯中，而不是管理服務器。Serverless并不意味著不再需要服務器了，只是服務器資源的申請、使用、調度、伸縮由云服務商自動實現，應用開發者無需關心。

2. Serverless如何工作?

以一個簡單需求為例，論壇網站需要對用戶上傳的圖片生成一個縮略圖。

我們使用UCloud的通用計算(UGC)來實現該功能。

如上圖所示，使用UGC實現這一功能操作步驟如下：

• 用戶將縮略圖算法代碼打包推送到UGC算法倉庫中;
• 用戶從UFile中讀取原始圖片作為輸入數據，調用UGC SubmitTask API，指定縮略圖算法;
• UGC平臺執行縮略圖轉換算法，將轉換后的縮略圖返回給用戶;
• 用戶將得到的結果縮略圖存儲到UFile中。

整個過程中，開發者僅僅需要將縮略圖算法實現函數代碼鏡像提交到UGC算法倉庫中，然后調用UGC的提交任務API，輸入源圖片數據，即可獲得計算結果。

從以上過程可以總結出：使用Serverless，開發者無需考慮服務器細節，只需要負責編寫發生某些事件后所需執行的代碼。云供應商將負責提供用于運行這些代碼的服務器，并在必要時對服務器進行縮放。執行完畢后，承擔這些功能的容器會立刻停用，用戶只需為運行代碼過程中所消耗的資源付費。這種模式也被稱為做函數即服務(Function-as-a-Service，FaaS)。

3. 與非Serverless方案的對比

上述場景如果使用非Serverless方案，大體架構如下：

該方案需要維護一組UHost服務集群，服務器中部署圖片縮略轉換程序。UHost的服務程序先從UFile中讀取源圖片，使用圖形庫將其轉換成縮略圖并再存回UFile中。相比之前的Serverless方案，有以下幾點對比：

• 開發者需要關心服務器端程序開發設計，將圖片處理程序部署成服務端程序，并購置服務器部署并運維管理這批UHost服務器。而使用UGC，開發者無需關注服務器端，只需要將圖形庫函數提交到UGC算法倉庫中并調用UGC API完成計算任務即可。
• UHost集群無法自動為突發流量自動伸縮擴容，需要運維工程師手動購置更多的UHost并部署上線擴容。而UGC能根據突發的流量自動伸縮，運行更多的函數容器。
• UHost服務器只要在運行就必須為之付費，無論請求量和負載的高低。UGC只需要為實際的調用次數和函數實際執行時間付費，真正實現了按需分配付費。

4. Serverless相比PaaS的特點

相比PaaS，Serverless在以下幾個方面更具優勢：

• 開發者無需關注服務器程序設計，部署和運維管理，開代碼重心從此轉移到調用方而非服務器端。
• 更精細粒度的計費模式，真正實現了按需付費(Pay as you go)。使用PaaS托管應用，只要將應用部署上去，無論訪問量或者負載高低，都需要計費。而使用Serverless，用戶僅僅需要為函數真正調用到的次數和執行時間付費。

4. 使用Serverless前，你需要了解的Serverless的適用場景特點

• Serverless平臺運行的是代碼函數的片段，而不是整個程序。例如生成縮略圖場景中，UGC僅僅運行的是用圖形庫處理圖片這段代碼。
• 代碼必須做徹底的無狀態改造。Serverless平臺會自動為突發的流量自動擴展運行函數代碼所需要的容器，但用戶代碼中無法得知其容器的部署環境情況。兩次不同的Serverless調用必須是非耦合無關聯的。
• 用戶無需關注水平擴展，Serverless平臺會自動根據調用量擴展運行代碼所需要的容器，輕松做到高并發調用。
• 僅僅需要上傳代碼文件或者代碼容器鏡像即可完成應用部署。
• 代碼運行的生命周期非常短暫。通常Serverless服務商，會限制代碼的最大運行時間，例如AWS Lambda為5分鐘。
• 每次Serverless調用，Serverless平臺都會啟動容器來運行對應代碼，調用結束后將容器銷毀。因為容器創建存在一定開銷，所以Serverless不太適合對延遲要求及其苛刻的場景。

5. 不是銀彈

Serveless架構在某些場景下擁有明顯的優勢，但它不是解決一切架構問題的靈丹妙藥，更不是傳統架構的革命者和替代者。架構上說，Serverless更像是一種粘合劑。以下是一些常見的不適用Serverless的情況。

Serverless平臺需要為每次FaaS調用創建一個容器運行對應代碼。前面提到過，由于創建容器并初始化代碼運行環境存在一定程度的開銷和延時(通常在10ms級)，Serverless架構難以勝任對延遲要求非常苛刻的場景。

同樣的，由于啟動容器進程開銷較高，Serverless架構難以應對非常高的并發請求場景。通常云服務商會對用戶的并發調用數做限制，比如AWS Lambda是1000。

通常FaaS平臺會對代碼運行時間做最大時間限制。如果你的代碼需要運行較長時間才能返回結果，需要慎重考慮使用Serverless。例如剛才提到的，AWS Lambda對代碼最大運行時間限制為5分鐘。

由于代碼容器在Serverless平臺部署位置環境的不確定性，使用Serverless時，我們必須對代碼做無狀態改造。如果你兩次調用存在關聯偶合，同樣請慎重考慮Serverless。

6. 其他主流公有云服務商Serverless產品

除了眾所周知的AWS Lambda，目前常見的Serverless產品還有前文提到的UCloud的通用計算 (UGC)，官網：https://www.ucloud.cn/site/product/ugc.html。

UCloud通用計算UGC具備以下特性：

• 用戶無需關心計算資源的的交付部署，以用戶算法代碼為中心;計算資源服務化，用戶通過API使用計算資源;
• 按需付費(Pay As You Go)。用戶僅需要為實際消耗的計算資源付費;
• 提供十萬核級的海量計算資源，輕松支持高并發計算任務請求，自動實現資源分配和擴展;
• 具備高可用和跨可用區自動容災能力。

作為UCloud研發的分布式大規模并行計算服務，UGC能夠充分利用UCloud多個區域內的多個可用區的計算資源，提供基于UCloud云平臺的高可用性和高并發性，同時滿足圖片處理、機器學習、大數據處理、生物數據分析等領域的計算需求。