Cloud Functions 具有「地區性」,這表示執行函式的基礎架構位於特定地區,且由 Google 代管,可為該地區內的所有區域提供備援功能。
選擇執行函式的地區時,請將延遲時間和可用性列為主要考量因素。一般來說,您可以選擇距離使用者最近的地區,但也應該考慮應用程式使用的其他產品和服務所在的位置。如果跨多個地區使用服務,可能會影響應用程式的延遲時間和定價。
根據預設,函式會在 us-central1
區域中執行。請注意,這可能與事件來源 (例如 Cloud Storage 值區) 的地區不同。請參閱本頁後續內容,瞭解如何指定函式執行的地區。
支援的地區
在本節的清單中, energy_savings_leaf 圖示表示該地區的電力是透過低碳排放方式產生。如需更多資訊,請參閱「Google Cloud 區域的無碳能源」。
級別 1 定價
Cloud Functions 可在下列採用級別 1 價格的地區使用:
區域 | 位置 | 支援的產品版本 | 二氧化碳排放量 |
---|---|---|---|
asia-east1 |
台灣 | 第 1 代、第 2 代 | |
asia-east2 |
香港 | 僅限第 1 代 | |
asia-northeast1 |
東京 | 第 1 代、第 2 代 | |
asia-northeast2 |
大阪 | 第 1 代、第 2 代 | |
europe-north1 |
芬蘭 | 僅限第 2 代 | energy_savings_leaf |
europe-southwest1 |
馬德里 | 僅限第 2 代 | |
europe-west1 |
比利時 | 第 1 代、第 2 代 | energy_savings_leaf |
europe-west4 |
荷蘭 | 僅限第 2 代 | |
europe-west8 |
米蘭 | 僅限第 2 代 | |
europe-west9 |
巴黎 | 僅限第 2 代 | energy_savings_leaf |
me-west1 |
特拉維夫 | 僅限第 2 代 | |
europe-west2 |
倫敦 | 僅限第 1 代 | |
us-central1 |
愛荷華州 | 第 1 代、第 2 代 | energy_savings_leaf |
us-east1 |
南卡羅來納州 | 第 1 代、第 2 代 | |
us-east4 |
北維吉尼亞州 | 第 1 代、第 2 代 | |
us-east5 |
哥倫布 | 僅限第 2 代 | |
us-south1 |
達拉斯 | 僅限第 2 代 | |
us-west1 |
奧勒岡州 | 第 1 代、第 2 代 | energy_savings_leaf |
級別 2 定價
Cloud Functions 可在下列採用級別 2 價格的地區使用:
區域 | 位置 | 支援的產品版本 | 二氧化碳排放量 |
---|---|---|---|
asia-east2 |
香港 | 僅限第 2 代 | |
asia-northeast3 |
首爾 | 第 1 代、第 2 代 | |
asia-southeast1 |
新加坡 | 第 1 代、第 2 代 | |
asia-southeast2 |
雅加達 | 第 1 代、第 2 代 | |
asia-south1 |
孟買 | 僅限第 2 代 | |
asia-south2 |
印度德里 | 僅限第 2 代 | |
australia-southeast1 |
雪梨 | 第 1 代、第 2 代 | |
australia-southeast2 |
墨爾本 | 僅限第 2 代 | |
europe-central2 |
華沙 | 第 1 代、第 2 代 | |
europe-west2 |
倫敦 | 僅限第 2 代 | |
europe-west3 |
法蘭克福 | 第 1 代、第 2 代 | energy_savings_leaf |
europe-west6 |
蘇黎世 | 第 1 代、第 2 代 | energy_savings_leaf |
europe-west10 |
柏林 | 僅限第 2 代 | |
europe-west12 |
杜林 | 僅限第 2 代 | |
me-central1 |
杜哈 | 僅限第 2 代 | |
me-central2 |
達曼 | 僅限第 2 代 | |
northamerica-northeast1 |
蒙特婁 | 第 1 代、第 2 代 | energy_savings_leaf |
northamerica-northeast2 |
多倫多 | 僅限第 2 代 | energy_savings_leaf |
southamerica-east1 |
聖保羅 | 第 1 代、第 2 代 | energy_savings_leaf |
southamerica-west1 |
智利聖地牙哥 | 僅限第 2 代 | |
us-west2 |
洛杉磯 | 第 1 代、第 2 代 | |
us-west3 |
鹽湖城 | 第 1 代、第 2 代 | |
us-west4 |
拉斯維加斯 | 第 1 代、第 2 代 |
指定專案內指定地區中的函式必須擁有唯一 (不區分大小寫) 名稱,但跨地區或跨專案的函式可能會共用相同名稱。
指定區域的最佳做法
根據預設,函式會在 us-central1
區域中執行。請注意,這可能與事件來源 (例如 Cloud Storage 值區) 的地區不同。如果您需要指定函式執行的地區,請按照本節中各函式觸發事件類型的建議操作。
如要設定函式執行的區域,請在函式定義中設定 region
參數,如下所示:
Node.js
exports.firestoreAsia = onDocumentCreated(
{
document: "my-collection/{docId}",
region: "asia-northeast1",
},
(event) => {},
);
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
您可以在 region
中傳遞多個以半形逗號分隔的區域字串,藉此指定多個區域。另請注意,為多種背景觸發條件類型指定區域時,您必須一併指定正確的事件篩選器。在上述範例中,這是發出事件的 Cloud Firestore document
。對於 Cloud Storage 觸發條件,事件篩選器可以是 bucket
;對於 Pub/Sub 觸發條件,則為 topic
,以此類推。
如要進一步瞭解如何變更負責處理實際流量的函式區域,請參閱「變更函式區域」。
HTTP 和可供用戶端呼叫的函式
針對 HTTP 和可呼叫的函式,建議您先將函式設為目的地區域,或最接近大部分預期客戶所在位置的區域,然後變更原始函式,將其 HTTP 要求重新導向至新函式 (兩者可以有相同名稱)。如果 HTTP 函式的用戶端支援重新導向,您只需變更原始函式,即可傳回 HTTP 重新導向狀態 (301) 和新函式的網址。如果您的用戶端無法妥善處理重新導向,您可以代理從原始函式到新函式的要求,方法是從原始函式到新函式發起新要求。最後一步是確保所有用戶端都會呼叫新函式。
可呼叫函式的用戶端位置選項
就可呼叫函式而言,用戶端可呼叫設定應遵循與 HTTP 函式相同的規範。用戶端也可以指定區域,如果函式在 us-central1
以外的任何區域執行,就必須這麼做。
如要在用戶端設定區域,請在初始化時指定所需區域:
Swift
lazy var functions = Functions.functions(region:"europe-west1")
Objective-C
@property(strong, nonatomic) FIRFunctions *functions;
// ...
self.functions = [FIRFunctions functionsWithRegion:@"europe-west1"];
網路
var functions = firebase.app().functions('europe-west1');
Android
private FirebaseFunctions mFunctions;
// ...
mFunctions = FirebaseFunctions.getInstance("europe-west1");
C++
firebase::functions::Functions* functions;
// ...
functions = firebase::functions::Functions::GetInstance("europe-west1");
Unity
firebase.Functions.FirebaseFunctions functions;
functions = Firebase.Functions.FirebaseFunctions.GetInstance("europe-west1");
背景函式
背景函式採用至少一次事件傳遞語意,這表示在某些情況下,背景函式可能會收到重複的事件。因此,您應實作冪等的函式。如果函式已是同質函式,您可以在確認新函式可正確接收流量後,在新區域中以相同事件觸發事件重新部署函式,並移除舊函式。在這個轉換期間,兩個函式都會收到事件。如要瞭解變更函式區域的建議指令順序,請參閱「變更函式區域」一文。
如果您的函式目前並非冪等,或其冪等未延伸到地區之外,則我們建議您先實作冪等,再移動函式。
最佳區域建議會因事件觸發條件類型而異:
觸發條件類型 | 地區建議 |
---|---|
Cloud Firestore | 與 Cloud Firestore 執行個體位置最接近的區域 (請參閱下一節) |
Realtime Database | 一律使用 us-central1 |
Cloud Storage | 離 Cloud Storage 值區位置最近的區域 (請參閱下一節) |
其他 | 如果您要與函式中的 Realtime Database 例項、Cloud Firestore 例項或 Cloud Storage 值區互動,建議的區域與您透過其中一個資源觸發函式時相同。否則,請使用預設區域 us-central1 。連線至 Firebase Hosting 的函式可以位於任何區域,但請參閱無伺服器主機總覽,瞭解建議。 |
依據 Cloud Firestore 和 Cloud Storage 位置選取區域
函式可用的區域不一定與 Cloud Firestore 資料庫和 Cloud Storage 資料夾可用的區域完全一致。
請注意,如果函式和資源 (資料庫執行個體或 Cloud Storage 值區) 位於不同位置,延遲時間和帳單費用可能會增加。
以下是 Cloud Firestore 和 Cloud Storage 支援的函式最接近的地區對應表,適用於不支援相同地區的情況:
Cloud Firestore 和 Cloud Storage 的區域/多區域 | 函式最近區域 |
---|---|
nam5 或 us-central (多區域) |
us-central1 |
eur3 或 europe-west (多區域) |
europe-west1 |
europe-west4 (荷蘭) |
europe-west1 |
asia-south1 (孟買) |
asia-east2 |
asia-south2 (德里) |
asia-east2 |
australia-southeast2 (墨爾本) |
australia-southeast1 |