Cloud Frontier

導言

Serverless 運算已成為雲端架構中的熱門詞彙。然而如同任何工具，它既有最佳適用情境，也有潛在風險。在建置與維護多個 serverless 應用程式後，我已學會它在哪些情境下表現出色，以及哪些情境會帶來困擾。本文將分享這些經驗。

Serverless 的優勢情境

1. 事件驅動的工作負載

當程式碼需要回應事件（例如檔案上傳、資料庫變更、HTTP 請求）時，Serverless 表現出色。按執行次數計費的模式意味著您不必為閒置時間付費。

// AWS Lambda handler for image resizing
exports.handler = async (event) => {
  const bucket = event.Records[0].s3.bucket.name;
  const key = event.Records[0].s3.object.key;
  // resize and save
  return { statusCode: 200 };
};

Enter fullscreen mode Exit fullscreen mode

2. 流量變化或不可預測

若您的應用程式偶爾會有流量高峰（例如行銷活動），Serverless 可即時自動擴展，無需預先規劃峰值負載。

3. 快速原型與 MVP 開發

您可以在數分鐘內部署完整的 API，而無需管理伺服器。這能加速回饋迴圈。

4. 微服務與整合程式碼

Serverless 函式非常適合用於小型、單一目的的服務，用來連接其他服務（例如處理 webhook、資料轉換）。

Serverless 的限制情境

1. 長時間執行的處理程序

大多數供應商都有執行時間上限（例如 AWS Lambda 為 15 分鐘）。批次處理或影片轉碼可能會觸及此限制。

# This will timeout if processing takes > 15 minutes
def handler(event, context):
    process_large_file(event['file'])
    return {'done': True}

Enter fullscreen mode Exit fullscreen mode

2. 冷啟動

一段時間未使用後，首次請求可能會有數秒的延遲。這對延遲敏感的應用程式（如同步 API）會造成影響。

3. 有狀態的應用程式

Serverless 在設計上為無狀態。若您需要持久連線（如 WebSocket）或本地狀態，就必須使用額外的服務（如 Redis 或 DynamoDB），增加複雜度。

4. 高且穩定的負載

若您的服務全天候持續運行且流量穩定，預先配置的伺服器通常更具成本效益。Serverless 按次計費的成本可能高於固定月租伺服器。

5. 複雜的除錯與測試

本地模擬工具（如 SAM、serverless-offline）雖然有幫助，但無法完全重現生產環境。除錯跨函式的分散式追蹤也可能相當困難。

實務建議

適合使用 Serverless 的情境：

  • 您的工作負載為事件驅動或間歇性
  • 您希望減少營運負擔
  • 您需要從零開始快速擴展

不建議使用 Serverless 的情境：

  • 您有長時間執行或有狀態的處理程序
  • 您需要一致的低延遲（冷啟動會造成影響）
  • 您的流量穩定且量大

結論

Serverless 是一種強大的架構模式，但並非萬靈丹。在採用前，請務必評估您工作負載的特性。適當使用時，它能降低複雜度與成本；若誤用，則可能帶來新的問題。請謹慎選擇。