無服務器計算：最終取決于開發人員

Todd+Hoff

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

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

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

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

無服務器計算無非就是函數

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

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

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

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

// do stuff

callback（null， "some success message"）；

}

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

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

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

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

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

幕后：沒有空閑時間

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

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

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

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

狀態怎么樣？

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

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

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

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

標準和記錄：最大的挑戰

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

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

無服務器計算提供商

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

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

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

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

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

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

本地無服務器計算

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

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

Azure Stack

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

IBM OpenWhisk

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

Iron.io

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

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

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

Fission.io

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

OpenStack .

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

做好自己的選擇

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

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

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

一些發現：

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

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

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

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

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

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

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

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

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

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

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

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

API網關調用Lambda函數。

該函數處理所有的業務邏輯：交易、信用、借記等。

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

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

采用Lambda，所有這一切發生在一秒鐘之內，亞馬遜收取的費用是一分錢的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看起來對可口可樂更有吸引力。

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

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