開發人員往往需要花費大量的時間編寫代碼以解決業務問題。隨後，運營團隊又要花費大量精力搞明白開發人員編寫的代碼，並讓它們在所有的計算機上運行，然後還要確保這些計算機能夠順利運行。這可以說是一項永遠沒有盡頭的任務，那麼爲什麼不將這部分工作留給別人去做呢？

在過去的二十年裏，虛擬機、雲計算、容器等衆多IT創新一直專注於確保讓用戶不必過多地考慮運行代碼的底層物理機器。如今無服務器計算正變得越來越受青睞，原因在於在使用無服務器計算時，用戶不需要了解運行代碼的硬件或操作系統，因爲服務提供商都會爲他們代勞。

什麼是無服務器計算？

無服務器計算是一種雲執行模型，由雲服務提供商動態分配執行特定代碼片段所需要的資源和存儲，然後根據使用情況向用戶收費。當然，這仍然涉及服務器，但是它們的供應和維護完全由服務提供商負責。亞馬遜無服務器計算的倡導者Chris Munns在2017年的會議上就曾表示，站在編寫和部署代碼的團隊的角度，“根本沒有服務器可以管理或配置。這裏面既沒有裸機，也沒有虛擬服務器和容器。在無服務器領域中，不需要你管理主機、修補主機或是在操作系統層面處理任何東西。”

開發人員Mike Roberts稱，“無服務器”這一術語曾被用於描述所謂的“後端即服務”場景，在這種場景中移動應用程序將連接完全託管在雲中的後端服務器。如今當人們談論無服務器計算或無服務器架構時，往往是指“功能即服務”產品，在這種場景中用戶編寫的代碼只用於業務邏輯並上傳至服務提供商那裏。該服務提供商負責配置所有的硬件、虛擬機和容器管理，甚至包括通常內置於應用程序代碼中的多線程這類的任務。

無服務器函數是事件驅動的，這意味着只有在請求觸發時纔會調用代碼。服務提供商僅根據計算時間對該次執行進行收費，而不是每月對維護物理或虛擬服務器等工作收取固定費用。這些函數可以連接在一起以創建處理管道，或者作爲規模更大的應用程序的組件，與運行在容器中或在傳統服務器上的其他代碼交互。

無服務器計算的優缺點

對於這個問題，無服務器計算的兩個最大好處是：開發人員可以專注於代碼的業務目標，而不是基礎設施問題，公司只需要支付他們實際使用的計算資源，而不用購買物理硬件或租用雲實例，因爲往往這些硬件和實例在購買或租下後大部分會處於閒置狀態。

Navica公司的CEO Bernard Golden認爲，後一點對於由事件驅動的應用程序特別有益。例如，應用程序可能大部分時間處於空閒狀態，但是在某些情況下又必須同時處理許多事件請求。亦或者，應用程序只需要處理物聯網設備定期性或間歇性發送過來的數據。在這兩種情況下，傳統方法都需要配置一個能夠處理峯值負載的強大服務器，但是大多數時候服務器都沒有得到充分利用。如果使用的是無服務器架構，那麼你只需爲實際使用的服務器資源付費。

無服務器計算也適用於特定類型的批處理。無服務器架構用例的經典實例之一是上傳和處理一系列單個圖像文件並將它們發送到應用程序的另一部分。

無服務器函數最明顯的缺點可能是，它們是短暫的，並不適合長期任務。大多數無服務器服務提供商不會讓代碼執行超過幾分鐘，在啓動函數時，他們也不會保留之前實例的任何狀態數據。問題在於，無服務器代碼可能需要幾秒鐘才能啓動，雖然這對於許多用例而言並不是問題，但是如果應用程序需要低延遲，那麼這就成了問題。

正如一些業界專家所指出的那樣，許多其他缺點都與供應商鎖定有關。儘管有可用的開源選項，但是大型商業雲服務提供商在無服務器市場佔據了主導地位。這意味着開發人員往往最終會使用他們的服務提供商的工具，這導致即便他們不滿意也很難換用其他服務提供商的產品。而且大量的無服務器計算都是在服務提供商的基礎設施上進行的，因此將無服務器代碼集成到本地開發和測試管道中會變得可能很困難。

無服務器服務提供商：

AWS Lambda、Azure函數和谷歌雲函數

無服務器計算時代始於2014年，其標誌是基於亞馬遜雲服務的AWS Lambda的推出。微軟在2016年也推出了Azure函數。自2017年以來一直處於測試階段的谷歌雲函數（Google Cloud Functions）也終於達到了生產狀態。這三種服務在侷限性、優勢、支持的語言和工作方式方面略有不同。業內專家Rohit Akiwatkar對這三者之間的區別曾進行過詳細介紹。此外，處於運行狀態的還有基於開源Apache OpenWhisk平臺的IBM Cloud Functions。

在所有無服務器計算平臺中，AWS Lambda是最突出的，發展時間最長和也最爲成熟。

無服務器堆棧

與許多軟件領域的情況一樣，無服務器世界也看到了軟件堆棧的發展，這些軟件堆棧可爲構建無服務器應用程序提供所需的不同組件。每個堆棧由編程語言、應用程序框架和一組觸發器組成。其中，應用程序框架可爲代碼提供架構，觸發器可幫助平臺理解並啓動代碼執行。

雖然用戶可以混合使用這些類別中的不同產品，但是服務提供商方面存在一些限制。例如，在語言方面，用戶可以在AWS Lambda上使用Node.js、Java、Go、C＃和Python，但只有JavaScript、C＃和F＃可在Azure函數上工作。在觸發器方面，雖然AWS Lambda的產品列表最長，但是其中的許多產品都是特定於AWS平臺的，如Amazon Simple Email Service和AWS CodeCommit。谷歌雲函數則可以由通用HTTP請求觸發。

無服務器框架

框架部分值得我們多說兩句，因爲它們很好地定義瞭如何最終構建應用程序。除了自己的原生產品，即開源的無服務器應用程序模型（SAM）外，亞馬遜還有一些其他產品，這些產品大多數都是跨平臺的，也是開源的。其中最爲流行的是Serverless，它強調爲AWS Lambda、Azure 函數、谷歌雲函數和IBM OpenWhisk等每個支持的平臺提供相同的體驗。另一個深受歡迎的產品是Apex，可幫助提供一些服務提供商無法提供的語言。

無服務器數據庫

正如我們上面提到的，使用無服務器代碼工作的一個弊端是沒有“持久狀態”，這意味着局部變量的值不會在實例化中持續存在。代碼需要訪問的所有持久性數據都必須存儲在其他位置，並且堆棧中的觸發器要包含函數與之交互的數據庫。

其中一些數據庫被稱爲“類無服務器”。這意味着它們的行爲與我們在本文中討論的無服務器函數非常相似，不過一個明顯區別是數據可以被無限期存儲，但是涉及配置和維護數據庫的大部分管理開銷都被消除了。正如開發人員Jeremy Daly所說，“你需要做的工作就是配置一個集羣，然後它們爲你自動處理所有維護、修補、備份、複製和擴展。”與“函數即服務”產品一樣，你只需支付實際使用的計算時間，並根據需要調高或調低資源以滿足需求。”

三大無服務器提供商各自擁有自己的無服務器數據庫：亞馬遜的爲Aurora無服務器和DynamoDB，微軟的是Azure Cosmos數據庫，谷歌的是Cloud Firestore。

無服務器計算和Kubernetes

容器可帶動無服務器技術。由於管理它們的開銷由服務提供商負責，因此用戶無需擔心這部分開銷。許多人認爲通過無服務器計算享受到容器化微服務的諸多優點，同時又可免去煩瑣的操作。有些人甚至已經開始談論“後容器”時代。

實際上，容器和無服務器計算在未來許多年內幾乎肯定會共存，因爲無服務器函數可以與容器化微服務共同存在於同一應用程序當中。作爲最受歡迎的容器編排平臺，Kubernetes能夠管理無服務器基礎設施。通過Kubernetes，用戶可以在單個集羣上集成不同類型的服務。

脫機（離線）運行無服務器

在開啓無服務器計算之旅前用戶可能會感到有些不安，因爲他們需要與服務提供商簽約才能使用，並且需要了解它們是如何工作的。不過不要擔心：用戶可以通過一些方法在自己的本地硬件上脫機運行無服務器代碼。例如，AWS SAM提供了一個本地功能，允許用戶脫機測試Lambda代碼。如果用戶正在使用Serverless 應用程序框架，那麼他們可以點擊“無服務器-脫機”選項，這是一個允許用戶在本地運行代碼的插件。

作者：Josh Fruhlinger爲自由撰稿人兼編輯，現居美國洛杉磯。

編譯：陳琳華