提示與秘訣

本文說明設計、實作、測試及部署 Cloud Functions 的最佳做法。

注意： 本文中的多項建議都圍繞著所謂的冷啟動。函式是無狀態的，而且執行環境通常是從頭開始初始化，這就是所謂的冷啟動。由於完成冷啟動可能會耗費大量時間，最佳做法是避免不必要的冷啟動，並盡可能簡化冷啟動程序 (例如，避免不必要的依附元件)。

正確性

本節說明設計和實作 Cloud Functions 的一般最佳做法。

編寫冪等函式

即使多次呼叫函式，這些函式也應該產生相同結果。這樣一來，如果先前的叫用在程式碼中失敗，您就可以重試叫用。詳情請參閱「重試事件驅動函式」。

請勿啟動背景活動

背景活動是指在函式終止後發生的任何活動。函式傳回或以其他方式表示完成後，函式叫用就會結束，例如在 Node.js 事件驅動函式中呼叫 callback 引數。在安全終止後執行的任何程式碼都無法存取 CPU，因此不會有任何進展。

注意： 如果 Node.js 事件驅動函式傳回 Promise，Cloud Functions 會確保 Promise 在終止前完成。

此外，如果後續叫用在相同環境中執行，背景活動就會恢復，並干擾新的叫用。這可能會導致發生難以診斷的非預期行為和錯誤。在函式終止後存取網路通常會導致連線重設 (ECONNRESET 錯誤代碼)。

您通常可以在個別叫用作業的記錄中偵測到背景活動，方法是尋找在表示叫用作業已完成的文字行後面記錄的任何內容。背景活動有時可能會深埋在程式碼中，尤其是在存在回呼或計時器等非同步作業時。請審查您的程式碼，確認在您終止函式之前，所有非同步作業皆已完成。

一律刪除暫存檔案

暫存目錄中的本機磁碟儲存空間是一個記憶體內部檔案系統。您編寫的檔案會耗用用於函式的記憶體，而且有時會在叫用間持續存在。不明確刪除這些檔案最終可能會導致發生記憶體不足的錯誤，並造成後續冷啟動。

如要查看個別函式使用的記憶體，請在 Google Cloud 控制台的函式清單中選取該函式，然後選擇「Memory usage」圖表。

如果您需要存取長期儲存空間，建議使用 Cloud Run 磁碟區掛載點，搭配 Cloud Storage 或 NFS 磁碟區。

使用管道處理較大的檔案時，可以減少記憶體需求。舉例來說，您可以建立讀取串流、透過以串流為基礎的程序傳遞，然後直接將輸出串流寫入 Cloud Storage，藉此在 Cloud Storage 上處理檔案。

Functions Framework

為確保在各環境中安裝相同的依附元件，我們建議您在套件管理工具中加入 Functions Framework 程式庫，並將依附元件釘選至特定版本的 Functions Framework。

如要這麼做，請在相關的鎖定檔案中加入偏好的版本 (例如 Node.js 的 package-lock.json，或 Python 的 requirements.txt)。

如果未明確將 Functions Framework 列為依附元件，系統會在建構程序中自動使用最新可用版本。

工具

本節提供使用工具實作、測試及與 Cloud Functions 互動的規範。

本機開發

函式部署作業需要一些時間，因此通常在本機測試函式的程式碼會比較快。

Firebase 開發人員可以使用 Firebase CLI Cloud Functions Emulator。

使用 Sendgrid 傳送電子郵件

Cloud Functions 不允許通訊埠 25 的傳出連線，因此您無法與 SMTP 伺服器建立非安全連線。建議您使用第三方服務 (例如 SendGrid) 傳送電子郵件。您可以在 Google Compute Engine 的從執行個體傳送電子郵件教學課程中，找到其他傳送電子郵件的選項。

成效

本節說明最佳化效能的最佳做法。

避免低並行性

由於冷啟動成本高昂，因此在尖峰期間重複使用最近啟動的執行個體，是處理負載的絕佳最佳化方式。限制並行作業會限制現有執行個體的使用方式，因此會導致更多冷啟動。

增加並行處理能力有助於延遲每個執行個體的多個要求，讓您更輕鬆地處理負載尖峰。

注意： 隨著效率提升，所需的數量也會減少，個別函式執行個體可能會使用更多記憶體來保留要求，並需要更多 CPU 來處理這些要求。

謹慎使用依附元件

由於函式是無狀態的，因此執行環境通常是從頭開始初始化 (這期間就是所謂的「冷啟動」)。發生冷啟動時，會評估函式的全域背景資訊。

如果函式匯入模組，在冷啟動期間，這些模組的載入時間會增加叫用的延遲時間。您可以正確載入依附元件，而不載入函式不使用的依附元件，來減少這一延遲時間以及部署函式需要的時間。

使用全域變數在未來叫用中重複使用物件

系統無法保證函式的狀態會保留供日後叫用。不過，Cloud Functions 通常會回收先前叫用的執行環境。如果您在全域範圍中宣告變數，則其值可在後續叫用中重複使用，而無需重新計算。

這樣一來，您便可以快取在每次叫用函式時重新建立起來費用可能比較高的的物件。將這類物件從函式主體移至全域範圍可能會使效能大幅提升。下列範例只會為每個函式執行個體建立一個重型物件，並在到達指定執行個體的所有函式叫用中共用這個物件：

Node.js

console.log('Global scope');
const perInstance = heavyComputation();
const functions = require('firebase-functions');

exports.function = functions.https.onRequest((req, res) => {
  console.log('Function invocation');
  const perFunction = lightweightComputation();

  res.send(`Per instance: ${perInstance}, per function: ${perFunction}`);
});

Python

import time

from firebase_functions import https_fn

# Placeholder
def heavy_computation():
  return time.time()

# Placeholder
def light_computation():
  return time.time()

# Global (instance-wide) scope
# This computation runs at instance cold-start
instance_var = heavy_computation()

@https_fn.on_request()
def scope_demo(request):

  # Per-function scope
  # This computation runs every time this function is called
  function_var = light_computation()
  return https_fn.Response(f"Instance: {instance_var}; function: {function_var}")
  

這個 HTTP 函式會使用要求物件 (flask.Request)，並傳回回應文字，或任何可透過 make_response 轉換為 Response 物件的值集。

在全域範圍內快取網路連線、程式庫參照和 API 用戶端物件特別重要。如需範例，請參閱「最佳化網路」。

注意： 請勿在要求時間結束後執行背景工作。如果您需要使用耗用大量資源的背景工作結果，來初始化全域變數，請在函式執行期間執行該工作，並在傳送回應前儲存結果。

設定執行個體數量下限，減少冷啟動

根據預設，Cloud Functions 會依據傳入要求的數量，將執行個體數量調度。如要變更這項預設行為，請設定 Cloud Functions 必須保持待命以便處理要求的最低執行個體數量。設定執行個體數量下限可減少應用程式的冷啟動情形。如果應用程式對延遲時間較為敏感，建議您設定執行個體數量下限，並在載入時完成初始化作業。

如要進一步瞭解這些執行階段選項，請參閱「控制資源調度行為」。

關於冷啟動和初始化的注意事項

全域初始化作業會在載入期間執行。否則，第一個要求就需要完成初始化和載入模組，因此會造成更高的延遲。

不過，全域初始化也會對冷啟動造成影響。為盡量減少這項影響，請只初始化第一個要求所需的內容，以便將第一個要求的延遲時間降到最低。

如果您為延遲時間敏感的函式依照上述方式設定最低執行個體數，這一點就格外重要。在這種情況下，如果可以在載入時完成初始化作業，並快取實用的資料，就能確保第一個要求不必執行這項作業，且可以低延遲提供。

如果您在全域範圍內初始化變數，視語言而定，長時間初始化可能會導致兩種行為：- 對於某些語言和非同步程式庫組合，函式架構可以非同步執行並立即傳回，導致程式碼繼續在背景執行，這可能導致無法存取 CPU等問題。為避免這種情況，請按照下文所述，在模組初始化時進行阻斷。這也能確保系統在初始化完成前不會提供要求。- 另一方面，如果初始化是同步的，則長時間初始化會導致冷啟動時間更長，這可能會造成問題，尤其是在負載量激增期間，並且同時有低並行函式時。

注意： 如果您選擇使用較長的冷啟動時間和 min_instances，我們也建議您使用高並發性，以便更好地支援流量尖峰。

非同步 Node.js 程式庫預熱示例

Node.js 搭配 Firestore 就是非同步 Node.js 程式庫的範例。為了充分利用 min_instances，下列程式碼會在載入時完成載入和初始化作業，並阻斷模組載入作業。

使用 TLA，也就是說必須使用 ES6，並為 node.js 程式碼使用 .mjs 擴充功能，或將 type: module 新增至 package.json 檔案。

{
  "main": "main.js",
  "type": "module",
  "dependencies": {
    "@google-cloud/firestore": "^7.10.0",
    "@google-cloud/functions-framework": "^3.4.5"
  }
}

Node.js

import Firestore from '@google-cloud/firestore';
import * as functions from '@google-cloud/functions-framework';

const firestore = new Firestore({preferRest: true});

// Pre-warm firestore connection pool, and preload our global config
// document in cache. In order to ensure no other request comes in,
// block the module loading with a synchronous global request:
const config = await firestore.collection('collection').doc('config').get();

functions.http('fetch', (req, res) => {

// Do something with config and firestore client, which are now preloaded
// and will execute at lower latency.
});

全域初始化的範例

Node.js

const functions = require('firebase-functions');
let myCostlyVariable;

exports.function = functions.https.onRequest((req, res) => {
  doUsualWork();
  if(unlikelyCondition()){
      myCostlyVariable = myCostlyVariable || buildCostlyVariable();
  }
  res.status(200).send('OK');
});

Python

from firebase_functions import https_fn

# Always initialized (at cold-start)
non_lazy_global = file_wide_computation()

# Declared at cold-start, but only initialized if/when the function executes
lazy_global = None

@https_fn.on_request()
def lazy_globals(request):

  global lazy_global, non_lazy_global

  # This value is initialized only if (and when) the function is called
  if not lazy_global:
      lazy_global = function_specific_computation()

  return https_fn.Response(f"Lazy: {lazy_global}, non-lazy: {non_lazy_global}.")
  

這個 HTTP 函式會使用延遲初始化的全域變數。它會取得要求物件 (flask.Request)，並傳回回應文字，或任何可使用 make_response 轉換為 Response 物件的值集。

如果您在單一檔案中定義多個函式，且不同函式使用不同變數，這個方法尤為重要。除非您使用延遲初始化，否則會浪費已初始化但從未使用的變數資源。

注意： 在 Node.js 和 Python 中匯入依附元件時，也可以使用這項技巧，但代價是犧牲程式碼可讀性。

其他資源

如要進一步瞭解如何提升效能，請觀看「Google Cloud Performance Atlas」影片的 Cloud Functions 冷啟動時間。