無服務器架構，通常被稱為“無服務器計算”，但并不像其名稱所暗示的那樣完全沒有服務器。無服務器架構是一種基于應用的云計算服務，其中由云計算提供商管理服務器，提供更高的效率和潛在的成本節約。對于大多數云計算用戶來說，這更容易和有效。

[[269372]]

無服務器也稱為功能即服務(FaaS)，無需存儲數據即可執行應用程序邏輯。利用FaaS的開發人員仍然需要編寫服務器端邏輯，但它運行在短暫的無狀態容器中?？蛻舳藨贸绦?包括移動應用程序)可利用基于云計算的基礎設施后端即服務(BaaS)。

“無服務器”一詞的使用可以追溯到2012年。而AWS公司在2014年推出了Lambda(公共云供應商提供的第一個無服務器計算產品)，加速了該術語的主流使用。2016年，谷歌云推出Google Cloud Functions，Microsoft Azure推出了Azure Functions，IBM Cloud推出了IBM Functions，而OpenWhisk開源項目則首次亮相。

無服務器有時會與云計算的平臺即服務(PaaS)混淆。后端即服務(BaaS)和功能即服務(FaaS)都是云計算提供商提供的服務選項，但功能即服務(FaaS)在幾個重要方面與平臺即服務(PaaS)不同。例如，功能即服務(FaaS)會自動擴展，但平臺即服務(PaaS)則不能。此外，功能即服務(FaaS)可以使整個應用程序上下移動，而平臺即服務(PaaS)并沒有這樣的專門設計。

無服務器架構使用了大量的應用程序粒度;它適用于當今的微服務世界，而不是早期的單片架構。

無服務器示例

• 照片應用的用戶可以在選擇照片時自動調整大小。照片將發送到Amazon S3存儲桶，該存儲桶使用無服務器來觸發相應的Lambda功能。其輸出是用戶選擇的照片大小。
• 應用內游戲開發者希望能夠使其購買變得不再繁瑣，因為應用評論受到了影響。玩家現在可以將鼠標懸停在他們想要購買的產品上。例如玩家將鼠標懸停在“Neo太陽鏡”上，通過API網關觸發虛擬產品和購買功能。每個無服務器功能都使用一個數據庫。幾秒鐘之內，所選的角色就戴上了太陽鏡，因為現在角色就擁有太陽鏡，它可能會被隨意移除或重新戴上。

無服務器用例

• Web應用程序
• 異步消息處理。例如，應用程序的用戶界面(UI)響應時間和準確的交易歷史記錄都很重要
• 需要自動擴展功能的聊天機器人
• 大規模流處理
• 移動應用程序后端
• 批處理作業
• 多媒體處理
• 數據處理
• 聊天機器人和虛擬助理
• IT自動化

無服務器的好處

• 減少開銷。應用程序可以在沒有使用功能即服務(FaaS)的服務器的情況下運行，因此無需配置或管理服務器。
• 自動縮放。功能即服務(FaaS)自動縮放，向上或向下擴展，因此客戶無需為閑置容量支付費用。
• 高可用性。應用程序可用性不是問題，因為功能即服務(FaaS)和后端即服務(BaaS)可用性不是問題。
• 選擇。功能即服務(FaaS)允許開發人員使用流行語言和庫。
• 成本。與平臺即服務(PaaS)和基礎設施即服務(IaaS)一樣，無服務器云計算提供商擁有硬件和軟件元素。服務器管理成本也是外包的。
• 簡單。部署功能即服務(FaaS)功能就像上傳代碼一樣簡單;部署服務器涉及腳本和面向資源的決策。
• 速度。由于無服務器無需服務器及其管理，因此節省了寶貴的IT時間。它還加速了實驗和原型設計。

無服務器的缺點

• 無狀態與狀態。對于使用面向狀態功能的應用程序體系結構來說，功能即服務(FaaS)的無狀態性質可能是一個問題。
• 超時。如果應用程序包含超出超時限制的任務，功能即服務(FaaS)超時可能會影響應用程序體系結構。
• 啟動延遲。功能即服務(FaaS)啟動延遲可能會排除極其敏感的用例，例如算法交易。
• 服務水平協議。缺乏服務等級教育協議(SLA)一直是個問題。在2018年10月，AWS公司宣布Lambda的每月正常運行時間為99.95%。
• 功能配置。配置功能即服務(FaaS)的能力可能有限。
• 并發限制。允許的并發功能即服務(FaaS)功能的數量是有限的。如果由于同時進行測試和生產，共享企業帳戶，跨多個云服務的帳戶超出該數量，則生產應用程序性能可能會受到影響。
• 功能即服務(FaaS)監控。這里的兩個問題是供應商提供了多少數據，以及監控臨時容器的一般困難。
• 供應商鎖定。云計算提供商希望難以轉移到其他提供商。有兩種方法可以使平臺特有的工具和設計功能不同。
• 控制。供應商可以完全控制基礎設施、定價和功能。
• 成本。無服務器并不總是比其他選項便宜，因此理解與其他選項相比的成本/收益權衡是明智的。使用功能即服務(FaaS)，功能在調用之前不需要任何費用。

無服務器的安全性

• 攻擊面擴大。生態系統中的任何新元素都會增加潛在的破壞機會。此外，與使用傳統架構的應用程序相比，無服務器應用程序具有更多的組件。每個組件都是應用程序的唯一入口點。
• 功能許可。有時，當權限越窄越明智時，廣泛的權限可能會應用于一系列功能。
• 多租戶。其他客戶不應該看到企業數據，但可能是這樣。這是主要提供商主動解決的一般云計算問題。
• 第三方軟件依賴性。功能可能依賴于已泄露的第三方軟件。

無服務器架構入門

開始使用無服務器架構的適合方法是完全理解文中的所有內容：它是什么，它的優點和缺點是什么，因此可以定義適當的用例。

具體來說，如果要將無服務器應用程序添加到現有應用程序或構建新的無服務器應用程序，需要考慮以下內容：

• 了解無服務器是什么或不是什么。
• 了解使用傳統架構應用程序和無服務器應用程序之間的權衡。
• 確定企業是要構建無服務器應用程序還是修改現有應用程序以利用后端即服務(BaaS)、功能即服務(FaaS)或兩者兼而有之。
• 選擇一個提供者(可能是企業使用過的提供者)。

假設企業選擇了AWS Lambda，這是一種特別受歡迎的無服務器解決方案：

• 設置Lambda功能(內存和存儲要求、觸發器、訪問)。
• 設置Amazon API網關。
• 要適應現有應用程序，請使用AWS步驟功能進行工作流管理。
• 通過Amazon身份訪問管理和Cognito服務設置訪問和安全。
• 對于日志記錄和監控，使用AWS Cloudwatch和X-Ray。
• 如果需要本地應用程序測試，請使用AWS無服務器應用程序模型。
• 滿足合規要求。
• 將無服務器架構模式與同一類型應用程序的常見模式進行比較。

如何管理無服務器架構

顧名思義，在無服務器云服務的情況下，IT不管理服務器。對于本地功能即服務(FaaS)實施(例如由Apache OpenWhisk、Kubeless和OpenFaaS啟用的實施)，服務器在內部進行管理。

雖然基于應用的云計算優勢不適用于本地功能即服務(FaaS)實施，但可以實現更高的服務器利用率，開發人員仍然可以從無服務器提供的抽象中受益。

但是，仍有一些操作問題需要考慮，例如權限、安全性、依賴性和其他問題，這取決于應用程序的設計，這些問題不會消失。

關鍵問題是：企業是否擁有管理無服務器所需的內部專業知識?直到現在，無服務器仍然是一項新興技術，因此不要假設企業的內部人員或開發人員是專家。

無服務器計算的未來

隨著無服務器選項越來越受歡迎，以下內容可能會展開：

• 更多更好的工具。這是一個市場成熟度問題，它也是受歡迎程度與其他選項的功能。無服務器變得越流行，工具和開源項目就越多。
• 優秀實踐。由于無服務器是一個相對較新的概念，目前還沒有很多優秀實踐，但是無服務器架構模式可用于上述許多用例。
• 無服務器優先應用程序。在某些用例中，可能會出現更多的無服務器應用程序，而不是通過修改應用程序來利用無服務器選項。
• 框架。將出現額外的框架，使其更容易與一個供應商而不是另一個供應商合作。目前的例子是Fn Project，它是一個容器本地開源框架和無服務器框架，可以將無服務器應用程序部署到多個功能即服務(FaaS)提供程序。
• 私有功能即服務(FaaS)。功能即服務(FaaS)已經可以在企業內部實施。與云計算服務或混合云實施相比，時間會證明這將成為主流。