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

[[215205]]

回溯本源

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

一、直接使用物理設備

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

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

二、IaaS托管硬件

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

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

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

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

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

三、 PaaS托管應用

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

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

1. 什么是Serverless?

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

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

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

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

2. Serverless如何工作?

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

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

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

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

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

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

3. 與非Serverless方案的對比

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

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

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

4. Serverless相比PaaS的特點

相比PaaS，Serverless在以下幾個方面更具優(yōu)勢：

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

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

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

5. 不是銀彈

Serveless架構在某些場景下?lián)碛忻黠@的優(yōu)勢，但它不是解決一切架構問題的靈丹妙藥，更不是傳統(tǒng)架構的革命者和替代者。架構上說，Serverless更像是一種粘合劑。以下是一些常見的不適用Serverless的情況。

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

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

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

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

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

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

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

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

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