管理函数

您可以使用 Firebase CLI 命令或在函数源代码中设置运行时选项来部署、删除和修改函数。

注意：Cloud Functions for Firebase（第 2 代）是公开预览版。也就是说，其功能可能会以不向后兼容的方式更改。预览版不在任何服务等级协议 (SLA) 或弃用政策的涵盖范围内，因此可能只会得到有限的支持或得不到任何支持。

部署函数

如需部署函数，请运行以下 Firebase CLI 命令：

$ firebase deploy --only functions

默认情况下，Firebase CLI 会同时部署 index.js 内的所有函数。如果您的项目包含 5 个以上的函数，建议您使用 --only 标志并指定函数名称，以便仅部署您已修改的函数。以这种方式部署特定函数可加快部署流程，并有助于避免超出部署配额。例如：

$ firebase deploy --only functions:addMessage,functions:makeUppercase

部署大量函数时，可能会超出标准配额，并收到 HTTP 429 或 500 错误消息。如需解决此问题，请以 10 或更少数量为单位分批部署函数。

如需查看可用命令的完整列表，请参阅 Firebase CLI 参考文档。

注意：默认情况下，使用任何低于 7.7.0 版本的 Firebase CLI 部署的新 HTTP 和 HTTP Callable 函数都是私有的，被调用时会抛出 HTTP 403 错误。在部署任何新函数之前，需要明确将这些函数设为公开或更新 Firebase CLI。

默认情况下，Firebase CLI 会在 functions/ 文件夹中查找源代码。如果您愿意，可以在代码库或多组文件中组织函数。

删除函数

您可以通过以下方式删除以前部署的函数：

• 在 Firebase CLI 中使用 functions:delete 明确删除
• 在 Firebase 控制台中使用函数列表中的上下文菜单明确删除
• 在部署前通过从 index.js 中移除函数隐式删除。

所有删除操作都会提示您确认是否从生产环境中移除函数。

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 会解析 index.js 并从生产环境中移除已从文件中移除的任何函数。

修改函数的名称、区域或触发器

如需更改正在处理生产流量的函数的名称、区域或触发器，请按本部分中的步骤操作，以免在修改期间丢失事件。在执行这些步骤之前，请先确保您的函数为幂等函数，因为在更改期间，函数的新版本和旧版本均会处于运行状态。

重命名函数

如需重命名函数，请在 index.js 中创建函数改名后的新版本，然后分别运行两个部署命令。第一个命令部署改名后的函数，而第二个命令则移除以前部署的版本。例如，如果您要将名为 webhook 的函数更名为 webhookNew，请按以下方式修改代码：

// 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");
});

然后运行以下命令，部署新函数：

# Deploy new function called webhookNew
$ firebase deploy --only functions:webhooknew

# Wait until deployment is done; now both webhooknew and webhook are running

# Delete webhook
$ firebase functions:delete webhook

更改函数的一个或多个区域

如需更改正在处理生产流量的函数的指定区域，您可以按顺序执行以下步骤，以防止丢失事件：

1. 重命名该函数，并根据需要更改其一个或多个区域。
2. 部署重命名的函数，这样就会暂时在两组区域中运行相同的代码。
3. 删除先前的函数。

例如，如果您有一个名为 webhook 的函数当前位于 us-central1 的默认函数区域，您希望将其迁移到 asia-northeast1，则需要先修改源代码，重命名该函数并修改区域。

// 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.webhookasia = onRequest({
        region: 'asia-northeast1'
    }, (req, res) => {
    res.send("Hello");
});

然后运行以下命令部署函数：

$ firebase deploy --only functions:webhookAsia

现在有两个相同的函数在运行：webhook 在 us-central1 中运行，webhookasia 在 asia-northeast1 中运行。

然后，删除 webhook：

$ firebase functions:delete webhook

现在只存在一个函数 - webhookasia，它在 asia-northeast1 中运行。

更改函数的触发器类型

当您的 Cloud Functions for Firebase 部署工作开展一段时间后，您可能会出于各种原因而需要更改函数的触发器类型。例如，您可能希望将触发器类型从 Firebase Realtime Database 或 Cloud Firestore 的一种事件类型更改为另一种事件类型，例如，从宽泛的 onWrite 事件更改为细化的 onCreate 事件。

仅凭更改源代码和运行 firebase deploy 无法更改函数的事件类型。为避免错误，请按以下流程更改函数的触发器类型：

1. 修改源代码，加入具备所需触发器类型的新函数。
2. 部署该函数，这样暂时会同时运行新旧两个函数。
3. 使用 Firebase CLI 从生产环境中明确删除旧函数。

例如，如果您有一个函数 objectchanged 具有旧版 onMetadataUpdated 事件类型，而您希望将其更改为 onObjectFinalized，请先重命名该函数，再将其事件类型修改为 onObjectFinalized。

// before
const {onMetadataUpdated} = require('firebase-functions/v2/storage');

exports.objectchanged = onMetadataUpdated((event) => {
    return console.log('File name is: ', event.data.name);
});

// after
const {onObjectFinalized} = require('firebase-functions/v2/storage');

exports.objectchanged = onObjectFinalized((event) => {
    return console.log('File name is: ', event.data.name);
});

然后运行以下命令，以便先创建新函数，然后再删除旧函数：

# Create new function objectFinalized
$ firebase deploy --only functions:objectFinalized

# Wait until deployment is done; now both objectChanged and objectFinalized are running

# Delete objectChanged
$ firebase functions:delete objectChanged

设置运行时选项

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 CLI 查看函数的完整配置。

设置 Node.js 版本

Firebase SDK for Cloud Functions（第 2 代）支允许选择 Node.js 运行时。 您可以选择仅在下面其中一个受支持的 Node.js 版本所对应的运行时环境中运行一个项目中的所有函数：

• Node.js 16
• Node.js 14

如需设置 Node.js 版本，请执行以下操作：

在初始化期间于 functions/ 目录下创建的 package.json 文件的 engines 字段中设置版本。例如，如仅需使用版本 16，请在 package.json 中修改下面一行内容：

  "engines": {"node": "16"}

engines 是必需字段，必须指定一个受支持的 Node.js 版本，以便您部署和运行函数。目前，firebase init functions 将此字段设置为 16。

升级 Node.js 运行时

如需升级 Node.js 运行时，请执行以下操作：

1. 确保您的项目采用的是 Blaze 定价方案。
2. 确保您使用的是 Firebase CLI v9.17.0 或更高版本。
3. 更改在初始化期间于 functions/ 目录下创建的 package.json 文件中的 engines 值。例如，如果您要从版本 10 升级到版本 16，请按如下方式设置该字段："engines": {"node": "16"}
4. 使用 Firebase CLI v9.17.0 或更高版本重新部署函数。

控制伸缩行为

默认情况下，Cloud Functions for Firebase 会根据传入请求数量调整运行的实例数量，当流量减少时可能会将实例数缩减为零。但是，如果您的应用要求更低的延迟时间，并且您希望限制冷启动次数，您可以指定保持备用状态并已准备好处理请求的容器实例数下限，来更改此默认行为。

同样，您也可以设置数量上限，限制为应对传入请求而扩增的实例数。使用此设置可以控制您的费用或限制与支持性服务（如数据库）的连接数。

通过将这些设置与每个实例的并发设置（第 2 代中的新功能）结合使用，您可以控制和调整函数的伸缩行为。应用和函数的性质决定了哪些设置最符合成本效益并可实现最佳性能。

对于某些低流量的应用，使用较少的 CPU 并且不设置多并发是最佳选择。对于冷启动是关键问题的其他应用，设置高并发和较高的实例数下限意味着一组实例始终保持备用状态以应对流量激增。

对于接收的流量非常少的较小规模应用，设置较低的实例数上限以及高并发意味着应用可以处理突发流量，而不会产生过多费用。

注意：冷启动尚未在第 2 代中进行优化，因此暂时可能会明显慢于第 1 代。但是，由于存在并发机制，最终用户体验到的总体冷启动时间应该会减少。

允许并发请求

在 Cloud Functions for Firebase（第 1 代）中，每个实例一次可以处理一个请求，因此只能通过 minInstances 和 maxInstances 设置来设定伸缩行为。在 Cloud Functions for Firebase（第 2 代）中，除了控制实例数之外，您还可以使用 concurrency 选项来控制每个实例可以同时处理的请求数量。并发设置的默认值为 80，但您可以将其设为 1 到 1000 之间的任何整数。

并发设置值较高的函数可以在没有冷启动的情况下吸收流量高峰，因为每个实例都可能有一些提升潜力。如果某个实例配置为最多处理 50 个并发请求，但当前仅处理 25 个请求，那么该实例另外还能处理 25 个请求，而无需冷启动新实例。相比之下，如果并发设置设为 1，请求激增可能会导致 25 次冷启动。

重要提示：并发仅适用于至少使用 1 个完整 CPU 的函数。对于 RAM 小于 2GB 的函数，将函数的 CPU 设置为小数值或将 CPU 设置为 gcf_gen1 会停用并发。 请参阅替换 CPU 默认设置。

在 Cloud Functions for Firebase（第 2 代）中尝试使用更高的并发设置时，请注意以下几点：

• 更高的并发设置可能需要更高的 CPU 和 RAM 才能获得最佳性能，直到达到实际限制。例如，执行大量图像或视频处理的函数可能缺乏处理 1000 个并发请求的资源，即使其 CPU 和 RAM 设置已设为最大值也是如此。
• 由于 Cloud Functions for Firebase（第 2 代）由 Cloud Run 提供支持，因此您还可以参阅 Google Cloud 指南，了解如何优化并发。
• 在生产环境中切换到多并发之前，请务必在测试环境中对多并发进行全面测试。

减少冷启动次数

如需在源代码中为函数设置实例数下限，请使用 minInstances 选项。例如，此函数将保持备用状态的实例数下限设置为 5：

  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
    }
  );

注意：最小数量的实例持续运行产生的结算费用以闲置费率计算。第 1 代函数默认内存分配为 256MiB 时的费用约为 $3/月（停用 gcf_gen_1 CPU 分配和并发）或大约 $8/月（启用 1 个 CPU 和并发）。对于预留最小数量实例的函数，Firebase CLI 会在部署时提供费用估算。请参阅 Cloud Run 价格来计算费用。

为 minInstances 设置值时，您需要考虑以下事项：

• 如果 Cloud Functions for Firebase 将您的应用扩容到超过 minInstances 设置范围，超出该阈值以后的每个实例都会进行冷启动。
• 冷启动对于有流量激增现象的应用会产生最为严重的影响。如果您的应用流量会激增，并且您将 minInstances 值设置得足够高，可以在每次流量增加时减少冷启动次数，延迟时间将明显缩短。对于流量稳定的应用，冷启动不太可能严重影响性能。

• 设置实例数下限可能适合生产环境，但在测试环境中通常应避免。如需在测试项目中缩减至零，但仍在生产项目中减少冷启动，您可以根据 FIREBASE_CONFIG 环境变量设置 minInstances：

  // Get Firebase project ID from `FIREBASE_CONFIG` environment variable
  const envProjectId = JSON.parse(process.env.FIREBASE_CONFIG).projectId;
  
  exports.renderProfilePage = onRequest(
    {
      // Keep 5 instances warm for this latency-critical function
      // in production only. Default to 0 for test projects.
      minInstances: envProjectId === "my-production-project" ? 5 : 0,
    },
    (req, res) => {
      // render some html
    }
  );
  

限制函数的实例数上限

如需在函数源代码中设置实例数上限，请使用 maxInstances 选项。 例如，以下函数将实例数上限设置为 100，以避免假设的旧数据库超负荷：

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

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

注意：如需更好地控制调用速率和限制，请考虑使用任务队列函数。

如果 HTTP 函数扩容到 maxInstances 上限，则新请求将在队列中等候 30 秒；如果这段时间内仍没有可用的实例，则系统将拒绝这些请求并返回响应代码 429 Too Many Requests。

如需详细了解使用实例数上限设置的最佳做法，请查看这些使用 maxInstances 的最佳做法。

设置超时时间和内存分配

在某些情况下，您的函数可能有特殊要求，需要具备较长的超时值或分配较多的内存。您可以在 Google Cloud 控制台或函数源代码（仅限 Firebase）中设置这些值。

如需在函数源代码中设置内存分配和超时，请使用 GlobalOptions.memory 和 GlobalOptions.timeoutSeconds 来自定义运行函数的虚拟机。例如，以下 Cloud Storage 函数使用 1 GiB 的内存，并会在 300 秒后超时：

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

timeoutSeconds 的最大值为 540，即 9 分钟。

如需在 Google Cloud 控制台中设置内存分配和超时，请执行以下操作：

1. 在 Google Cloud 控制台中，从左侧菜单中选择 Cloud Functions for Firebase。
2. 点击函数列表中的名称，选择相应函数。
3. 点击顶部菜单中的修改图标。
4. 从名为分配的内存的下拉菜单中选择内存分配。
5. 点击更多以显示高级选项，并在超时文本框中输入秒数。
6. 点击保存以更新函数。

替换 CPU 默认设置

分配的内存最高为 2 GB，Cloud Functions for Firebase（第 2 代）中的每个函数默认配置了一个 CPU，然后可以增加到 2 个 CPU，分配的内存分别为 4 GB 和 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.7x
1 GB	7/12	1	1.6x
2 GB	1	1	1x
4 GB	2	2	1x
8 GB	2	2	1x
16 GB	不适用	4	不适用

如果您希望为第 2 代函数保留第 1 代行为，请将第 1 代默认值设置为全局选项：

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

对于 CPU 密集型函数，第 2 代可让您灵活地配置额外的 CPU。您可以按函数增加 CPU 数量，如下所示：

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