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

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

什么是無服務(wù)器計算？

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

開發(fā)人員Mike Roberts稱，“無服務(wù)器”這一術(shù)語曾被用于描述所謂的“后端即服務(wù)”場景，在這種場景中移動應(yīng)用程序?qū)⑦B接完全托管在云中的后端服務(wù)器。如今當(dāng)人們談?wù)摕o服務(wù)器計算或無服務(wù)器架構(gòu)時，往往是指“功能即服務(wù)”產(chǎn)品，在這種場景中用戶編寫的代碼只用于業(yè)務(wù)邏輯并上傳至服務(wù)提供商那里。該服務(wù)提供商負責(zé)配置所有的硬件、虛擬機和容器管理，甚至包括通常內(nèi)置于應(yīng)用程序代碼中的多線程這類的任務(wù)。

無服務(wù)器函數(shù)是事件驅(qū)動的，這意味著只有在請求觸發(fā)時才會調(diào)用代碼。服務(wù)提供商僅根據(jù)計算時間對該次執(zhí)行進行收費，而不是每月對維護物理或虛擬服務(wù)器等工作收取固定費用。這些函數(shù)可以連接在一起以創(chuàng)建處理管道，或者作為規(guī)模更大的應(yīng)用程序的組件，與運行在容器中或在傳統(tǒng)服務(wù)器上的其他代碼交互。

無服務(wù)器計算的優(yōu)缺點

對于這個問題，無服務(wù)器計算的兩個最大好處是：開發(fā)人員可以專注于代碼的業(yè)務(wù)目標，而不是基礎(chǔ)設(shè)施問題，公司只需要支付他們實際使用的計算資源，而不用購買物理硬件或租用云實例，因為往往這些硬件和實例在購買或租下后大部分會處于閑置狀態(tài)。

Navica公司的CEO Bernard Golden認為，后一點對于由事件驅(qū)動的應(yīng)用程序特別有益。例如，應(yīng)用程序可能大部分時間處于空閑狀態(tài)，但是在某些情況下又必須同時處理許多事件請求。亦或者，應(yīng)用程序只需要處理物聯(lián)網(wǎng)設(shè)備定期性或間歇性發(fā)送過來的數(shù)據(jù)。在這兩種情況下，傳統(tǒng)方法都需要配置一個能夠處理峰值負載的強大服務(wù)器，但是大多數(shù)時候服務(wù)器都沒有得到充分利用。如果使用的是無服務(wù)器架構(gòu)，那么你只需為實際使用的服務(wù)器資源付費。

無服務(wù)器計算也適用于特定類型的批處理。無服務(wù)器架構(gòu)用例的經(jīng)典實例之一是上傳和處理一系列單個圖像文件并將它們發(fā)送到應(yīng)用程序的另一部分。

無服務(wù)器函數(shù)最明顯的缺點可能是，它們是短暫的，并不適合長期任務(wù)。大多數(shù)無服務(wù)器服務(wù)提供商不會讓代碼執(zhí)行超過幾分鐘，在啟動函數(shù)時，他們也不會保留之前實例的任何狀態(tài)數(shù)據(jù)。問題在于，無服務(wù)器代碼可能需要幾秒鐘才能啟動，雖然這對于許多用例而言并不是問題，但是如果應(yīng)用程序需要低延遲，那么這就成了問題。

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

無服務(wù)器服務(wù)提供商：AWS Lambda、Azure函數(shù)和谷歌云函數(shù)

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

在所有無服務(wù)器計算平臺中，AWS Lambda是最突出的，發(fā)展時間最長和也最為成熟。

無服務(wù)器堆棧

與許多軟件領(lǐng)域的情況一樣，無服務(wù)器世界也看到了軟件堆棧的發(fā)展，這些軟件堆棧可為構(gòu)建無服務(wù)器應(yīng)用程序提供所需的不同組件。每個堆棧由編程語言、應(yīng)用程序框架和一組觸發(fā)器組成。其中，應(yīng)用程序框架可為代碼提供架構(gòu)，觸發(fā)器可幫助平臺理解并啟動代碼執(zhí)行。

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

無服務(wù)器框架

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

無服務(wù)器數(shù)據(jù)庫

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

其中一些數(shù)據(jù)庫被稱為“類無服務(wù)器”。這意味著它們的行為與我們在本文中討論的無服務(wù)器函數(shù)非常相似，不過一個明顯區(qū)別是數(shù)據(jù)可以被無限期存儲，但是涉及配置和維護數(shù)據(jù)庫的大部分管理開銷都被消除了。正如開發(fā)人員Jeremy Daly所說，“你需要做的工作就是配置一個集群，然后它們?yōu)槟阕詣犹幚硭芯S護、修補、備份、復(fù)制和擴展。”與“函數(shù)即服務(wù)”產(chǎn)品一樣，你只需支付實際使用的計算時間，并根據(jù)需要調(diào)高或調(diào)低資源以滿足需求。”

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

無服務(wù)器計算和Kubernetes

容器可帶動無服務(wù)器技術(shù)。由于管理它們的開銷由服務(wù)提供商負責(zé)，因此用戶無需擔(dān)心這部分開銷。許多人認為通過無服務(wù)器計算享受到容器化微服務(wù)的諸多優(yōu)點，同時又可免去煩瑣的操作。有些人甚至已經(jīng)開始談?wù)摗昂笕萜鳌睍r代。

實際上，容器和無服務(wù)器計算在未來許多年內(nèi)幾乎肯定會共存，因為無服務(wù)器函數(shù)可以與容器化微服務(wù)共同存在于同一應(yīng)用程序當(dāng)中。作為最受歡迎的容器編排平臺，Kubernetes能夠管理無服務(wù)器基礎(chǔ)設(shè)施。通過Kubernetes，用戶可以在單個集群上集成不同類型的服務(wù)。

脫機（離線）運行無服務(wù)器

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