在從管理實體機器到利用雲端功能的光譜上，無伺服器位於最極端的一端。 您唯一的責任是您的程序代碼，而且只有在程式代碼執行時才會支付費用。 Azure Functions 可讓您在雲端原生應用程式中建置無伺服器功能。
什麼是無伺服器？
無伺服器是相對新的雲端運算服務模型。 這並不表示伺服器是選擇性的， 您的程式代碼仍會在某處的伺服器上執行。 差別在於，應用程式小組不再擔心管理伺服器基礎結構。 相反地，雲端廠商擁有此責任。 開發小組藉由為客戶提供商務解決方案來提升生產力，而不是管道。
無伺服器運算會使用事件觸發的無狀態容器來裝載您的服務。 他們可以擴展和縮小，以應需求。 Azure Functions 之類的無伺服器平臺與其他 Azure 服務緊密整合，例如佇列、事件和記憶體。
無伺服器可以解決哪些挑戰？
無伺服器平臺可解決許多耗時且昂貴的問題：
- 購買機器和軟體授權
- 安置、保護、設定和維護機器，以及滿足它們的網路、電力和空調需求
- 修補和升級作業系統和軟體
- 設定 Web 伺服器或電腦服務以裝載應用程式軟體
- 在其平台內設定應用程式軟體
許多公司都會配置大量預算來支持硬體基礎設施需求。 移至雲端有助於降低這些成本;將應用程式轉移到無伺服器有助於消除它們。
微服務與無伺服器函式之間的差異為何？
一般而言，微服務會封裝商務功能，例如在線電子商務網站的購物車。 它會公開多個作業，讓用戶能夠管理其購物體驗。 不過，函式是小型輕量型程式代碼區塊，可執行單一用途作業以回應事件。 微服務通常被設計來回應請求，通常是通過介面來進行。 要求可以是基於 HTTP REST 或 gRPC 的。 無伺服器服務會回應事件。 其事件驅動架構非常適合用來處理短期執行的背景工作。
哪些案例適用於無伺服器？
無伺服器架構提供個別短時間運行的函式，這些函式會在觸發事件時被叫用。 這使得它們非常適合用於處理背景工作。
應用程式可能需要以工作流程中的步驟傳送電子郵件。 不要將通知當做微服務要求的一部分傳送，而是將訊息詳細數據放在佇列上。 Azure 函式可以移除佇列中的訊息，並以異步方式傳送電子郵件。 這樣做可以改善微服務的效能和延展性。 您可以實作佇列型負載撫平，以避免傳送電子郵件的相關瓶頸。 此外，這個獨立服務可以作為工具，重複使用於許多不同的應用程式。
來自佇列和主題的異步傳訊是觸發無伺服器函式的常見模式。 不過，Azure Functions 可由其他事件觸發，例如 Azure Blob 記憶體的變更。 支援影像上傳的服務可能會有 Azure 函式負責優化影像大小。 函式可以直接藉由插入 Azure Blob 儲存體來觸發，從而簡化微服務操作的複雜性。
許多服務在其工作流程中都有長時間執行的進程。 這些工作通常是在使用者與應用程式的互動中完成。 這些工作可以強制使用者等候，對他們的體驗造成負面影響。 無伺服器運算提供在用戶互動迴圈之外移動較慢工作的絕佳方式。 這些工作可以隨需求進行調整，而不需要整個應用程式進行調整。
何時應避免無伺服器？
無伺服器解決方案能依需求迅速配置和擴展。 叫用新的實例時，冷啟動是常見的問題。 冷啟動期是布建此實例過程中所需的時間。 通常，此延遲可能是幾秒鐘，但可能會根據各種因素而較長。 布建之後，只要單一實例收到定期要求，單一實例就會保持運作。 但是，如果服務呼叫頻率較低，Azure 可能會從記憶體中移除它，並在重新叫用時需要冷啟動。 當函數擴展到新的實例時，冷啟動也是必須的。
圖 3-9 顯示冷啟動模式。 注意當應用程式處於未使用狀態時所需的額外步驟。
圖 3-9。 冷啟動與暖啟動。
若要完全避免冷啟動，您可能會從 取用方案切換到專用方案。 您也可以使用進階方案升級來設定一或多個 預先暖化實例 。 在這些情況下，當您需要新增另一個實例時，它已啟動並準備好進行。 這些選項有助於減輕與無伺服器運算相關聯的冷啟動問題。
雲端提供者會根據計算運行時間和耗用的記憶體來計費無伺服器。 長時間執行的作業或高記憶體耗用量工作負載不一定是無伺服器的最佳候選專案。 無伺服器函式支援可快速完成的小型工作區塊。 大部分無伺服器平臺都要求單一函式需在幾分鐘內完成。 Azure Functions 預設為 5 分鐘的逾時持續時間，最多可以設定 10 分鐘。 Azure Functions 進階方案也可以減輕此問題，將逾時預設為 30 分鐘，並具有可設定的無限制上限。 計算時間不是行事歷時間。 使用 Azure Durable Functions 架構 的更進階函式可能會在幾天內暫停執行。 計費是以函式被喚醒後並恢復處理的實際執行時間為基礎。
最後，利用 Azure Functions 來執行應用程式工作會增加複雜性。 最好先使用模組化、鬆散結合的設計來建構您的應用程式。 然後，判斷伺服器無需管理是否有優點可以抵銷其增加的複雜性。
