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 |
Dallas | 仅限第 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 |
Dammam | 仅限第 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 和客户端 Callable 函数
对于 HTTP 和 Callable 函数，我们建议您首先将函数设到目标区域（或离大多数预期客户所在位置最近的位置），然后更改原始函数以将其 HTTP 请求重定向到新函数（函数名称可以相同）。如果 HTTP 函数的客户端支持重定向，那么您只需更改原始函数，使其返回 HTTP 重定向状态 (301) 以及新函数的网址即可。如果您的客户端无法很好地处理重定向，您可以从原始函数发起指向新函数的新请求，以便将请求从原始函数（代理）转发到新函数。最后一步是确保所有客户端都调用新函数。
在客户端为 Callable 函数选择位置
对于 Callable 函数，客户端的相应设置应遵循与 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"];
Web
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 |