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

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

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

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

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

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

無服務(wù)器計(jì)算的優(yōu)缺點(diǎn)

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

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

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

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

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

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

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

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

無服務(wù)器堆棧

與許多軟件領(lǐng)域的情況一樣，無服務(wù)器世界也看到了軟件堆棧的發(fā)展，這些軟件堆棧可為構(gòu)建無服務(wù)器應(yīng)用程序提供所需的不同組件。每個(gè)堆棧由編程語言、應(yīng)用程序框架和一組觸發(fā)器組成。其中，應(yīng)用程序框架可為代碼提供架構(gòu)，觸發(fā)器可幫助平臺(tái)理解并啟動(dòng)代碼執(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平臺(tái)的，如Amazon Simple Email Service和AWS CodeCommit。谷歌云函數(shù)則可以由通用HTTP請求觸發(fā)。

無服務(wù)器框架

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

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

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

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

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

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

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

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

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

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