無伺服器運算
在雲端運算早期,Amazon 和 Microsoft 等雲端服務提供者均著重於為客戶提供豐富的 IaaS 服務。 這讓客戶能輕鬆將在實體伺服器或虛擬機器中執行內部部署的工作負載,轉移到雲端中的虛擬機器,以推動公用雲端的成長。 但隨著 IaaS 出現,責任也隨之而來。 在雲端中啟動 VM 的組織還要負責維護 VM 內部的內容,包括作業系統、所需的任何執行階段、使用這些執行階段的應用程式等。
PaaS 會將這其中的部分責任轉移給雲端服務提供者,並進一步推動了在雲端中的投資。 透過 AWS Elastic Beanstalk 和 Azure App Service 等服務,客戶就可以佈建配備了熱門執行階段 (例如 JAVA、Node.js 和 Microsoft .NET) 的虛擬 Web 伺服器,並在短短數分鐘內讓軟體在其上執行。 當虛擬機器在幕後執行繁重的作業時,這些虛擬機器的存在大多都是抽象的。 PaaS 讓客戶能專注於自己撰寫來解決業務問題的應用程式,而不是花時間來管理 VM,以及保持平台已修補和最新狀態。
「無伺服器運算」是雲端運算中相對較新的創新,會進一步採用此類抽象概念。 假設貴組織所撰寫和維護的程式碼會執行任務關鍵性資料的夜間備份、執行每週計費回合,或是在每次將發票上傳至雲端儲存體時傳輸電子付款。 在此情況下,整體目標是執行此程式碼,且是在適當的時間執行。 其他任何事項都是次要的,包括程式碼的儲存位置,以及執行的方式和位置。
您可以建立一或多部 VM 來執行程式碼,並安裝必要的平台和程式庫,以採用 IaaS 方法。 您可以佈建 Elastic Beanstalk 或 App Service 執行個體,並在該處裝載程式碼。 或者,您可以使用函式執行階段 (例如 AWS Lambda 或 Azure Functions) 來執行所需的程式碼,而不需考慮其裝載的位置或方式。 AWS Lambda 和 Azure Functions 都是無伺服器運算 (特別是無伺服器函式) 的範例,與 Google Cloud Functions 相同。 這三者均代表雲端運算從 IaaS (您需負責一切) 自然演進到無伺服器的下個步驟,無伺服器表示您可專注於想在雲端中執行的動作 (您想執行的程式碼),然後讓雲端服務提供者管理所有其他事務。
在雲端中,函式執行階段所執行的無伺服器函式是最常見的無伺服器運算形式,但這並不是唯一的形式。 Amazon、Microsoft 和 Google 均會提供一些其他 PaaS 服務的無伺服器版本,包括無伺服器資料庫。 有些提供者支援無伺服器工作流程,可讓您在雲端中定義業務工作流程,並執行它們來回應外部事件,例如將發票上傳至雲端儲存體、計時器依指定間隔引發,或是電子郵件送達收件匣 (通常不需撰寫任何一行程式碼)。 最後,雲端服務提供者所提供的許多容器服務 (包括 Azure 容器執行個體和 AWS Elastic Container Service) 都適合作為無伺服器運算的範例,因為它們可讓您在雲端中執行容器,同時持續將基礎結構抽象化。
無伺服器運算的優點
無伺服器運算可為運用雲端運算的組織提供三個主要優點:
較低的運算成本:客戶通常會針對 IaaS 虛擬機器和 PaaS 服務 (例如 Elastic Beanstalk 和 Azure App Service) 支付每月費用。 即使服務處於閒置狀態,仍會繼續計費。 不過,大部分的無伺服器運算服務都支援使用量定價,您只需為執行程式碼的時間支付費用。 假設您將每月 100 美元的 VM 用於執行程式碼,讓程式碼執行任務關鍵資料的晚間備份,而且每晚都會執行 30 分鐘。 您每月支付 100 美元,只為了在 1/48 個月 (或少於一天) 內執行程式碼。 若將相同的程式碼部署為無伺服器函式,每月只需支付數美元的費用。 採用使用量定價,您就不需為閒置時間支付費用。
自動可擴縮性:雲端提供者提供在產品中擴縮 IaaS 服務的機制,例如 Azure 的 AWS Auto Scaling 和虛擬機器擴展集。 此外也提供 PaaS 服務的手動和自動擴縮選項。 但即使擴縮會自動執行,雲端管理員還是必須啟用自動擴縮並加以設定,才能讓雲端提供者知道應如何及何時進行擴縮。 管理員必須考慮的其中一個基本事項是,因為您需要為 IaaS 和 PaaS 服務的個別執行個體支付費用,所以您希望將服務設定為擴充到足夠的程度,但又不會擴充太多。 無伺服器運算所提供的選項可明確地自動擴增以符合增加的需求,並在需求減少時縮減。 雲端管理員通常不需執行任何設定,只要在服務中啟用此選項即可。 如果您一次遇到 100 個執行無伺服器函式的要求,雲端服務提供者就會確保可平行 (或大部分平行) 執行要求。 成本不會受到影響,因為採用使用量定價方式,不論是循序還是平行執行,成本都與執行 100 次函式相同。
降低管理成本:無伺服器可讓您專注於執行程式碼和工作流程,同時將所有其他事務 (包括維護基礎平台) 的責任都轉移給雲端服務提供者。
無伺服器運算也有缺點。 一些需考慮的限制包括:
某些函式執行階段會對允許函式執行的時間長度施加限制。
某些函式執行階段不保證函式將會立即執行,除非您願意為此支付更多費用。 例如,當 Azure Functions 設定為利用以使用量為基礎的定價時,函式可能不會在觸發後 (最多 10 分鐘) 執行。 這對夜間備份來說也許不是問題;您可能不在意備份是在凌晨 1:00 還是 1:10 執行,但這可能會成為時間關鍵函式的交易中斷因素,這類函式必須即時執行 (或近乎即時)。
無伺服器函式通常是無狀態的,也就是說,它們不能在內部儲存資料,並預期會從一個函式叫用過程保存到下一個。 它們可以使用外部雲端儲存體服務 (例如 Amazon S3 和 Azure 儲存體) 來保存呼叫之間的資料,但這讓函式的程式碼變得更複雜。
有些雲端服務提供者支援具狀態的函式 (Azure 稱為「Durable Functions」),但是,保留狀態的函式是無伺服器運算中相對較近期新增的功能,普遍未受到支援。
無伺服器函式
無伺服器運算最常見的範例就是無伺服器函式。 您將程式碼上傳至雲端,並告訴它何時執行。 程式碼可以使用各種不同語言來撰寫,包括 Java 和 C#。
圖 11 列出在撰寫此文章時,Azure、AWS 和 GCP 中無伺服器函式所支援的程式設計語言:
語言 | Azure Functions | AWS Lambda | Google Cloud Functions |
---|---|---|---|
C# | x | x | |
F# | x | ||
Go | x | x | |
Java | x | x | |
JavaScript (Node.js) | x | x | x |
PowerShell | x | x | |
Python | x | x | x |
Ruby | x | ||
TypeScript | x |
圖 11:常見無伺服器函式執行階段支援的程式設計語言。
建立函式並提供要執行的程式碼時,您也會識別導致函式執行的外部事件。 熱門的雲端平台支援各種類型的觸發程序,包括計時器、其他雲端服務中發生的事件 (例如將文件上傳至雲端儲存體),以及 HTTP 呼叫。 將計費程式碼上傳至函式執行階段,並將執行時間設定為每天一次、每周一次或每月一次,是很簡單的操作。 每次將發票上傳至雲端儲存體 (例如 Amazon S3 或 Azure 儲存體),或將呼叫放入與函式相關聯的 REST 端點時,啟動函式同樣很簡單。
無伺服器函式經常用來執行獨立的工作,例如夜間備份和計費。 它們也會用來連接其他雲端服務,並使用雲端服務作為建置組塊來撰寫豐富的解決方案。 圖 12 介紹一個這類型的解決方案,用於結合數個 Azure 服務來監視北極的北極熊活動。 Azure 函式在架構中扮演了一個重要角色,它會取得 Azure 串流分析 (由 HTTP 呼叫所觸發) 的輸出、接收來自 Azure Blob 儲存體的相片,並將該相片提交至使用 Azure 自訂視覺服務定型的模型,藉此利用人工智慧 (AI) 來判斷相片中是否包含北極熊。 此函式是將串流分析、Blob 儲存體和自訂視覺服務繫結在一起的黏著劑。
圖 12:使用 Azure 函式來連接其他 Azure 服務。
無伺服器工作流程
某些無伺服器運算服務可讓客戶將業務工作流程自動化,而不需撰寫程式碼來執行。 例如,Azure Logic Apps 提供 100 個以上的內建「連接器」與資料來源互動,範圍從 Oracle 資料庫到 X 等社交媒體服務。其會提供「觸發程序」,定義工作流程應該執行的時間 -- 例如,當檔案上傳至 Box.com 或使用主題標籤發佈推文時。 此外也提供數百個預先定義的動作,定義觸發程序引發時要執行的動作,而且可鏈結在一起來組成複雜的工作流程,且可透過條件讓動作依條件執行。 而且還能無限擴充,因為 Azure Logic Apps 支援的其中一個動作就是呼叫 Azure 函式。 如果工作流程涉及未封裝於動作中的自訂邏輯,則您可以提供程式碼來實作該邏輯,並將它包含於工作流程中,就像是預先定義的動作一樣。
圖 13 顯示 Azure Logic Apps 設計工具中的一個此類工作流程1。 當電子郵件送達時,邏輯應用程式就會立即採取行動,並檢查電子郵件主旨列中是否有關鍵片語,以及是否有附件存在。 如果同時滿足這兩個條件,邏輯應用程式就會叫用 Azure 函式,從電子郵件內文中移除所有 HTML。 然後,將已處理過的電子郵件和隨附的所有附件放在 Azure Blob 儲存體中,並傳送電子郵件,郵件內包含 Blob 儲存體中相關文件的連結,藉此通知感興趣的對象,該資訊可供使用且正等待審核。 此範例結合了兩個無伺服器範例:在沒有任何程式碼 (至少沒有您或貴組織中任何人撰寫的程式碼) 的情況下執行動作的邏輯應用程式,以及包含您提供用來自訂工作流程之程式碼的 Azure 函式,此範例為雲端運算中發生的典型轉移,範圍可從自助式虛擬機器到更高層級的抽象概念,讓組織能專注於解決業務問題,而不是管理虛擬機器以及安裝和維護執行階段。
圖 13:在 Azure Logic Apps 中定義工作流程。
Amazon 以 AWS Step Functions 形式提供類似的服務。 使用 Step Functions,您可以撰寫結合其他服務 (例如 AWS Lambda 和 AWS ECS) 的視覺化工作流程。 工作流程由一系列步驟組成,其中每個步驟的輸出均會作為下一個步驟的輸入。 如同 Azure Logic Apps,AWS Step Functions 提供分支和平行執行的基本功能,讓您不必撰寫程式碼,就能執行相同動作。 實際上,業務工作流程會變成一個容易了解、容易向他人說明且容易修改的具狀態機器圖表。
無伺服器資料庫
早期的雲端運算技術將資料庫裝載於雲端,這表示需佈建虛擬機器並安裝資料庫產品,例如 MySQL、PostgreSQL 或 SQL Server。 PaaS 藉由提供資料庫即服務改變了這個做法。 例如,利用 Azure SQL Database 或 Amazon Relational Database Service (RDS),您只需佈建執行個體,就能在數分鐘內讓雲端裝載的資料庫準備好服務用戶端。 此外,雲端服務提供者會套用軟體更新和修補程式,讓資料庫平台保持在最新狀態。
雲端運算中較新的創新技術是無伺服器資料庫,可提供最佳化的性價比模型,非常適合具有不規則使用量模式的單一資料庫。 例如,Azure 提供無伺服器版本的 Azure SQL Database。 利用 Azure SQL Database 的主要版本,您可以根據預期資料庫能處理的負載上限來選擇性價比層級。 如果負載是「尖峰」或間歇性的,則您最終經常會因為資料庫隨時都會經歷高負載而支付費用。
無伺服器版本的 Azure SQL Database 可視需要縮放資料庫以處理經歷的負載來減緩此情況,並根據運算成本和儲存體成本的總和來降低成本。 就像利用使用量模型的無伺服器函式一樣,您只需為使用的部分付費。 Amazon 以 AWS Aurora Serverless 形式提供類似服務,這是 Amazon Aurora 資料庫服務的無伺服器版本,而 Google 為客戶提供無伺服器的 NoSQL 資料庫服務 (稱為 Google Cloud Firestore)。
參考資料
- Microsoft (2019 年)。 Automate handling emails and attachments with Azure Logic Apps (使用 Azure Logic Apps 自動處理電子郵件和附件)。 https://zcusa.951200.xyz/azure/logic-apps/tutorial-process-email-attachments-workflow.