Todd+Hoff

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

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

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

在本文中，我們詳細闡述無服務器架構的真正含義，仔細對比了主要的公共云選擇，并簡要介紹可口可樂正在進行的無服務器計算項目。

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

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

云中無服務器計算的主要服務包括AWS Lambda、Azure Functions和Google Cloud Functions。在云中，“FaaS”（函數(shù)即服務）可能是一種更好的說法。當我們說“函數(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ù)并將其連接到一個請求或者事件。當您的無服務器計算主機提供商（在本例中是AWS）檢測到已發(fā)出了請求（例如，某個REST調用），或者已經發(fā)生的事件（例如，將文件添加到S3存儲桶中）時，采用傳遞變量調用該函數(shù)，把返回參數(shù)和結果一起傳回來。當然，它在實際中會更復雜，您可以添加安全限制，而這是其精髓所在。

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

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

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

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

幕后：沒有空閑時間

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

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

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

相反，PaaS/IaaS是要求您為所使用的資源量付費的。PaaS提供商會為您管理服務器，但您的應用程序具有長時間運行的進程，您始終要付費——即使它們處于空閑狀態(tài)。可以通過構建負載敏感的自動擴展系統(tǒng)來管理所使用的資源量，但是您總是要為一些超額用量付費。

狀態(tài)怎么樣？

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

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

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

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

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

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

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

無服務器計算提供商

怎樣開始？開始使用無服務器計算時有很多選項。兩個使用最廣泛的：使用公共云和內部部署解決方案。

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

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

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

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

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

本地無服務器計算

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

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

Azure Stack

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

IBM OpenWhisk

OpenWhisk是可以托管或者內部部署的IBM的FaaS。它有一個API網關，自然支持Swift和Node.js，還支持Docker鏡像。它是有很好支持的產品，因此，今年應用的會更多。

Iron.io

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

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

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

Fission.io

Fission.io是一個有趣的無服務器計算新方法，使用Kubernetes作為其云基礎設施。Kubernetes負責群管理、調度和網絡。有一種看法是，Kubernetes將成為開源云基礎設施的贏家，因為它有一個充滿活力而且工作效率很高的開發(fā)人員社區(qū)。在Kubernetes上構建無服務器計算產品能夠替代本地堆棧，這引起了人們的興趣。

OpenStack .

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

做好自己的選擇

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

無服務器計算案例研究：可口可樂

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

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

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

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

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

無服務器計算不會浪費人力資源。它避免了垃圾工作，不必停下來給服務器打補丁。

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

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

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

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

自動售貨機示例涉及到以下：

當您在自動售貨機買東西時，刷自己的卡。

交易從自動售貨機發(fā)送到支付網關。

支付網關向Amazon API網關提交REST API調用。

API網關調用Lambda函數(shù)。

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

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

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

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

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

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

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

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