管理功能


您可以使用 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/ 資料夾中尋找 Cloud Build 觸發條件 會在您變更原始碼時自動啟動建構作業如有需要,您可以整理函式 或多組檔案之中

刪除函式

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

所有刪除作業 從實際工作環境移除函式前,會提示您進行確認。

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 會剖析來源, 會從檔案中移除所有函式。

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

如果您要針對適用於 請按照本節所述步驟處理,以免遺失 事件。執行下列步驟前,請先確認 函式為「冪等」,因為 新版和舊版函式都會在 變更的延遲時間

重新命名函式

如要重新命名函式,請在來源中新建該函式的重新命名版本 然後執行兩個不同的部署指令第一個指令會部署 新命名的函式,第二個指令則移除先前部署的 版本。舉例來說,如要透過 HTTP 觸發的 Webhook 請重新命名並修改程式碼,如下所示:

Node.js

// before
const {onRequest}  = require('firebase-functions/v2/https');

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

// after
const {onRequest}  = require('firebase-functions/v2/https');

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

Python

# before
from firebase_functions import https_fn

@https_fn.on_request()
def webhook(req: https_fn.Request) -> https_fn.Response:
    return https_fn.Response("Hello world!")

# after
from firebase_functions import https_fn

@https_fn.on_request()
def webhook_new(req: https_fn.Request) -> https_fn.Response:
    return https_fn.Response("Hello world!")

接著執行下列指令,部署新函式:

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

# Wait until deployment is done; now both functions are running

# Delete webhook
firebase functions:delete webhook

變更函式的區域或區域

如果要變更的指定區域 處理正式環境流量的函數,如要避免事件遺失, 執行下列步驟:

  1. 重新命名函式,並視需要變更區域或區域。
  2. 部署重新命名的函式,以便在兩組區域中暫時執行相同的程式碼。
  3. 刪除前一個函式。

舉例來說,如果您具有 Cloud Firestore 觸發的函式 目前位於 us-central1 的預設函式區域,想遷移至 asia-northeast1,您必須先修改原始碼,才能將 並修改區域。

Node.js

// before
exports.firestoreTrigger = onDocumentCreated(
  "my-collection/{docId}",
  (event) => {},
);

// after
exports.firestoreTriggerAsia = onDocumentCreated(
  {
    document: "my-collection/{docId}",
    region: "asia-northeast1",
  },
  (event) => {},
);

更新過的程式碼應指定正確的事件篩選器 (在本例中為 document) 和地區。詳情請見 Cloud Functions 位置

Python

# Before
@firestore_fn.on_document_created("my-collection/{docId}")
def firestore_trigger(event):
    pass

# After
@firestore_fn.on_document_created("my-collection/{docId}",
                                  region="asia-northeast1")
def firestore_trigger_asia(event):
    pass

接著執行下列指令來部署:

firebase deploy --only functions:firestoreTriggerAsia

現在有兩個相同的函式正在執行:firestoreTrigger 會在 「us-central1」和「firestoreTriggerAsia」正在 asia-northeast1 中執行。

然後刪除 firestoreTrigger

firebase functions:delete firestoreTrigger

現在只有一個函式 firestoreTriggerAsia,其執行位置為 asia-northeast1

變更函式的觸發條件類型

隨著您逐步開發 Cloud Functions for Firebase 部署作業,您可以 因為各種原因而需要變更函式的觸發條件類型。例如: 建議變更一種類型的Firebase Realtime DatabaseCloud Firestore 事件變更為另一種類型。

您無法只透過變更 並執行 firebase deploy。為避免發生錯誤 透過以下程序變更函式的觸發條件類型:

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

舉例來說,假設您的函式是在物件 但之後已啟用 物件版本管理 但想改為訂閱這個封存活動時,請先重新命名 函式,編輯函式,使其使用新的觸發條件類型。

Node.js

// before
const {onObjectDeleted} = require("firebase-functions/v2/storage");

exports.objectDeleted = onObjectDeleted((event) => {
    // ...
});

// after
const {onObjectArchived} = require("firebase-functions/v2/storage");

exports.objectArchived = onObjectArchived((event) => {
    // ...
});

Python

# before
from firebase_functions import storage_fn

@storage_fn.on_object_deleted()
def object_deleted(event):
  # ...

# after 
from firebase_functions import storage_fn

@storage_fn.on_object_archived()
def object_archived(event):
  # ...

接著執行下列指令,先建立新函式,然後再刪除舊函式:

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

# Wait until deployment is done; now both objectDeleted and objectArchived are running

# Delete objectDeleted
firebase functions:delete objectDeleted

設定執行階段選項

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 查看函式的完整設定。

設定 Node.js 版本

Cloud Functions 適用的 Firebase SDK 允許選取 Node.js 執行階段。 您可以選擇只在執行階段執行專案中的所有函式 環境:

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

Node.js 14 和 16 版 並將於 2025 年初停用。部署作業 無法使用這些已淘汰的版本

如要設定 Node.js 版本:

您可以在 package.jsonengines 欄位中設定版本 該檔案是在初始化期間建立的 functions/ 目錄中。 舉例來說 18 版,請在 package.json 中編輯這一行:

  "engines": {"node": "20"}

如果您使用 Yarn 套件管理工具,或有其他 engines 欄位,您可以在以下位置設定 Firebase SDK 的 Cloud Functions 執行階段: firebase.json

  {
    "functions": {
      "runtime": "nodejs18" // or nodejs20
    }
  }

CLI 使用 firebase.json 中設定的值,而非任何值或 您在 package.json 中單獨設定的範圍。

升級 Node.js 執行階段

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

  1. 請確認您的專案位於 Blaze 定價方案
  2. 請務必使用 Firebase CLI v11.18.0 以上版本。
  3. 變更先前建立的 package.json 檔案內的 engines 值。 functions/ 目錄, 舉例來說,如果您從第 18 版升級至第 20 版,則輸入的項目 看起來應該像這樣:"engines": {"node": "20"}
  4. 視需要使用 Firebase Local Emulator Suite
  5. 重新部署所有函式。

設定 Python 版本

Cloud Functions 12.0.0 以上版本的 Firebase SDK 允許選擇 Python 執行階段。在 firebase.json 中設定執行階段版本,如下所示:

  {
    "functions": {
      "runtime": "python310" // or python311
    }
  }

控管資源調度行為

根據預設,Cloud Functions for Firebase 會調整運作中的執行個體數量 依據傳入要求的數量,甚至可能將資源縮減至零 執行個體會發生在流量減少的時候不過,如果您的應用程式需要 如要限製冷啟動的次數,您可以變更 您可以指定容器執行個體數量下限 保持暖機狀態,隨時可供處理要求。

同樣地,您可以設定上限,限制 回應傳入要求。使用這項設定來控管費用 或限制後端服務的連線數量,例如 資料庫

搭配使用這些設定與個別執行個體的並行設定 (新 第 2 代),您可以控制和調整函式的縮放行為。 應用程式與函式的性質將決定 成本效益一致,爭取最佳成效

對於某些流量偏低的應用程式來說,沒有多並行機制的 CPU 選項較少: 最佳。其他對於冷啟動是重大問題的人,將較高值設為 並行和最低執行個體數量 代表一組執行個體 ,以處理巨大的尖峰流量。

對於流量很少的小型應用程式,請將最高 執行個體若具備高並行性,表示應用程式可以處理大量流量 而不會產生高額費用不過請注意 執行個體設定過低,達到上限時可能會捨棄要求。

允許並行要求

Cloud Functions for Firebase (第 1 代) 中,每個執行個體一次可以處理一個要求,因此 資源調度行為僅設有執行個體下限和上限設定。 除了控管執行個體數量之外,在 Cloud Functions for Firebase (第 2 代) 中, 限制每個執行個體可以同時處理的要求數量 concurrency 選項。並行的預設值為 80,但您可以 請設為 1 到 1000 之間的任何整數。

並行設定較高的函式可能會吸收尖峰流量 每個執行個體可能都有一些餘餘空間,所以才會啟動「冷啟動」。如果執行個體 設定以處理最多 50 個並行要求,但目前僅限處理 25,不必執行新的執行緒,即可處理額外 25 項額外要求 複製到冷啟動相反地,並行設定僅設為 1 要求量高峰可能會導致 25 次冷啟動。

這個簡單的情境展現了 並行。事實上,資源調度行為是為了提升效率並減少 並行的冷啟動比較複雜並行類型: Cloud Functions for Firebase 第 2 代採用 Cloud Run 技術, Cloud Run的規則 自動調度容器執行個體資源

Cloud Functions for Firebase 中實驗更高的並行設定 (第 2 代)),請留意以下事項:

  • 較高的並行設定可能需要較高的 CPU 和 RAM 資源,才能達到最佳狀態 效能才會降低執行大量的函式 或是圖片或影片處理程序等 1, 000 個並行要求,即使 CPU 和 RAM 設定最大化。
  • 由於 Cloud Functions for Firebase (第 2 代) 採用 Cloud Run 技術,因此你可以: 也請參閱 Google Cloud 相關指南 最佳化並行
  • 務必先在測試環境中完整測試多並行功能,再進行下列作業: 在實際工作環境中切換至多並行。

將執行個體數量下限維持在暖機狀態

您可以在原始碼中設定函式的執行個體數量下限。 例如,這個函式會將執行個體數量至少設為 5 個 如何保暖:

Node.js

const { onCall } = require("firebase-functions/v2/https");

exports.getAutocompleteResponse = onCall(
  {
    // Keep 5 instances warm for this latency-critical function
    minInstances: 5,
  },
  (event) => {
    // Autocomplete users search term
  }
);

Python

@https_fn.on_call(min_instances=5)
def get_autocomplete_response(event: https_fn.CallableRequest) -> https_fn.Response:

設定執行個體下限時,請注意下列事項:

  • 如果 Cloud Functions for Firebase 會將應用程式縮放至您的設定上方, 在每個執行個體超過該門檻時,我們就會啟動冷啟動
  • 對於流量暴增的應用程式而言,冷啟動的效果最為嚴重。如果您的 您將應用程式設為足夠的流量 而您設定了足夠的價值 每當流量增加時,冷啟動都會降低 縮短延遲時間如果應用程式的流量穩定,冷啟動就不可能 嚴重影響效能
  • 在實際工作環境中設定最低執行個體是合理的做法,但 通常應避免在測試環境中使用。如要在 仍能減少正式環境專案中的冷啟動次數 可以在參數化設定中設置執行個體下限值:

    Node.js

    const functions = require('firebase-functions/v1');
    const { defineInt, defineString } = require('firebase-functions/params');
    
    // Define some parameters
    const minInstancesConfig = defineInt('HELLO_WORLD_MININSTANCES');
    const welcomeMessage = defineString('WELCOME_MESSAGE');
    
    // To use configured parameters inside the config for a function, provide them 
    // directly. To use them at runtime, call .value() on them.
    export const helloWorld = functions.runWith({ minInstances: minInstancesConfig}).https.onRequest(
      (req, res) => {
        res.send(`${welcomeMessage.value()}! I am a function.`);
      }
    );
    

    Python

    MIN_INSTANCES = params.IntParam("HELLO_WORLD_MININSTANCES")
    WELCOME_MESSAGE = params.StringParam("WELCOME_MESSAGE")
    
    @https_fn.on_request(min_instances=MIN_INSTANCES.value())
    def get_autocomplete_response(event: https_fn.Request) -> https_fn.Response:
        return https_fn.Response(f"{WELCOME_MESSAGE.value()} I'm a function.")
    

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

您可以在函式原始碼中設定執行個體上限的值。 例如,這個函式會將限制設為 100 個執行個體 克服假想的舊資料庫:

Node.js

const { onMessagePublished } = require("firebase-functions/v2/pubsub");

exports.mirrorevents = onMessagePublished(
  { topic: "topic-name", maxInstances: 100 },
  (event) => {
    // Connect to legacy database
  }
);

Python

@pubsub_fn.on_message_published(topic="topic-name", max_instances=100)
def mirrorevents(event: pubsub_fn.CloudEvent):
#  Connect to legacy database

如果 HTTP 函式擴充為執行個體數量上限, 排入佇列 30 秒,然後遭到拒絕,回應代碼為 如果屆時沒有任何執行個體,則為 429 Too Many Requests

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

設定逾時和記憶體分配

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

如要在函式原始碼中設定記憶體分配和逾時,請使用 記憶體和逾時秒數的全域選項 自訂執行函式的虛擬機器。 舉例來說,這個 Cloud Storage 函式會使用 1 GiB 的記憶體和時間 而不是在 300 秒過後

Node.js

exports.convertLargeFile = onObjectFinalized({
  timeoutSeconds: 300,
  memory: "1GiB",
}, (event) => {
  // Do some complicated things that take a lot of memory and time
});

Python

@storage_fn.on_object_finalized(timeout_sec=300, memory=options.MemoryOption.GB_1)
def convert_large_file(event: storage_fn.CloudEvent):
# Do some complicated things that take a lot of memory and time.

逾時秒數的最大值為 540 或 9 分鐘。

如要在 Google Cloud 控制台中設定記憶體分配和逾時功能,請按照下列步驟操作:

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

覆寫 CPU 預設值

最多可分配 2 GB 的記憶體,Cloud Functions for Firebase (第 2 代) 中的每個函式 設為 1 個 CPU,再增加為 2 個 CPU,可支援 4 和 8 GB。請注意, 與第 1 代的預設行為有很大的差異 因此會稍微增加低記憶體函式的成本 資料表:

分配的 RAM 版本 1 預設 CPU (小規模) 版本 2 預設 CPU 每毫秒價格調漲
128MB 1 月 12 日 1 分 10.5 倍
256MB 1 月 6 日 1 分 5.3 倍
512MB 1 月 3 日 1 分 2.7 倍
1GB 7 月 12 日 1 分 1.6 倍
2GB 1 分 1 分 1 倍
4GB 2 分 2 分 1 倍
8GB 2 分 2 分 1 倍
16 GB 不適用 4 分 不適用

如果想將第 1 代功能用於第 2 代函式,請將第 1 代預設值設為預設值 做為全域選項

Node.js

// Turn off Firebase defaults
setGlobalOptions({ cpu: 'gcf_gen1' });

Python

# Use 1st gen behavior
set_global_options(cpu="gcf_gen1")

針對會耗用大量 CPU 的函式,第 2 代可彈性設定額外的 也就是 CPU您可以針對每個函式強化 CPU,如下所示:

Node.js

// Boost CPU in a function:
export const analyzeImage = onObjectFinalized({ cpu: 2 }, (event) => {
  // computer vision goes here
});

Python

# Boost CPU in a function:
@storage_fn.on_object_finalized(cpu=2)
def analyze_image(event: storage_fn.CloudEvent):
# computer vision goes here