無伺服器運算平台比較與框架詳解

– 11 分鐘閱讀

無伺服器運算的興起，讓開發者得以擺脫伺服器管理的負擔，專注於程式碼的開發與業務邏輯的實作。AWS Lambda 作為先驅者，提供簡便的佈署方式和彈性擴充套件能力，但執行時間和資源限制仍需考量。Azure Durable Functions 則針對長時間任務和狀態管理提供更完善的支援。Google Cloud Functions 與 Google Cloud 平台的深度整合，使其在事件驅動架構中表現出色。IBM Cloud Functions 則受益於 Apache OpenWhisk 的開源生態，提供更靈活的觸發機制。選擇合適的平台需要根據實際需求進行權衡。

無伺服器運算服務比較：AWS Lambda、Azure Functions 與 Google Cloud Functions

無伺服器運算（Serverless Computing）已成為現代雲端運算的重要趨勢，各大雲端供應商如 Amazon、Microsoft 和 Google 都提供了相關服務。本篇文章將探討 AWS Lambda、Azure Functions 和 Google Cloud Functions 這三種無伺服器運算服務的特點、優勢與限制。

AWS Lambda

AWS Lambda 是 Amazon 提供的無伺服器運算服務，允許開發者執行程式碼而無需管理伺服器。Lambda 的設計目標是支援多種程式語言，事實上，Lambda 的沙盒環境僅是一個容器，因此理論上可以執行任何語言的程式碼。

執行原生可執行檔

要在 Lambda 中執行非 Node.js 程式碼，可以透過 Node.js 程式呼叫 ZIP 檔案中的二進位制可執行檔。不過，這需要確保二進位制檔案是靜態編譯的，或與 Amazon Linux 提供的共用函式庫相容，因為 Lambda 的容器根據 Amazon Linux。

// 使用 Node.js 執行自訂二進位制檔案的範例
const childProcess = require('child_process');

exports.handler = async (event) => {
    // 執行自訂二進位制檔案
    childProcess.execFileSync('./myBinary', (err, stdout, stderr) => {
        if (err) {
            console.error(err);
            return;
        }
        console.log(stdout);
    });

    return {
        statusCode: 200,
        body: '執行完成',
    };
};

內容解密：

此範例程式碼展示瞭如何在 AWS Lambda 的 Node.js 環境中執行自訂的二進位制可執行檔。首先，我們匯入了 childProcess 模組，該模組允許 Node.js 執行子行程。接著，在 Lambda 的處理函式中，我們使用 execFileSync 方法同步執行名為 myBinary 的二進位制檔案，並處理可能的錯誤。最後，Lambda 傳回一個成功的回應。

LambCI 的幫助

為瞭解決相容性問題，開發者可以使用 LambCI 這個開源專案。LambCI 提供了一個 Docker 容器，模擬了 AWS Lambda 的執行環境，包括軟體、函式庫、檔案結構和許可權等，使得開發者可以在本地端安全地測試程式碼，確保其在 Lambda 上能正常執行。

# 使用 LambCI Docker 容器測試 Lambda 函式
docker run -v "$PWD":/var/task lambci/lambda:nodejs14.x index.handler

內容解密：

此命令將當前目錄掛載到 LambCI 的 Lambda 容器中，並執行 index.handler 函式。這使得開發者能夠在本地模擬 Lambda 環境，進行測試和除錯。

Azure Functions

Azure Functions 是 Microsoft 提供的無伺服器運算服務，作為 Azure Cloud 的一部分。與其他無伺服器服務一樣，Azure Functions 允許開發者執行應用程式邏輯而無需管理基礎設施。

語言支援

目前，Azure Functions 支援多種程式語言，包括 C#、F#、Java、JavaScript（Node.js）等。其中，C# 和 F# 因為是 Microsoft 自家語言，因此獲得了優先支援。

套件管理

開發者可以使用 NuGet 管理 .NET 語言的依賴套件，而對於 Node.js，則可以使用 NPM 進行套件管理。

// 使用 C# 開發 Azure Function 的範例
using Microsoft.AspNetCore.Http;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Azure.WebJobs;
using Microsoft.Azure.WebJobs.Extensions.Http;

public static class MyFunction
{
    [FunctionName("MyFunction")]
    public static IActionResult Run(
        [HttpTrigger(AuthorizationLevel.Function, "get", Route = null)] HttpRequestData req)
    {
        return new OkObjectResult("Hello, Azure Functions!");
    }
}

內容解密：

此 C# 範例展示瞭如何建立一個簡單的 Azure Function。該 Function 由 HTTP 觸發，並傳回一個簡單的訊息。程式碼中使用了 HttpTrigger 屬性來定義觸發器，並透過 OkObjectResult 傳回 HTTP 回應。

定價模式

Azure Functions 提供兩種定價方案：消費計劃和應用程式服務計劃。消費計劃類別似於其他雲端供應商的模式，按實際執行時間計費；而應用程式服務計劃則將 Functions 視為應用程式的一部分，在某些情況下可能不需要額外付費。

觸發與繫結機制

Azure Functions 的一大特點是其觸發和繫結機制。開發者可以在獨立的設定檔中定義如何觸發 Function，以及輸入輸出的資料繫結，從而避免在程式碼中進行硬編碼。

// Azure Function 的 function.json 範例
{
  "bindings": [
    {
      "name": "req",
      "type": "httpTrigger",
      "direction": "in",
      "authLevel": "function",
      "methods": ["get"]
    },
    {
      "name": "$return",
      "type": "http",
      "direction": "out"
    }
  ]
}

內容解密：

此 function.json 檔案定義了一個 HTTP 觸發的 Azure Function。設定檔中指定了輸入的 HTTP 請求和輸出的 HTTP 回應，使得 Function 的觸發和資料處理更加靈活。

擴充套件性

Azure Functions 具備自動擴充套件能力。Azure 的 Scale Controller 元件會即時監控請求數量，並根據需求動態調整 Function 的例項數量。

Durable Functions

Azure 提供了 Durable Functions 擴充套件，支援在無伺服器環境中實作有狀態的 Function。透過 Orchestrator Function，開發者可以實作複雜的工作流程，並支援狀態管理、檢查點和重啟等功能。

// Durable Functions 的 Orchestrator Function 範例
[FunctionName("MyOrchestrator")]
public static async Task Run(
    [OrchestrationTrigger] IDurableOrchestrationContext context)
{
    await context.CallActivityAsync("MyActivity", "Hello, Durable Functions!");
}

內容解密：

此範例展示了一個 Orchestrator Function，它呼叫了一個名為 MyActivity 的 Activity Function。Durable Functions 允許開發者在無伺服器環境中實作有狀態的工作流程，並支援狀態持久化和重試機制。

Google Cloud Functions

Google Cloud Functions（GCF）是 Google 提供的無伺服器運算服務。與其他無伺服器平台類別似，GCF 提供了執行環境和 SDK，幫助開發者開發和管理 Function 的完整生命週期。

語言支援與佈署

GCF 主要支援 JavaScript，並提供 Node.js Docker 映像檔，方便開發者建構和佈署 Function。使用 Google Cloud CLI 工具可以輕鬆佈署 Function。

// 使用 Node.js 開發 Google Cloud Function 的範例
exports.myFunction = async (req, res) => {
    res.send('Hello, Google Cloud Functions!');
};

內容解密：

此 Node.js 範例展示瞭如何建立一個簡單的 Google Cloud Function。該 Function 由 HTTP 請求觸發，並傳回一個簡單的訊息。

與其他 Google 服務的整合

GCF 能夠輕鬆連線其他 Google 服務，如 Cloud Storage、Cloud Pub/Sub 等，適合用於 IoT、資料處理等場景。

IoT 應用範例

下圖展示了一個典型的 IoT 應用場景，使用 Google Cloud Functions 進行資料處理，並將資料傳送到 Big Data 堆積疊和 Firebase。

  graph LR
    A[IoT 裝置] -->|資料| B(Cloud IoT Core)
    B -->|訊息| C(GCF)
    C -->|處理後資料| D(Big Data 堆積疊)
    C -->|資料| E(Firebase)
    E -->|資料| F[行動應用程式]

圖表翻譯：

此圖展示了一個典型的 IoT 資料處理流程。IoT 裝置將資料傳送到 Cloud IoT Core，再透過 Cloud Pub/Sub 將訊息傳送到 Google Cloud Functions 進行處理。處理後的資料會被傳送到 Big Data 堆積疊進行進一步分析，同時也會被傳送到 Firebase，為行動應用程式提供後端支援。

Google Cloud Functions（GCF）深度解析與應用實踐

概述

Google Cloud Functions（GCF）作為一種Serverless架構的核心元件，專注於實作單一且明確的功能目標。由於其本質特性，函式（Function）的設計不宜過於複雜。GCF實際上是事件驅動程式設計模型的一個子集，所有雲端函式均以此模型運作，各個元件透過事件傳遞相互連線，並可進行監控。當特定事件源觸發時，相關聯的雲端函式便會自動執行。

GCF 的技術特性與優勢

GCF支援以JavaScript撰寫函式，或使用可轉譯為JavaScript的程式語言。目前執行的環境是Node.js v6.11.5，通常開發者會使用相同版本的Node.js執行環境，以確保良好的可移植性。利用JavaScript和Node.js生態系統，開發者不僅可以進行本地測試，還能使用大量的Node.js函式庫，包括Google Cloud提供的API，簡化開發流程並促進整合。

GCF的設計宗旨是作為連線或膠合層，將不同的服務連結起來。在某些使用案例中，函式被用來擴充套件現有的雲端服務。例如，透過事件驅動模型，函式可以監聽檔案上傳事件，當檔案被放入雲端儲存時觸發；也可以訂閱Pub/Sub主題，在接收到通知時觸發函式執行。

GCF 的應用場景

由於GCF具備存取GCP憑證系統的能力，因此能夠與大量的GCP服務進行身份驗證，使其在Google的平台上非常實用。開發者只需關注程式碼本身，所有基礎設設和系統軟體層都由Google的平台全權管理。此外，GCF具備自動擴充套件功能，當觸發次數增加時，系統會自動組態額外的計算資源，無需手動干預。

支援的工作負載

GCF支援多種工作負載，包括但不限於：

  • 資料處理/ELT（Extract, Load, Transform）
  • WebHooks實作
  • API實作
  • 作為行動應用的後端
  • 接收來自IoT裝置的串流資料

執行模型

在GCF中，每個雲端函式都會在根據容器的隔離環境中獨立執行，確保安全性和互不幹擾。GCF選擇支援JavaScript執行於Node.js v6.11.5，並承諾將緊隨Node.js的長期支援（LTS）版本更新，確保執行環境的安全性和穩定性。

容器基礎

GCF的基礎映像檔定期更新，並可從gcr.io/google-appengine/nodejs取得。系統透過繼承該映像檔並安裝特定版本的Node.js（例如v6.11.5）來準備執行環境。示例如下：

FROM gcr.io/google-appengine/nodejs
RUN install_node v6.11.5

無狀態性

撰寫Serverless FaaS函式時，無狀態（Stateless）是首選模型。由於執行環境可能隨時擴充套件或縮減，無法預期函式狀態會被保留。因此，最好不要將資料儲存於函式的本地儲存。如果需要記憶體，例如跨函式例項分享的全域變數，必須透過外部儲存服務進行明確管理。

超時機制

Serverless平台通常會限制雲端函式的執行時間，以防止過度使用計算資源。GCF的預設超時時間為1分鐘，可延長至最長9分鐘。當函式執行超時，其執行中的程式碼將被終止。例如，若函式設定在啟動後3分鐘執行，但超時時間設定為2分鐘，則該函式將永遠不會執行。

程式碼實作與最佳實踐

在實作GCF時，開發者應遵循最佳實踐，確保函式設計的合理性和高效性。以下是一個簡單的Node.js雲端函式範例：

exports.helloWorld = (req, res) => {
  res.send('Hello, World!');
};

內容解密：

此範例展示了一個基本的HTTP觸發雲端函式。當接收到HTTP請求時，函式會回傳「Hello, World!」。開發者可根據需求擴充套件此函式，例如處理請求引數或與其他GCP服務互動。

隨著Serverless架構的持續演進，GCF將在更多應用場景中發揮重要作用。開發者應關注其最新功能和最佳實踐，以充分利用其強大的功能。同時，隨著容器技術和事件驅動模型的進一步發展，GCF的應用前景將更加廣闊。

無伺服器運算平台的比較與 Serverless Framework 詳解

無伺服器運算（Serverless Computing）已成為現代雲端運算的重要趨勢，各大雲端服務供應商紛紛推出各自的無伺服器平台。本文將探討四大主要無伺服器運算平台的特性與限制，並詳細介紹 Serverless Framework 在跨雲端佈署中的關鍵作用。

四大無伺服器運算平台特性分析

1. AWS Lambda 的運作限制

AWS Lambda 是目前最為廣泛使用的無伺服器運算服務，其主要特性包括：

  • 執行時間限制：單次執行最長不超過 15 分鐘
  • 資源限制：記憶體組態最高可達 10,288 MB
  • 冷啟動問題：首次呼叫或長時間未呼叫時會出現延遲

2. Azure Durable Functions 的優勢

Azure Durable Functions 是微軟 Azure 平台針對無伺服器運算的擴充套件方案，主要特點包括：

  • 支援長時間執行的任務：可超越單次執行的時間限制
  • 狀態管理機制：內建檢查點和狀態持久化功能
  • 工作流程協調：可複雜的工作流程進行協調和管理

3. Google Cloud Functions 的設計理念

Google Cloud Functions 作為 Google Cloud Platform 的無伺服器解決方案，具有以下特點：

  • 事件驅動架構：專為回應特定事件而設計
  • 語言支援：支援多種程式語言
  • 無伺服器整合：與 Google Cloud 生態系統緊密整合

4. IBM Cloud Functions 的技術背景

IBM Cloud Functions 根據 Apache OpenWhisk 技術構建，主要特點包括：

  • 開源技術支援：受益於 OpenWhisk 的開源生態
  • 事件驅動能力：可與 Cloudant 等資料函式庫系統整合
  • 靈活的觸發機制：支援多種事件來源的觸發

函式即服務（FaaS）的執行保障

在無伺服器架構中，函式的執行保障是至關重要的考量因素。主要挑戰包括：

  1. 錯誤處理機制：不同型別的函式需要不同的錯誤處理策略

    • 同步函式：通常最多執行一次，錯誤處理由呼叫端負責
    • 非同步函式：至少執行一次，需要考慮重複執行的情況

  2. 冪等性設計：為確保系統的穩定性，非同步函式的執行需要滿足冪等性要求

    • 狀態機設計：透過狀態機控制系統狀態的轉換
    • 冪等操作：確保重複執行相同的操作不會產生不同結果

程式碼範例：冪等性操作實作

def idempotent_update(counter_id, increment_value):
    """
    冪等性計數器更新操作
    
    :param counter_id: 計數器ID
    :param increment_value: 增量值
    :return: 更新後的計數值
    """
    # 使用資料函式庫的原子性更新操作確保冪等性
    return db.update_counter(counter_id, increment_value)

#### 內容解密：
此程式碼實作了一個冪等性的計數器更新操作。透過使用資料函式庫的原子性更新操作，確保了即使在重複呼叫的情況下，計數器的更新仍然是正確且一致的。這種設計避免了因函式重複執行而導致的資料不一致問題。

Serverless Framework 的架構優勢

Serverless Framework 作為一個開源的無伺服器應用開發框架，主要優勢體現在以下幾個方面：

  1. 跨雲端供應商支援：允許開發者編寫一次程式碼並佈署到多個雲端平台

    • 佈署靈活性：透過簡單修改設定檔即可切換雲端供應商
    • 供應商中立：避免廠商鎖定的問題

  2. 自動化開發流程：提供完整的開發、測試和佈署工具鏈

    • CLI 工具：簡化專案建立、建置和測試流程
    • 自動化佈署：支援一鍵佈署和版本回復

  3. 基礎設施即程式碼（IaC）：實作基礎設施組態的版本控制和管理

    • 可重複佈署：確保環境的一致性和可重現性
    • 自動化管理：簡化基礎設施的維護工作

Serverless Framework 的實際應用

# serverless.yml 設定檔範例
service:
  name: my-serverless-app

provider:
  name: aws
  runtime: python3.8

functions:
  hello:
    handler: handler.hello
    events:
      - http:
          path: hello
          method: get

#### 內容解密：
此設定檔定義了一個名為 `my-serverless-app` 的 Serverless 應用程式。透過設定 `provider` 欄位指定使用 AWS 作為雲端供應商，並定義了一個名為 `hello` 的函式。該函式將被觸發當有 HTTP GET 請求到 `/hello` 路徑時。透過這種設定方式，可以輕鬆地將應用程式佈署到不同的雲端供應商，只需修改 `provider` 欄位即可。

無伺服器運算的未來發展

隨著雲端運算技術的不斷進步，無伺服器架構正朝著以下幾個方向發展：

  1. 跨雲端整合：未來無伺服器架構將更加註重跨雲端的整合與協同工作能力
  2. 更強大的開發工具：開發框架和工具將持續進化，提供更完善的開發體驗
  3. 安全性增強：無伺服器架構的安全性將得到進一步加強，滿足更嚴格的合規要求

未來發展趨勢圖示

  graph LR
    A[當前無伺服器架構] -->|進化|> B[跨雲端整合]
    A -->|進化|> C[增強開發工具]
    A -->|進化|> D[安全性提升]
    B --> E[更強的供應商中立性]
    C --> F[更高效的開發流程]
    D --> G[更嚴格的安全合規]

#### **圖表翻譯：**
此圖表展示了無伺服器運算未來的三大主要發展方向：跨雲端整合、增強開發工具和安全性提升。這些進展將共同推動無伺服器技術的進一步成熟和廣泛應用。
玄貓

玄貓

技術愛好者，專注於分享程式開發、雲端技術與 AI 應用的心得體會。