管理函式

您可以使用 Firebase CLI 指令部署、刪除及修改函式，或在函式原始碼中設定執行階段選項。

部署函式

如要部署函式，請執行以下 Firebase CLI 指令：

firebase deploy --only functions

根據預設，Firebase CLI 會同時部署來源中的所有函式。如果專案包含超過 5 個函式，建議使用 --only 旗標搭配特定函式名稱，只部署編輯過的函式。這樣即可部署特定函式加快部署程序速度，並避免超額部署配額。例如：

firebase deploy --only functions:addMessage,functions:makeUppercase

部署大量函式時，您可能會超出標準配額，並收到 HTTP 429 或 500 錯誤訊息。如要解決這個問題，請以 10 個以下的群組為單位部署函式。

如需可用指令的完整清單，請參閱 Firebase CLI 參考資料。

根據預設，Firebase CLI 會在 functions/ 資料夾中查看原始碼。如有需要，您可以使用程式碼集或多組檔案整理函式。

刪除函式

您可以透過以下方式刪除先前部署的函式：

• 在 Firebase CLI 中明確使用 functions:delete
• 明確設定位於 Google Cloud 控制台。
• 以隱含的方式在部署前從來源中移除函式。

所有刪除作業都會提示您先確認，再將函式從實際工作環境中移除。

Firebase CLI 中的明確刪除函式支援多個引數與函式群組，並且可讓您指定在特定地區中執行的函式。此外，您也可以覆寫確認提示。

# Delete all functions that match the specified name in all regions.
firebase functions:delete myFunction

# Delete a specified function running in a specific region.
firebase functions:delete myFunction --region us-east-1

# Delete more than one function
firebase functions:delete myFunction myOtherFunction

# Delete a specified functions group.
firebase functions:delete groupA

# Bypass the confirmation prompt.
firebase functions:delete myFunction --force

隱含函式刪除作業之後，firebase deploy 會剖析來源，並從實際工作環境中移除已從檔案中移除的任何函式。

修改函式的名稱、區域或觸發條件

如果您要為處理實際工作環境流量的函式重新命名或變更區域或觸發條件，請按照本節所述的步驟操作，避免在修改期間遺失事件。在執行下列步驟之前，請先確認您的函式是冪等，因為新版和舊版函式會在變更期間同時執行。

重新命名函式

如要重新命名函式，請在來源中為函式建立新的重新命名版本，然後執行兩個不同的部署指令。第一個指令會部署新命名的函式，第二個指令則會移除先前部署的版本。例如，如果您有名為 webhook 的 Node.js 函式，並您想要變更為 webhookNew，請按照以下方式修改程式碼：

// before
const functions = require('firebase-functions');

exports.webhook = functions.https.onRequest((req, res) => {
    res.send("Hello");
});

// after
const functions = require('firebase-functions');

exports.webhookNew = functions.https.onRequest((req, res) => {
    res.send("Hello");
});

然後執行下列指令，部署新函式：

# Deploy new function called webhookNew
firebase deploy --only functions:webhookNew

# Wait until deployment is done; now both webhookNew and webhook are running

# Delete webhook
firebase functions:delete webhook

變更函式的區域或區域

如果您要為處理實際工作環境流量的函式變更指定地區，可以依序執行以下步驟，避免事件遺失：

1. 重新命名函式，並視需要變更其區域或區域。
2. 部署重新命名的函式，讓兩個區域都暫時執行相同的程式碼。
3. 刪除前一個函式。

舉例來說，如果您有一個名為 webhook 的函式，且該函式目前位於 us-central1 的預設函式區域中，且您想將該函式遷移至 asia-northeast1，就必須先修改原始碼來重新命名函式，並且修改區域。

// before
const functions = require('firebase-functions');

exports.webhook = functions
    .https.onRequest((req, res) => {
            res.send("Hello");
    });

// after
const functions = require('firebase-functions');

exports.webhookAsia = functions
    .region('asia-northeast1')
    .https.onRequest((req, res) => {
            res.send("Hello");
    });

接著執行下列指令進行部署：

firebase deploy --only functions:webhookAsia

現在有兩個相同的函式正在執行：webhook 在 us-central1 中執行，而 webhookAsia 是在 asia-northeast1 中執行。

接著刪除 webhook：

firebase functions:delete webhook

現在只有一個函式 - webhookAsia，其在 asia-northeast1 中執行。

變更函式的觸發條件類型

隨著時間開發 Cloud Functions for Firebase 部署時，您可能需要基於各種原因變更函式的觸發條件類型。例如，您可能會想要從某個類型的 Firebase 即時資料庫或 Cloud Firestore 事件變更為另一種類型。

您無法僅變更原始碼並執行 firebase deploy 來變更函式的事件類型。為了避免發生錯誤，請按照以下程序變更函式的觸發條件類型：

1. 修改原始碼，加入包含所需觸發條件類型的新函式。
2. 部署函式，可同時執行新舊函式。
3. 使用 Firebase CLI 從實際工作環境中明確刪除舊函式。

舉例來說，如果您有一個名為 objectChanged 的 Node.js 函式，其中包含舊版 onChange 事件類型，且您想將其變更為 onFinalize，請先重新命名函式，並將其編輯為 onFinalize 事件類型。

// before
const functions = require('firebase-functions');

exports.objectChanged = functions.storage.object().onChange((object) => {
    return console.log('File name is: ', object.name);
});

// after
const functions = require('firebase-functions');

exports.objectFinalized = functions.storage.object().onFinalize((object) => {
    return console.log('File name is: ', object.name);
});

接著執行下列指令，先建立新函式，再刪除舊函式：

# Create new function objectFinalized
firebase deploy --only functions:objectFinalized

# Wait until deployment is done; now both objectChanged and objectFinalized are running

# Delete objectChanged
firebase functions:delete objectChanged

設定執行階段選項

Cloud Functions for Firebase 可讓您選取執行階段選項，例如 Node.js 執行階段版本、每個函式逾時、記憶體分配，以及函式的最低/上限。

最佳做法是針對函式程式碼內的設定物件設定這些選項 (Node.js 版本除外)。這個 RuntimeOptions 物件是函式執行階段選項的可靠來源，並會覆寫透過任何其他方法設定的選項 (例如透過 Google Cloud 控制台或 gcloud CLI)。

如果您的開發工作流程涉及透過 Google Cloud 控制台或 gcloud CLI 手動設定執行階段選項，且您「不想」在每次部署時覆寫這些值，請將 preserveExternalChanges 選項設為 true。這個選項設為 true 之後，Firebase 會將程式碼中設定的執行階段選項與目前部署的函式版本，合併為下列優先順序：

1. 選項是在函式程式碼中設定：覆寫外部變更。
2. 在函式程式碼中，選項設為 RESET_VALUE：以預設值覆寫外部變更。
3. 選項未在函式程式碼中設定，但已在目前部署的函式中設定：使用已部署函式中指定的選項。

在大多數情況下，我們不建議使用 preserveExternalChanges: true 選項，因為您的程式碼將不再是函式的執行階段選項的完整資料來源。如果使用這個程式庫，請查看 Google Cloud 控制台或使用 gcloud CLI 查看函式的完整設定。

設定 Node.js 版本

Cloud Functions 適用的 Firebase SDK 可讓您選取 Node.js 執行階段。您可以選擇在專案內僅執行專案中的所有函式，其對應以下任一受支援的 Node.js 版本所對應的執行階段環境：

• Node.js 20 (預先發布版)
• Node.js 18
• Node.js 16
• Node.js 14

如要設定 Node.js 版本：

您可以在初始化期間於 functions/ 目錄中建立的 package.json 檔案，在 engines 欄位中設定版本。舉例來說，如果只要使用第 18 版，請在 package.json 中編輯這一行：

  "engines": {"node": "18"}

如果您使用的是 Yarn 套件管理員，或者對 engines 欄位有其他特定需求，可以改為在 firebase.json 中設定 Cloud Functions 適用的 Firebase SDK 執行階段：

  {
    "functions": {
      "runtime": "nodejs18" // or nodejs14, nodejs16 or nodejs20
    }
  }

CLI 會使用 firebase.json 中設定的值，取代您在 package.json 中單獨設定的任何值或範圍。

升級 Node.js 執行階段

如要升級 Node.js 執行階段：

1. 請確認您的專案採用 Blaze 定價方案。
2. 請確認使用的是 Firebase CLI 11.18.0 以上版本。
3. 在初始化期間，在 functions/ 目錄中建立的 package.json 檔案變更 engines 值。例如，如果您要從 16 版升級至 18 版，項目應如下所示："engines": {"node": "18"}
4. 視需要使用 Firebase 本機模擬器套件測試變更。
5. 重新部署所有函式。

控制資源調度行為

根據預設，Cloud Functions for Firebase 會根據傳入要求數量調整執行中執行個體的數量，且在減少流量的情況下，可能縮減為零個執行個體。不過，如果應用程式需要縮短延遲時間，而您希望限製冷啟動次數，則可變更這項預設行為，方法是指定要保留暖機狀態、準備好處理要求的最低容器執行個體數量。

同樣地，您可以設定上限來限制回應傳入要求的執行個體資源調度。如要控管成本，或限制後端服務 (例如資料庫) 的連線數量，請使用這項設定。

減少冷啟動次數

如要在原始碼中為函式設定執行個體數量下限，請使用 runWith 方法。這個方法接受符合 RuntimeOptions 介面的 JSON 物件，該物件會定義 minInstances 的值。例如，這個函式至少會設定 5 個以上的執行個體來保持暖機：

exports.getAutocompleteResponse = functions
    .runWith({
      // Keep 5 instances warm for this latency-critical function
      minInstances: 5,
    })
    .https.onCall((data, context) => {
      // Autocomplete a user's search term
    });
index.js

為 minInstances 設定值時，請考量以下幾點：

• 如果 Cloud Functions for Firebase 將應用程式調度到高於 minInstances 的設定值，就會對超過該門檻的每個執行個體發生冷啟動的情況。
• 冷啟動對流量激增的應用程式最嚴重的影響。如果應用程式的流量遽增，且您的 minInstances 值夠高，足以在每次流量增加時減少冷啟動，您就可以看到延遲時間大幅縮短。對於流量穩定不變的應用程式，冷啟動不太可能嚴重影響效能。

• 對於實際工作環境而言，設定最低執行個體是合理的做法，但通常應避免在測試環境中使用。如要將測試專案中的資源調度降至零，但仍減少實際工作環境專案中的冷啟動，您可以根據 FIREBASE_CONFIG 環境變數設定 minInstances：

  // Get Firebase project id from `FIREBASE_CONFIG` environment variable
  const envProjectId = JSON.parse(process.env.FIREBASE_CONFIG).projectId;
  
  exports.renderProfilePage = functions
      .runWith({
        // Keep 5 instances warm for this latency-critical function
        // in production only. Default to 0 for test projects.
        minInstances: envProjectId === "my-production-project" ? 5 : 0,
      })
      .https.onRequest((req, res) => {
        // render some html
      });
  index.js
  

限制函式的執行個體數量上限

如要在函式原始碼中設定執行個體數量上限，請使用 runWith 方法。這個方法接受符合 RuntimeOptions 介面的 JSON 物件，該物件會定義 maxInstances 的值。舉例來說，這個函式會設定 100 個執行個體的限制，以免假的舊版資料庫發生過多負擔：

exports.mirrorOrdersToLegacyDatabase = functions
    .runWith({
      // Legacy database only supports 100 simultaneous connections
      maxInstances: 100,
    })
    .firestore.document("orders/{orderId}")
    .onWrite((change, context) => {
      // Connect to legacy database
    });
index.js

如果 HTTP 函式向上擴充至 maxInstances 上限，系統會將新的要求排入佇列 30 秒，如果屆時沒有任何執行個體可用，回應代碼就會遭拒並顯示 429 Too Many Requests。

如要進一步瞭解使用執行個體數量上限設定的最佳做法，請參閱使用 maxInstances 的最佳做法。

設定逾時和記憶體配置

在某些情況下，您的函式對於長時間逾時值或大量記憶體配置可能有特殊需求。您可以在 Google Cloud 控制台或函式原始碼 (僅限 Firebase) 中設定這些值。

如要在函式原始碼中設定記憶體配置和逾時，請使用 Firebase SDK for Cloud Functions 2.0.0 中引入的 runWith 參數。此執行階段選項接受與 RuntimeOptions 介面相符的 JSON 物件，該物件會定義 timeoutSeconds 和 memory 的值。舉例來說，這個儲存空間函式使用 1 GB 的記憶體，並在 300 秒後逾時：

exports.convertLargeFile = functions
    .runWith({
      // Ensure the function has enough memory and time
      // to process large files
      timeoutSeconds: 300,
      memory: "1GB",
    })
    .storage.object()
    .onFinalize((object) => {
      // Do some complicated things that take a lot of memory and time
    });
index.js

timeoutSeconds 的最大值是 540 或 9 分鐘。授予函式的記憶體容量會與分配至函式的 CPU 相對應，如以下 memory 的有效值清單所述：

• 128MB - 200MHz
• 256MB - 400MHz
• 512MB - 800MHz
• 1GB：1.4 GHz
• 2GB：2.4 GHz
• 4GB：4.8 GHz
• 8GB：4.8 GHz

如何在 Google Cloud 控制台中設定記憶體配置和逾時：

1. 在 Google Cloud 控制台的左選單中選取「Cloud Functions」。
2. 在函式清單中按一下函式名稱以選取函式。
3. 按一下頂端選單中的「編輯」圖示。
4. 從標示為「Memory memory」(分配的記憶體) 下拉式選單中，選取記憶體配置。
5. 按一下「更多」即可顯示進階選項，然後在「逾時」文字方塊中輸入秒數。
6. 按一下「儲存」以更新函式。