利用無伺服器函式

提示

此內容摘錄自《建構適用於 Azure 的雲端原生 .NET 應用程式》電子書，您可以在 .NET Docs 找到此電子書，或免費下載可離線閱讀的 PDF。

下載 PDF

從管理實體機器到利用雲端功能，無伺服器代表了兩個極端。 您只需要負責自己的程式碼，而且只有在您的程式碼執行時才需要支付費用。 Azure Functions 可讓您在雲端原生應用程式中建置無伺服器功能。

什麼是無伺服器？

無伺服器是相對新穎的雲端運算服務模型。 這並不表示伺服器是選擇性的，您的程式碼仍在某處的伺服器上執行。 差別在於，應用程式團隊不用再費心管理伺服器基礎結構。 而是將此歸責於雲端廠商。 開發團隊向客戶提供商務解決方案而非管道，藉以提高生產力。

無伺服器運算使用事件觸發的無狀態容器來裝載您的服務。 他們可以擴增與縮減，視需要滿足需求。 Azure Functions 之類的無伺服器平台可與其他 Azure 服務緊密整合，例如佇列、事件和儲存體。

無伺服器可解決哪些挑戰？

無伺服器平台可解決許多耗時且昂貴的考量：

• 購買機器和軟體授權
• 收納、保護、設定與維護機器及其網路、電源和 A/C 需求
• 修補與升級作業系統和軟體
• 設定 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 處理應用程式工作會增加複雜性。 最好先使用模組化的鬆散結合設計來建構您的應用程式。 然後，找出無伺服器是否有克制額外複雜度的優勢。

上一個下一個