無服務(wù)器計算：最終取決于開發(fā)人員

Todd+Hoff

采用我們清晰的無服務(wù)器計算指南解決您頭痛的基礎(chǔ)設(shè)施問題，公共云和本地選擇也有助于解決這些問題

無服務(wù)器計算為那些希望減輕基礎(chǔ)設(shè)施負(fù)擔(dān)的開發(fā)人員提供了很好的機(jī)會。把所有東西都進(jìn)行抽象化，而只留下代碼，無服務(wù)器計算模型使得開發(fā)人員能夠更快地迭代和部署新代碼，預(yù)算不多的小團(tuán)隊(duì)能夠干好以前只有大公司才能做的事情?；蛘?，正如Cloudability的創(chuàng)始人兼首席執(zhí)行官M(fèi)at Ellis在CloudCast episode中所說的“無服務(wù)器計算有可能把開發(fā)人員的工作成果實(shí)現(xiàn)工業(yè)化。”

當(dāng)然，在后臺，服務(wù)器仍然存在，嗡嗡作響。但是無服務(wù)器架構(gòu)是沒有狀態(tài)的。它通過執(zhí)行一點(diǎn)點(diǎn)的邏輯——一個函數(shù)去完成工作，并調(diào)用其他服務(wù)來做任何需要的事情。如果您是主要通過API使用服務(wù)構(gòu)建應(yīng)用程序或者需要響應(yīng)事件的開發(fā)人員，那么，無服務(wù)器架構(gòu)可能是完成工作最簡單、最快、風(fēng)險最小的方法。

在本文中，我們詳細(xì)闡述無服務(wù)器架構(gòu)的真正含義，仔細(xì)對比了主要的公共云選擇，并簡要介紹可口可樂正在進(jìn)行的無服務(wù)器計算項(xiàng)目。

無服務(wù)器計算無非就是函數(shù)

無服務(wù)器是一種云計算服務(wù)模式——就像IaaS、PaaS、SaaS、BaaS和CaaS，依賴于無處不在的、方便的、按需訪問的動態(tài)資源共享池，其中包括了可配置網(wǎng)絡(luò)、存儲和計算資源。然而，無服務(wù)器計算采用不同的方法來使用這些資源。無服務(wù)器計算還沒有達(dá)成一致的定義，但是已經(jīng)出現(xiàn)了關(guān)于概念的宣言。使用無服務(wù)器計算，函數(shù)是部署的基本單元。程序員看不到任何計算機(jī)、虛擬機(jī)或者容器。

云中無服務(wù)器計算的主要服務(wù)包括AWS Lambda、Azure Functions和Google Cloud Functions。在云中，“FaaS”（函數(shù)即服務(wù)）可能是一種更好的說法。當(dāng)我們說“函數(shù)”時，我們真的是指一個函數(shù)。這是一個在Node.js中編寫的AWS Lambda示例：

exports.myHandler = function（event， context， callback） {

console.log（"value1 = " + event.key1）；

// do stuff

callback（null， "some success message"）；

}

就這么簡單。上傳函數(shù)并將其連接到一個請求或者事件。當(dāng)您的無服務(wù)器計算主機(jī)提供商（在本例中是AWS）檢測到已發(fā)出了請求（例如，某個REST調(diào)用），或者已經(jīng)發(fā)生的事件（例如，將文件添加到S3存儲桶中）時，采用傳遞變量調(diào)用該函數(shù)，把返回參數(shù)和結(jié)果一起傳回來。當(dāng)然，它在實(shí)際中會更復(fù)雜，您可以添加安全限制，而這是其精髓所在。

可以采用您的提供商支持的任何語言來編寫您的函數(shù)。您要做的是把輸入請求或者事件映射到函數(shù)調(diào)用。每個提供商都有自己的一整套支持語言、約定、過程、成本、能力和限制要求（參見下表）。這就是“無服務(wù)器計算宣言”所說的“帶上自己的代碼”。

您的函數(shù)可以任意復(fù)雜，它可以通過API調(diào)用所包含的庫或者外部服務(wù)。為了能夠擴(kuò)展，無服務(wù)器計算函數(shù)必須只使用自身可擴(kuò)展的服務(wù)。

取決于提供商，代碼可以直接在在線編輯器中編寫，也可以作為代碼文件、.zip、.jar文件或者容器上傳。這也是無服務(wù)器計算的一個缺點(diǎn)，因?yàn)橥ㄟ^發(fā)布周期進(jìn)行代碼上傳和管理的工具仍然不是很好，還需要大量的框架來填補(bǔ)空白。

當(dāng)然，代碼不可能真的任意復(fù)雜，提供商會有一些相關(guān)的限制。每個主機(jī)都有代碼上傳最大限制（例如，AWS Lambda為50MB）。每個主機(jī)有最長函數(shù)執(zhí)行時間（對于AWS Lambda，在1到300秒之間）。每個函數(shù)在其可用的存儲容量和所使用的CPU能力方面也受到限制。想要更多的內(nèi)存、更好的CPU，還是更長的執(zhí)行時間？那您就得付更多的錢。費(fèi)用結(jié)算是提供商之間的另一區(qū)別，我們將在下面看到。

幕后：沒有空閑時間

當(dāng)然，幕后會有服務(wù)器，但作為開發(fā)人員，您從來不需要考慮它們。您需要知道的是您的函數(shù)。您不用再去處理容量規(guī)劃、部署、擴(kuò)展、安裝、修補(bǔ)程序等。這通常被視為NoOps或者LessOps，而實(shí)際上是DifferentOps。代碼仍然需要被組織、開發(fā)、構(gòu)建、測試、版本化、發(fā)布、記錄和監(jiān)控。

由于您所看到的只是函數(shù)，因此，您的提供商負(fù)責(zé)激活您的函數(shù)以響應(yīng)任何請求或者事件。當(dāng)有請求進(jìn)入，并且函數(shù)的空閑實(shí)例不可用時，必須把代碼分配給服務(wù)器并啟動。作為開發(fā)人員，您什么也不用做。是由您的提供商保證有足夠的容量來處理負(fù)載。當(dāng)然，在冷啟動情況下，延遲命中是無服務(wù)器計算的缺點(diǎn)之一。

使用無服務(wù)器計算，您只有消費(fèi)時才付費(fèi)，當(dāng)您的服務(wù)運(yùn)行時才付費(fèi)。您從來不用為空閑計算時間付費(fèi)。其影響是巨大的。您可以建立整套基礎(chǔ)設(shè)施，而不用支付一分錢。操作、開發(fā)和擴(kuò)展成本都降低了。

相反，PaaS/IaaS是要求您為所使用的資源量付費(fèi)的。PaaS提供商會為您管理服務(wù)器，但您的應(yīng)用程序具有長時間運(yùn)行的進(jìn)程，您始終要付費(fèi)——即使它們處于空閑狀態(tài)?？梢酝ㄟ^構(gòu)建負(fù)載敏感的自動擴(kuò)展系統(tǒng)來管理所使用的資源量，但是您總是要為一些超額用量付費(fèi)。

狀態(tài)怎么樣？

您所看到的只是一個函數(shù)，因此，沒有存儲狀態(tài)。當(dāng)執(zhí)行一個函數(shù)時，其計算資源可以被垃圾式地收集并重用。狀態(tài)必須存儲在某些其他服務(wù)中，例如數(shù)據(jù)庫或者高速緩存。

為了控制計費(fèi)成本，提供商對函數(shù)設(shè)置了最大執(zhí)行時間。目前，對于AWS Lambda和Azure Functions這是五分鐘。執(zhí)行限制存在缺點(diǎn)。例如，如果您正在升級數(shù)據(jù)庫，該怎么辦？或者您的函數(shù)要對其他服務(wù)進(jìn)行很多調(diào)用才能返回結(jié)果？或者您的函數(shù)有很多輸入要處理？在某些情況下，這些操作需要的時間可能會超過5分鐘。

除非您的函數(shù)很簡單，否則函數(shù)都需要被編碼為無狀態(tài)、等冪、由狀態(tài)機(jī)驅(qū)動的事件驅(qū)動服務(wù)，在調(diào)用之間在連續(xù)存儲中保存數(shù)據(jù)。這會變得很復(fù)雜。您正常的云方法仍然有效。例如，將輸入劃分成批次，并將其放入工作隊(duì)列中。

為了在這方面提供幫助，AWS已經(jīng)創(chuàng)建了一項(xiàng)名為步進(jìn)函數(shù)的新服務(wù)，它實(shí)現(xiàn)了一個狀態(tài)機(jī)，允許函數(shù)無限期地繼續(xù)下去。實(shí)際上，AWS Lambda應(yīng)該更好，它不要求使用完全不同的、昂貴的服務(wù)。

標(biāo)準(zhǔn)和記錄：最大的挑戰(zhàn)

盡管無服務(wù)器計算將服務(wù)接口縮減為單個函數(shù)，有時稱為納服務(wù)（nanoservice），但總歸還是很復(fù)雜。使用PaaS，計算的最小單位是應(yīng)用程序。這有好處也有壞處。由于應(yīng)用程序很大，啟動和停止會很慢；它可能很難響應(yīng)需求進(jìn)行擴(kuò)展；可能很難在細(xì)粒度等級上進(jìn)行計費(fèi)。但PaaS也易于管理、監(jiān)控和調(diào)試。

把代碼分散到大量的函數(shù)上，無服務(wù)器計算真的很難調(diào)試。邏輯流的跟蹤分布在許多不同的日志文件中，并且調(diào)用之間沒有連接。需要記錄和標(biāo)準(zhǔn)，但這還不夠。這方面的工具還應(yīng)該繼續(xù)改進(jìn)。

無服務(wù)器計算提供商

怎樣開始？開始使用無服務(wù)器計算時有很多選項(xiàng)。兩個使用最廣泛的：使用公共云和內(nèi)部部署解決方案。

無服務(wù)器計算已經(jīng)成為任何公共云的基礎(chǔ)，因此所有主要提供商都在開發(fā)自己的產(chǎn)品。亞馬遜有AWS Lambda，自2015年4月以來一直是GA。微軟有Azure Functions，自2016年11月以來一直是GA。谷歌有Google Cloud Functions，還處于封閉alpha測試狀態(tài)中。

在這三者之間怎樣進(jìn)行選擇，如果您已經(jīng)在公共云中，最好使用當(dāng)前提供商的產(chǎn)品。無服務(wù)器計算之所以實(shí)用，主要原因是您可以使用豐富的服務(wù)和事件。這些選擇最好在您的云中。但是，如果您在云中開始，穩(wěn)定性很重要，那么AWS Lambda時間最長，并且是迄今為止最安全的選擇。

對于AWS Lambda，函數(shù)是獨(dú)立的，盡管在實(shí)踐中它們通常使用類似Serverless的框架在群中進(jìn)行管理。將根據(jù)您的函數(shù)請求數(shù)量和代碼執(zhí)行時間向您收費(fèi)。如果您想要更多的CPU，您必須分配更多的內(nèi)存。

使用Azure Functions，其Function App包括了一個或者多個不同的函數(shù)，這些函數(shù)是由Azure App Service一起管理的。Function App可以使用Consumption托管計劃或者App Service托管計劃。使用Consumption計劃，F(xiàn)unction App會自動調(diào)整，您按照所有函數(shù)的內(nèi)存大小和總執(zhí)行時間付費(fèi)，其計費(fèi)單位是千兆字節(jié)秒。使用App Service托管計劃計費(fèi)更像是EC2。

由于Google Cloud Functions仍處于封閉alpha測試狀態(tài)中，因此還不清楚關(guān)于函數(shù)操作和付費(fèi)的方法。我們知道有兩類函數(shù)：HTTP函數(shù)和Background函數(shù)。HTTP函數(shù)通過HTTP（S）直接調(diào)用。Background函數(shù)通過Google Cloud Pub/Sub主題上的消息或者Google Cloud Storage存儲桶中的更改間接調(diào)用。

本地?zé)o服務(wù)器計算

在您自己的數(shù)據(jù)中心托管無服務(wù)器計算并不簡單，盡管它變得更容易了，并且有很多選項(xiàng)。您仍然要建立并維護(hù)基礎(chǔ)設(shè)施。

這是一個變化很快的領(lǐng)域。供應(yīng)商正在爭奪位置，力爭在公共云大提供商的陰影下開拓出一個市場。要小心翼翼地前行，應(yīng)該謹(jǐn)慎地看待每個應(yīng)用程序的可移植性承諾。

Azure Stack

如果您的目標(biāo)是像公共云那樣在本地運(yùn)行，那么Azure Stack （2017年中可用）看起來是最好的選擇。還不知道它是怎樣工作的，但其前景很好，也是云供應(yīng)商之間的關(guān)鍵區(qū)別所在。

IBM OpenWhisk

OpenWhisk是可以托管或者內(nèi)部部署的IBM的FaaS。它有一個API網(wǎng)關(guān)，自然支持Swift和Node.js，還支持Docker鏡像。它是有很好支持的產(chǎn)品，因此，今年應(yīng)用的會更多。

Iron.io

Iron.io是第一個無服務(wù)器計算提供商，但現(xiàn)在也不得不在大的云提供商夾縫中謀得一席之地。它提供兩種選擇：IronFunctions和Project Kratos。

Project Kratos是一種接受策略：它使企業(yè)能夠在任何云提供商中以及內(nèi)部部署中運(yùn)行AWS Lambda函數(shù)，從而避免了受限于供應(yīng)商。

IronFunctions是擴(kuò)展策略：它是一個基于Docker的開源無服務(wù)器/FaaS平臺，可以在任何地方運(yùn)行：公共云、私有云和混合云，甚至在您自己的筆記本電腦上。

Fission.io

Fission.io是一個有趣的無服務(wù)器計算新方法，使用Kubernetes作為其云基礎(chǔ)設(shè)施。Kubernetes負(fù)責(zé)群管理、調(diào)度和網(wǎng)絡(luò)。有一種看法是，Kubernetes將成為開源云基礎(chǔ)設(shè)施的贏家，因?yàn)樗幸粋€充滿活力而且工作效率很高的開發(fā)人員社區(qū)。在Kubernetes上構(gòu)建無服務(wù)器計算產(chǎn)品能夠替代本地堆棧，這引起了人們的興趣。

OpenStack .

OpenStack目前不能自然的支持FaaS，但名為Project Picasso的項(xiàng)目比較重要。它有兩個主要組件：Picasso API和IronFunctions。Picasso使用IronFunctions提供的后端容器引擎。

做好自己的選擇

無服務(wù)器計算不是火箭科學(xué)。您可以在當(dāng)前基礎(chǔ)設(shè)施之上構(gòu)建自己的無服務(wù)器計算平臺，發(fā)揮其所有優(yōu)勢，而無需遷移到新堆棧。如果您不想把自己的數(shù)據(jù)中心當(dāng)成云，那么這是一個很好的選擇。

無服務(wù)器計算案例研究：可口可樂

無服務(wù)器計算在實(shí)際中是怎樣工作的？這里有一個案例，“可口可樂：按照企業(yè)要求運(yùn)行無服務(wù)器計算應(yīng)用程序”，其中可口可樂北美技術(shù)戰(zhàn)略主任Michael Connor解釋了可口可樂怎樣使用AWS Lambda處理自動售貨機(jī)上的交易。

一些發(fā)現(xiàn)：

無服務(wù)器計算比IaaS便宜三倍。每月約8千萬筆交易，IaaS變得更有吸引力。

可口可樂現(xiàn)在強(qiáng)制要求采用無服務(wù)器計算解決方案，否則要解釋清楚為什么不使用無服務(wù)器計算。

無服務(wù)器計算并不能解決所有問題，但它的確解決了對凈收益沒有貢獻(xiàn)的問題。

無服務(wù)器計算不會浪費(fèi)人力資源。它避免了垃圾工作，不必停下來給服務(wù)器打補(bǔ)丁。

可口可樂對比了使用IaaS與無服務(wù)器計算時花費(fèi)的時間（如下表所示）。

使用IaaS時，只有39%的時間花在交付業(yè)務(wù)項(xiàng)目上。在轉(zhuǎn)向無服務(wù)器計算后，可口可樂花了68%的時間用于業(yè)務(wù)項(xiàng)目，這還有改進(jìn)的余地。

轉(zhuǎn)到亞馬遜之后，啟動服務(wù)器會有幾分鐘的沖擊，而過去需要幾星期的時間。當(dāng)您意識到服務(wù)器整個生命周期中的維護(hù)成本時，這種沖擊就顯得微不足道了。據(jù)可口可樂公司Connor的說法，無服務(wù)器計算簡化了這方面的工作。

可口可樂還希望開發(fā)人員開發(fā)，而不是履行開發(fā)職責(zé)。轉(zhuǎn)到無服務(wù)器計算大大減少了所需的操作量，而且開發(fā)人員還能更好的應(yīng)對那些仍在使用的操作。

自動售貨機(jī)示例涉及到以下：

當(dāng)您在自動售貨機(jī)買東西時，刷自己的卡。

交易從自動售貨機(jī)發(fā)送到支付網(wǎng)關(guān)。

支付網(wǎng)關(guān)向Amazon API網(wǎng)關(guān)提交REST API調(diào)用。

API網(wǎng)關(guān)調(diào)用Lambda函數(shù)。

該函數(shù)處理所有的業(yè)務(wù)邏輯：交易、信用、借記等。

通過Apple/Android推送通知服務(wù)把通知發(fā)送回用戶。相應(yīng)的將其提交回Apple Pay/Android Pay，因此您可以在您手機(jī)錢包中看到有一筆支出。

在這些交易之前還可能會有“買10免費(fèi)送一”和其他促銷。

采用Lambda，所有這一切發(fā)生在一秒鐘之內(nèi)，亞馬遜收取的費(fèi)用是一分錢的1/1，000。而且，只有客戶進(jìn)行交易時，可口可樂才會付費(fèi)。否則，可口可樂不支付任何費(fèi)用。對于Lambda，每月大約3000萬次調(diào)用，每年的費(fèi)用為4490美元。

使用AWS IaaS方法，T2中型服務(wù)器的成本約為每月56美元。而完全負(fù)擔(dān)的成本幾乎是其五倍：250美元 = 56美元（服務(wù)器）+ 150美元（管理：補(bǔ)丁、調(diào)用、記賬）+ 30美元（安全：防病毒）+ 14美元（自動化：Puppet，Chef，Ansible）。使用六臺T2中型服務(wù)器，每年的成本為12，864美元，因此，Lambda解決方案比IaaS解決方案便宜65%。

當(dāng)然，有一個盈虧平衡點(diǎn)。如果您運(yùn)行大量的交易，使用自己的設(shè)備會更便宜。對于這個例子，每月大約8000萬次交易，轉(zhuǎn)到IaaS看起來對可口可樂更有吸引力。

這個案例研究的另一個細(xì)節(jié)是無服務(wù)器計算怎樣處理長尾生命周期。假設(shè)您剛推出首批10臺自動售貨機(jī)使用IaaS，您為該群支付13，000美元。那么壽命終了時會怎樣？當(dāng)最后這10臺機(jī)器還沒有完全報廢時，您每年仍然要為IaaS支付13000美元。而無服務(wù)器計算可以輕松的進(jìn)行調(diào)整。當(dāng)您每月交易少于100萬次時，這節(jié)省了99%的成本。

無服務(wù)器計算的成本非常吸引人，除非您是大批量運(yùn)行。有多少服務(wù)是小批量運(yùn)行的？