您可以使用 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
會剖析來源,並從正式版中移除已從檔案中移除的任何函式。
修改函式的名稱、區域或觸發條件
如果您要為處理正式版流量的函式重新命名或變更區域或觸發條件,請按照本節中的步驟操作,避免在修改期間遺失事件。在您按照這些步驟操作之前,請先確認函式是否冪等,因為在變更期間,函式的新舊版本都會同時執行。
重新命名函式
如要重新命名函式,請在來源中建立新版本的函式並重新命名,然後執行兩個個別的部署指令。第一個指令會部署新命名的函式,第二個指令則會移除先前部署的版本。舉例來說,如果您有要重新命名的 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
變更函式的區域
如果您要為處理實際工作環境流量的函式變更指定地區,可以依序執行下列步驟,避免事件遺失:
- 重新命名函式,並視需要變更其區域。
- 部署重新命名的函式,這會導致在兩組區域中暫時執行相同的程式碼。
- 刪除前一個函式。
舉例來說,如果您有一個由 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 Database 或 Cloud Firestore 事件類型變更為另一種類型。
您無法僅透過變更原始碼並執行 firebase deploy
來變更函式的事件類型。為避免發生錯誤,請按照下列程序變更函式的觸發事件類型:
- 修改原始碼,加入含有所需觸發類型的新函式。
- 部署函式,這會導致暫時同時執行舊函式和新函式。
- 使用 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 會將程式碼中設定的執行階段選項,與目前部署的函式版本設定合併,並以以下優先順序進行:
- 在函式程式碼中設定選項:覆寫外部變更。
- 函式程式碼中的選項設為
RESET_VALUE
:以預設值覆寫外部變更。 - 選項未在函式程式碼中設定,而是在目前已部署的函式中設定:請使用已部署函式中指定的選項。
在大多數情況下,不建議使用 preserveExternalChanges: true
選項,因為您的程式碼將不再是函式執行階段選項的完整來源。如果發生這種情況,請檢查 Google Cloud 控制台或使用 gcloud CLI,檢視函式的完整設定。
設定 Node.js 版本
Cloud Functions 適用的 Firebase SDK 可讓您選取 Node.js 執行階段。您可以選擇只在與下列任一受支援 Node.js 版本的執行階段環境中,執行專案中的所有函式:
- Node.js 22 (預先發布版)
- Node.js 20
- Node.js 18
Node.js 14 和 16 版已淘汰,並將於 2025 年初停用。已停用的版本已停用部署功能。
如要設定 Node.js 版本,請按照下列步驟操作:
您可以在初始化期間在 functions/
目錄中建立的 package.json
檔案中,於 engines
欄位設定版本。例如,如要只使用 18 版,請在 package.json
中編輯這行:
"engines": {"node": "20"}
如果您使用 Yarn 套件管理員,或對 engines
欄位有其他特定需求,可以改為在 firebase.json
中為 Cloud Functions 設定 Firebase SDK 的執行階段:
{
"functions": {
"runtime": "nodejs18" // or nodejs20
}
}
CLI 會優先使用 firebase.json
中設定的值,而非您在 package.json
中個別設定的任何值或範圍。
升級 Node.js 執行階段
如要升級 Node.js 執行階段:
- 請確認您的專案採用 Blaze 定價方案。
- 請確認您使用的是 Firebase CLI 11.18.0 以上版本。
- 針對在初始化期間於
functions/
目錄中建立的package.json
檔案,變更engines
值。舉例來說,如果您要從 18 版升級至 20 版,項目應如下所示:"engines": {"node": "20"}
- 您可以選擇使用 Firebase Local Emulator Suite 測試變更。
- 重新部署所有函式。
設定 Python 版本
Firebase 適用於 Cloud Functions 的 SDK 12.0.0 以上版本可讓您選取 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 才能達到最佳效能,直到達到實際限制為止。舉例來說,如果函式需要進行大量圖片或影片處理作業,即使 CPU 和 RAM 設定已最大化,可能仍缺乏資源來處理 1,000 項並行要求。
- 由於 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 user’s 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 主控台中設定記憶體分配和逾時時間,請按照下列步驟操作:
- 在 Google Cloud 控制台中,選取左側選單中的「Cloud Functions for Firebase」。
- 在函式清單中按一下函式名稱,即可選取函式。
- 按一下頂端選單中的「編輯」圖示。
- 從「Memory allocated」下拉式選單中選取記憶體配置。
- 按一下「More」顯示進階選項,然後在「Timeout」文字方塊中輸入秒數。
- 按一下「Save」(儲存) 以更新函式。
覆寫 CPU 預設值
分配最多 2 GB 的記憶體。Cloud Functions for Firebase (第 2 代) 中的每個函式預設使用一個 CPU,接著調高為 2 個 CPU (4 和 8 GB)。請注意,這與第 1 代預設行為有顯著差異,可能會導致低記憶體函式的成本略高,如以下表格所示:
已分配的 RAM | 版本 1 預設 CPU (小數) | 版本 2 的預設 CPU | 每毫秒的價格調漲幅度 |
---|---|---|---|
128 MB | 1/12 | 1 | 10.5x |
256 MB | 1/6 | 1 | 5.3x |
512 MB | 1/3 | 1 | 2.7 倍 |
1 GB | 7/12 | 1 種 | 1.6 倍 |
2 GB | 1 種 | 1 | 1x |
4GB | 2 | 2 | 1x |
8 GB | 2 | 2 | 1x |
16 GB | 不適用 | 4 | 不適用 |
如果您偏好為第 2 代函式使用第 1 代行為,請將第 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