Asaf撰寫了一篇博文，闡述了是否應該使用無服務器架構，以及分析它的利弊得失。

業界有一種觀點，無服務器的說法并不太確切，服務器怎么可能不存在呢？這里提到的服務器，其實就是一種立足于云基礎設施上建立的新抽象層，讓開發者無需再為服務器乃至云中的各類虛擬資源分神。

目前在無服務器概念最具知名度的是Amazon AWS Lambda。Amazon表示：“一旦將代碼上傳至Lambda，該服務會處理基礎設施的全部容量、規模伸縮、補丁安裝以及管理工作，從而為代碼運行提供必要環境。”

經作者Asaf Yigal授權，InfoQ翻譯、整理了Asaf的博文的觀點，分享給廣大讀者。

當2014年Amazon發布AWS Lambda時，“無服務器”術語開始得到普及。從那時起，我們看到這術語在使用和參考呈指數級增長，更多的應用上帶著他們自己的解決方案進入市場（例如，Azure最近提供的帶函數的遺傳算法（Genetic Algorithms，GA）。

“無服務器”究竟是指什么呢？這種新趨勢如何影響人們編寫和部署應用的方式？“無服務器”是一種范式轉變呢，還是僅僅是基礎架構即服務（Iaas）和平臺即服務（Pass）的自然演進呢？在這篇文章中，Asaf將討論究竟什么是“無服務器”，以及與現有的PaaS解決方案相比，它是如何形成的。

什么是“無服務器”？

“無服務器”是一種特殊類型的軟件體系結構，在沒有可見的進程、操作系統、服務器或者虛擬機的環境中執行應用邏輯。值得一提的是，這樣的環境實際上運行在操作系統之上，并使用物理服務器或者虛擬機，但是，提供和管理基礎設施完全是服務提供商的責任。因此，軟件開發人員才能專注于編寫代碼。

換句話說，開發者要考慮彼此之間以及與外部通信的服務或功能。實施這些服務后，開發人員使用傳統方法時將它們組合成多個分布式進程：安裝、運行、監視和更新特定操作系統上運行的特定服務器或虛擬機的這種進程。在“無服務器”方法中，第三方服務提供商包攬了一切：從進程，到操作系統，再到服務器。

當第三方服務提供商負責底層IT基礎架構時，開發人員不再負責購買專用服務器或虛擬機。同時，服務提供商可以自由決定如何有效地利用其基礎設施來滿足其所有客戶端的請求。做為結果，服務提供商通常不需要為特定客戶端運行永久工作負載；相反，軟件同時處理來自所有客戶的要求，只花費有限的時間來處理來自特定客戶的每個請求。因此，這樣的提供商通常基于請求的總數，在指定時間段內的請求的頻率或為來自客戶的所有請求所花費的總時間來對他們的客戶收費。

同樣的方法適用于不同類型的負載，因為第三方服務提供商通常具有彈性、可擴展的服務。當客戶開始使用第三方服務時，與在本地或云中購買、配置和管理自己的基礎設施相比，預期的請求數量可能較少，客戶支付的費用顯著降低。對于大量的請求（預期或意外的負載峰值），客戶不需要添加服務器來橫向擴展其應用程序。相反，服務提供商確實關心增加的負載。當然，處理更多請求的成本會更高，但在大多數情況下，它仍然比使用專用IT基礎設施更有效。

BaaS和FaaS

通常與無服務器一起提到的兩種方法是后端即服務(BaaS)和函數即服務(FaaS)。

BaaS

越來越多的實現所需功能，提供服務器端邏輯并管理其內部狀態的第三方服務導致應用程序沒有特定應用程序，服務器端邏輯，并使用第三方服務的一切。在這方面，這樣的應用是無服務器的。

第三方服務的一些示例包括身份認證即服務（Auth0、AWS Cognito），日志即服務（Loggly、Logsense、Amazon Elasticsearch Service）和分析即服務（Amazon Kinesis、Keen IO）等等。

FaaS

當應用程序仍需要特定的服務器端邏輯時，開發人員可以使用傳統架構的現代替代方案：FaaS。通過這種方法，開發人員專注于實現由事件觸發的短期無狀態函數，并且可以與對方和外部世界進行通信。FaaS提供者進行休息配置，以處理所有請求所需的功能的多個實例，終止不再需要的實例，監視所有這些實例并提供身份和日志服務。FaaS是微服務架構的理想之選，因為FaaS提供了組織運行微服務所需的一切。

Auth0 Webtask、AWS Lambda、Google Cloud Functions和Azure Functions是FaaS實現的示例。IronFunctions是一個來自Iron.io的雄心勃勃的計劃，目標是在最受歡迎的云提供商以及內部部署上運行AWS Lambda功能。

“無服務器”不能做的是什么？

無服務器和PaaS之間的主要區別在于傳統的PaaS提供程序（如Heroku或OpenShift）通常缺少自動縮放功能。傳統PaaS的用戶必須為應用程序指定資源量，例如Heroku的Dyno或OpenShift的Gear。仍然可以通過更改分配的資源數量手動縮放應用程序，但大多數情況下這是開發人員或系統管理員的責任。

InfoQ注：　　
Gear，也稱之為application container，是OpenShift的計量單位，每賬戶3個。每個Gear就是一個由軟硬件資源構成的容器，放置著用戶應用代碼和所使用的cartridge實例。　　
Dyno，是Heroku的一個度量標準，定義為“在Heroku平臺上運行的、任何類型的單一進程。”Heroku以此為依據收取服務費用。

第二個區別是傳統的PaaS設計用于長期運行的服務器應用程序。使用這樣的設計，應用程序應始終運行以處理傳入請求。如果用戶把應用程序關閉，它顯然不會提供請求。使用FaaS，用戶的函數開始提供請求，并在處理請求時終止。理想情況下，當沒有傳入請求時，用戶的函數不應該消耗提供程序資源（另請參閱下面的“冷啟動”問題）。

根據這個術語的嚴格定義，傳統的PaaS實現不是“無服務器”，因為它們沒有自動擴展，并且要求服務器端應用程序始終運行，以便可以提供請求。由于同樣的原因，傳統的容器管理平臺也不是“無服務器”。

另一種了解提供商是否允許無服務器方法的途徑，是識別兩個責任區域之間的邊界：提供商的消費者和提供商本身。在“無服務器”中，邊界在應用程序代碼之間，以及如何在物理服務器上實際部署和運行該代碼。在容器平臺中，平臺的消費者仍然負責使用操作系統級別來定義諸如將在哪個容器中運行的進程，以及每種類型的多少容器將運行的事務。

盡管如此，容器和無服務器之間存在固有的相似之處。例如，Kubernetes（一個開源容器編排平臺）允許使用應用程序提供的指標（如并發請求數）自動擴展容器。AWS Lambda實際上為每個函數運行一個容器。

換句話說，容器和容器編排可以提供實現FaaS的有效方式，而FaaS提供了隱藏特定進程的附加抽象級別，它隱藏來自開發人員的特定進程、操作系統和容器，并允許他們專注于代碼。

“無服務器”的優點和缺點

正如我們已經提到的，“無服務器”具有以下主要優點：

減少交付時間、軟件發布更快。降低運營和開發成本。低擴展成本：無須為開發人員實現代碼進行縮放，管理員也無需升級現有服務器或添加其他服務器。 與敏捷開發工作，并允許開發人員專注于代碼以更快交付。適合微服務，可以實現為函數。降低軟件的復雜性。簡化打包和部署，無需系統管理。

同時，“無服務器”具有以下缺點：

無服務器對長時間運行的應用程序效率不高。在某些情況下，使用長任務并不比專用服務器或虛擬機上運行工作負載高效。 和提供商捆綁在一起。用戶的應用程序完全依賴第三方提供商。用戶對自己的應用程序沒有完全的控制權。最有可能的情況是，用戶不能在不對應用程序進行重大改進的情況下更換平臺或者提供商。此外，用戶依賴平臺的可用性，而平臺的API和成本可能會發生變更。需要說明的是，現有的各類FaaS變更彼此并不兼容。 無服務器（和微服務）架構為調用函數/微服務帶來了額外的開銷。沒有“本地”操作，用戶不能假定兩個通信功能位于同一服務器上。 為了更有效地利用其資源，服務提供商可以在同一物理服務器上運行用于若干不同客戶的軟件（這也被稱為“多租戶”）。即使客戶的工作負載在虛擬機或容器中隔離，在FaaS產品的早期階段也會有不同的錯誤。如果用戶使用敏感數據，這可能是應用程序的主要安全問題。平臺中的這種潛在錯誤或一個客戶代碼（“嘈雜的鄰居”）中的故障可能會影響應用程序的性能或可用性。

在實踐中，可擴展的無服務器平臺需要一些時間來處理用戶的函數的第一個請求。這個問題被稱為“冷啟動”：因為平臺需要初始化內部資源（例如AWS Lambda需要啟動容器）。如果長時間沒有對用戶的函數發出請求，平臺也可以釋放這些資源（例如停止容器）。避免冷啟動的一個選項是通過向函數發送定期請求來確保函數保持活動狀態。

一些FaaS實現（例如AWS Lambda）不提供開箱即用的工具在本地測試函數（假設開發人員使用相同的云進行測試）。這不是一個理想的決定，特別是考慮到用戶將為調用每個函數支付費用。因此，一些第三方解決方案正在努力填補這一空白，使用戶能夠在本地測試函數。

不同的FaaS實現提供了用戶記錄函數的不同方法。例如，AWS Lambda允許使用特定語言的標準框架（Java的Log4j，Node.js的控制臺方法，Python的日志記錄模塊）將日志寫入AWS CloudWatch。這完全取決于開發人員如何實現更高級的日志記錄。

總結

無服務器架構是編寫和部署應用程序的一種新方法，它允許開發人員專注于代碼。這種方法可以減少交付時間、運營成本和系統復雜性。盡管無服務器利用第三方服務（例如AWS Lambda）來消除設置和配置物理服務器或虛擬機的要求，它還捆綁在應用程序及其架構中的特定服務提供商。在將來，我們可以期待更多的趨向于統一FaaS API或框架，如IronFunctions，將有助于避免被提供商捆綁，使我們能夠在不同的云提供商或甚至內部運行無服務器應用程序。