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

在過去的二十年里，虛擬機、云計算、容器等眾多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 應用程序框架，那么他們可以點擊“無服務器-脫機”選項，這是一個允許用戶在本地運行代碼的插件。