Cloud Functions 位置

Cloud Functions 具有區域性，這表示執行函式的基礎架構位於特定區域，並由 Google 管理，可為這些區域內的所有可用區提供備援功能。

選擇執行函式的區域時，主要考量重點在於延遲時間和可用性。原則上可以選擇距離使用者最近的地區，但也應考慮應用程式所用其他產品和服務的位置。如果跨多個區域使用服務，可能會影響應用程式的延遲時間和定價。

根據預設，函式會在 us-central1 區域中執行。請注意，這可能與事件來源 (例如 Cloud Storage 值區) 的區域不同。如要瞭解如何指定函式執行的區域，請參閱本頁後續內容。

支援的地區

在本節的清單中， energy_savings_leaf 圖示表示該區域的電力是以低碳排放量產生。詳情請參閱「Google Cloud 區域無碳能源」一文。

級別 1 價格

Cloud Functions 適用於下列級別 1 價格區域：

區域	位置	支援的產品版本	CO₂ 排放量
`africa-south1`	約翰尼斯堡	僅限第 2 代
`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 價格區域：

區域	位置	支援的產品版本	CO₂ 排放量
`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) 以及新函式網址即可。如果用戶端無法妥善處理重新導向，則可從原始函式向新函式發起新要求，經由 Proxy 將要求傳送至新函式。最後一步是確保所有用戶端都會呼叫新函式。

可呼叫函式的用戶端位置選取

至於可呼叫函式，用戶端可呼叫設定應遵循與 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	與 Realtime Database 執行個體位於相同區域
Cloud Storage	最接近 Cloud Storage bucket 位置的區域 (請參閱下一節)
其他	如果您在函式中與 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`

Cloud Functions 位置 透過集合功能整理內容 你可以依據偏好儲存及分類內容。