Quản lý chức năng

Bạn có thể triển khai, xoá và sửa đổi các hàm bằng lệnh CLI Firebase hoặc bằng cách đặt các tuỳ chọn thời gian chạy trong mã nguồn của hàm.

Triển khai hàm

Để triển khai các hàm, hãy chạy lệnh Firebase CLI sau:

firebase deploy --only functions

Theo mặc định, CLI Firebase triển khai tất cả các hàm bên trong nguồn của bạn cùng một lúc. Nếu dự án của bạn chứa hơn 5 hàm, bạn nên sử dụng cờ --only với tên hàm cụ thể để chỉ triển khai những hàm mà bạn đã chỉnh sửa. Việc triển khai các hàm cụ thể theo cách này sẽ đẩy nhanh quá trình triển khai và giúp bạn tránh vượt quá hạn mức triển khai. Ví dụ:

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

Khi triển khai số lượng lớn hàm, bạn có thể vượt quá hạn mức tiêu chuẩn và nhận được thông báo lỗi HTTP 429 hoặc 500. Để giải quyết vấn đề này, hãy triển khai các hàm theo nhóm gồm tối đa 10 hàm.

Hãy xem Tài liệu tham khảo về CLI Firebase để biết danh sách đầy đủ các lệnh hiện có.

Theo mặc định, CLI Firebase sẽ tìm mã nguồn trong thư mục functions/. Nếu muốn, bạn có thể sắp xếp các hàm trong cơ sở mã hoặc nhiều nhóm tệp.

Dọn dẹp cấu phần phần mềm triển khai

Trong quá trình triển khai hàm, hình ảnh vùng chứa được tạo và lưu trữ trong Artifact Registry. Những hình ảnh này không bắt buộc để các hàm đã triển khai của bạn chạy; Cloud Functions tìm nạp và giữ lại một bản sao của hình ảnh trong lần triển khai ban đầu, nhưng các cấu phần phần mềm được lưu trữ không cần thiết để hàm hoạt động trong thời gian chạy.

Mặc dù các hình ảnh vùng chứa này thường nhỏ, nhưng chúng có thể tích luỹ theo thời gian và góp phần vào chi phí lưu trữ của bạn. Bạn nên giữ lại các cấu phần phần mềm này trong một khoảng thời gian nếu dự định kiểm tra cấu phần phần mềm đã tạo hoặc chạy quy trình quét lỗ hổng bảo mật của vùng chứa.

Để giúp quản lý chi phí lưu trữ, Firebase CLI 14.0.0 trở lên cho phép bạn định cấu hình chính sách dọn dẹp Artifact Registry cho các kho lưu trữ lưu trữ cấu phần phần mềm triển khai sau mỗi lần triển khai hàm.

Bạn có thể thiết lập hoặc chỉnh sửa chính sách dọn dẹp theo cách thủ công bằng lệnh functions:artifacts:setpolicy:

firebase functions:artifacts:setpolicy

Theo mặc định, lệnh này định cấu hình Artifact Registry để tự động xoá hình ảnh vùng chứa cũ hơn 1 ngày. Điều này giúp cân bằng hợp lý giữa việc giảm thiểu chi phí lưu trữ và cho phép kiểm tra các bản dựng gần đây.

Bạn có thể tuỳ chỉnh thời gian lưu giữ bằng tuỳ chọn --days:

firebase functions:artifacts:setpolicy --days 7  # Delete images older than 7 days

Nếu triển khai các hàm cho nhiều khu vực, bạn có thể thiết lập chính sách dọn dẹp cho một vị trí cụ thể bằng cách sử dụng tuỳ chọn --location:

$ firebase functions:artifacts:setpolicy --location europe-west1

Chọn không dọn dẹp cấu phần phần mềm

Nếu muốn quản lý việc dọn dẹp hình ảnh theo cách thủ công hoặc nếu không muốn xoá bất kỳ hình ảnh nào, bạn có thể chọn không áp dụng hoàn toàn chính sách dọn dẹp:

$ firebase functions:artifacts:setpolicy --none

Lệnh này sẽ xoá mọi chính sách dọn dẹp hiện có mà CLI Firebase đã thiết lập và ngăn Firebase thiết lập chính sách dọn dẹp sau khi triển khai hàm.

Xoá hàm

Bạn có thể xoá các hàm đã triển khai trước đó theo những cách sau:

• một cách rõ ràng trong CLI Firebase bằng functions:delete
• một cách rõ ràng trong bảng điều khiển Google Cloud.
• ngầm bằng cách xoá hàm khỏi nguồn trước khi triển khai.

Tất cả thao tác xoá đều nhắc bạn xác nhận trước khi xoá hàm khỏi môi trường thực tế.

Tính năng xoá hàm rõ ràng trong CLI Firebase hỗ trợ nhiều đối số cũng như các nhóm hàm, đồng thời cho phép bạn chỉ định một hàm chạy trong một khu vực cụ thể. Ngoài ra, bạn có thể ghi đè lời nhắc xác nhận.

• Xoá tất cả hàm khớp với tên đã chỉ định ở mọi khu vực:

  firebase functions:delete FUNCTION-1_NAME

• Xoá một hàm cụ thể đang chạy ở một khu vực không phải là khu vực mặc định:

  firebase functions:delete FUNCTION-1_NAME --region REGION_NAME

• Xoá nhiều hàm:

  firebase functions:delete FUNCTION-1_NAME FUNCTION-2_NAME

• Xoá một nhóm hàm cụ thể:

  firebase functions:delete GROUP_NAME

• Bỏ qua lời nhắc xác nhận:

  firebase functions:delete FUNCTION-1_NAME --force

Với tính năng xoá hàm ngầm định, firebase deploy sẽ phân tích cú pháp nguồn của bạn và xoá khỏi môi trường production mọi hàm đã bị xoá khỏi tệp.

Sửa đổi tên, khu vực hoặc điều kiện kích hoạt của hàm

Nếu bạn đang đổi tên hoặc thay đổi khu vực hoặc điều kiện kích hoạt cho các hàm đang xử lý lưu lượng truy cập thực tế, hãy làm theo các bước trong phần này để tránh mất sự kiện trong quá trình sửa đổi. Trước khi làm theo các bước này, trước tiên, hãy đảm bảo rằng hàm của bạn là idempotent (bất biến), vì cả phiên bản mới và phiên bản cũ của hàm sẽ chạy cùng lúc trong quá trình thay đổi.

Đổi tên hàm

Để đổi tên một hàm, hãy tạo một phiên bản mới của hàm đó trong nguồn rồi chạy hai lệnh triển khai riêng biệt. Lệnh đầu tiên triển khai hàm được đặt tên mới và lệnh thứ hai xoá phiên bản đã triển khai trước đó. Ví dụ: nếu bạn có một webhook được kích hoạt bằng HTTP mà bạn muốn đổi tên, hãy sửa đổi mã như sau:

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

# 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!")

Sau đó, hãy chạy các lệnh sau để triển khai hàm mới:

# Deploy new function
firebase deploy --only functions:webhookNew

# Wait until deployment is done; now both functions are running

# Delete webhook
firebase functions:delete webhook

Thay đổi một hoặc nhiều khu vực của hàm

Nếu đang thay đổi khu vực được chỉ định cho một hàm đang xử lý lưu lượng truy cập thực tế, bạn có thể ngăn chặn việc mất sự kiện bằng cách thực hiện các bước sau theo thứ tự:

1. Đổi tên hàm và thay đổi (các) khu vực của hàm theo ý muốn.
2. Triển khai hàm đã đổi tên, dẫn đến việc tạm thời chạy cùng một mã trong cả hai nhóm khu vực.
3. Xoá hàm trước đó.

Ví dụ: nếu có một hàm được kích hoạt bằng Cloud Firestore hiện đang được triển khai trong us-central1 và bạn muốn di chuyển hàm đó sang asia-northeast1, thì trước tiên, bạn cần sửa đổi mã nguồn để đổi tên hàm và sửa đổi khu vực.

// before
exports.firestoreTrigger = onDocumentCreated(
  "my-collection/{docId}",
  (event) => {},
);

// after
exports.firestoreTriggerAsia = onDocumentCreated(
  {
    document: "my-collection/{docId}",
    region: "asia-northeast1",
  },
  (event) => {},
);

# 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

Sau đó, triển khai bằng cách chạy:

firebase deploy --only functions:firestoreTriggerAsia

Bây giờ, có hai hàm giống hệt nhau đang chạy: firestoreTrigger đang chạy trong us-central1 và firestoreTriggerAsia đang chạy trong asia-northeast1.

Sau đó, hãy xoá firestoreTrigger:

firebase functions:delete firestoreTrigger

Giờ đây, chỉ có một hàm – firestoreTriggerAsia, đang chạy trong asia-northeast1.

Thay đổi loại điều kiện kích hoạt của hàm

Khi phát triển quá trình triển khai Cloud Functions for Firebase theo thời gian, bạn có thể cần thay đổi loại điều kiện kích hoạt của hàm vì nhiều lý do. Ví dụ: bạn có thể muốn thay đổi từ một loại sự kiện Firebase Realtime Database hoặc Cloud Firestore sang một loại khác.

Bạn không thể thay đổi loại sự kiện của một hàm chỉ bằng cách thay đổi mã nguồn và chạy firebase deploy. Để tránh lỗi, hãy thay đổi loại điều kiện kích hoạt của hàm theo quy trình sau:

1. Sửa đổi mã nguồn để thêm một hàm mới có loại điều kiện kích hoạt mong muốn.
2. Triển khai hàm, dẫn đến việc tạm thời chạy cả hàm cũ và hàm mới.
3. Xoá rõ ràng hàm cũ khỏi môi trường production bằng CLI Firebase.

Ví dụ: nếu bạn có một hàm được kích hoạt khi một đối tượng bị xoá, nhưng sau đó bạn bật tính năng tạo phiên bản đối tượng và muốn đăng ký sự kiện lưu trữ, thì trước tiên, hãy đổi tên hàm và chỉnh sửa hàm đó để có loại điều kiện kích hoạt mới.

// before
const {onObjectDeleted} = require("firebase-functions/v2/storage");

exports.objectDeleted = onObjectDeleted((event) => {
    // ...
});

// after
const {onObjectArchived} = require("firebase-functions/v2/storage");

exports.objectArchived = onObjectArchived((event) => {
    // ...
});

# 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):
  # ...

Sau đó, hãy chạy các lệnh sau để tạo hàm mới trước khi xoá hàm cũ:

# 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

Đặt các lựa chọn về thời gian chạy

Cloud Functions for Firebase cho phép bạn chọn các tuỳ chọn thời gian chạy, chẳng hạn như phiên bản thời gian chạy Node.js và thời gian chờ, mức phân bổ bộ nhớ cũng như số lượng thực thể hàm tối thiểu/tối đa cho mỗi hàm.

Tốt nhất là bạn nên đặt các tuỳ chọn này (ngoại trừ phiên bản Node.js) trên một đối tượng cấu hình bên trong mã hàm. Đối tượng RuntimeOptions này là nguồn đáng tin cậy cho các tuỳ chọn thời gian chạy của hàm và sẽ ghi đè các tuỳ chọn được đặt bằng bất kỳ phương thức nào khác (chẳng hạn như bảng điều khiển Google Cloud hoặc gcloud CLI).

Nếu quy trình phát triển của bạn liên quan đến việc đặt các tuỳ chọn thời gian chạy theo cách thủ công bằng bảng điều khiển Google Cloud hoặc gcloud CLI và bạn không muốn các giá trị này bị ghi đè trong mỗi lần triển khai, hãy đặt tuỳ chọn preserveExternalChanges thành true. Khi bạn đặt tuỳ chọn này thành true, Firebase sẽ hợp nhất các tuỳ chọn thời gian chạy được đặt trong mã của bạn với chế độ cài đặt của phiên bản hàm hiện được triển khai theo mức độ ưu tiên sau:

1. Tuỳ chọn được đặt trong mã hàm: ghi đè các thay đổi bên ngoài.
2. Tuỳ chọn được đặt thành RESET_VALUE trong mã hàm: ghi đè các thay đổi bên ngoài bằng giá trị mặc định.
3. Tuỳ chọn không được đặt trong mã hàm, nhưng được đặt trong hàm hiện đang được triển khai: sử dụng tuỳ chọn được chỉ định trong hàm đã triển khai.

Bạn không nên sử dụng tuỳ chọn preserveExternalChanges: true cho hầu hết các trường hợp vì mã của bạn sẽ không còn là nguồn đáng tin cậy duy nhất cho các tuỳ chọn thời gian chạy cho các hàm của bạn. Nếu bạn sử dụng, hãy kiểm tra bảng điều khiển Google Cloud hoặc sử dụng gcloud CLI để xem cấu hình đầy đủ của hàm.

Đặt phiên bản Node.js

SDK Firebase cho Cloud Functions cho phép lựa chọn môi trường thời gian chạy Node.js. Bạn có thể chọn chạy tất cả các hàm trong một dự án chỉ trên môi trường thời gian chạy tương ứng với một trong các phiên bản Node.js được hỗ trợ sau:

• Node.js 22
• Node.js 20
• Node.js 18 (không dùng nữa)

Node.js phiên bản 14 và 16 đã ngừng hoạt động vào đầu năm 2025. Bạn không thể triển khai bằng các phiên bản này. Hãy xem lịch hỗ trợ để biết thông tin quan trọng về việc hỗ trợ liên tục cho các phiên bản Node.js này.

Cách đặt phiên bản Node.js:

Bạn có thể đặt phiên bản trong trường engines trong tệp package.json được tạo trong thư mục functions/ trong quá trình khởi chạy. Ví dụ: để chỉ sử dụng phiên bản 20, hãy chỉnh sửa dòng này trong package.json:

  "engines": {"node": "20"}

Nếu đang sử dụng trình quản lý gói Yarn hoặc có các yêu cầu cụ thể khác đối với trường engines, bạn có thể đặt thời gian chạy cho SDK Firebase cho Cloud Functions trong firebase.json:

  {
    "functions": {
      "runtime": "nodejs20" // or nodejs22
    }
  }

CLI sử dụng giá trị được đặt trong firebase.json thay vì bất kỳ giá trị hoặc phạm vi nào mà bạn đặt riêng trong package.json.

Nâng cấp môi trường thời gian chạy Node.js

Cách nâng cấp môi trường thời gian chạy Node.js:

1. Đảm bảo dự án của bạn đang sử dụng gói giá Blaze.
2. Đảm bảo bạn đang sử dụng Firebase CLI phiên bản 11.18.0 trở lên.
3. Thay đổi giá trị engines trong tệp package.json được tạo trong thư mục functions/ trong quá trình khởi chạy. Ví dụ: nếu bạn đang nâng cấp từ phiên bản 18 lên phiên bản 20, thì mục nhập sẽ có dạng như sau: "engines": {"node": "20"}
4. Bạn có thể kiểm tra các thay đổi bằng Firebase Local Emulator Suite.
5. Triển khai lại tất cả các hàm.

Chọn một hệ thống mô-đun Node.js

Hệ thống mô-đun mặc định trong Node.js là CommonJS (CJS), nhưng các phiên bản Node.js hiện tại cũng hỗ trợ Mô-đun ECMAScript (ESM). Cloud Functions hỗ trợ cả hai.

Theo mặc định, các hàm của bạn sẽ sử dụng CommonJS. Điều đó có nghĩa là các lệnh nhập và xuất sẽ có dạng như sau:

const {onRequest} = require("firebase-functions/https");

exports.helloWorld = onRequest(async (req, res) => res.send("Hello from Firebase!"));

Để sử dụng ESM, hãy đặt trường "type": "module" trong tệp package.json :

  {
   ...
   "type": "module",
   ...
  }

Sau khi thiết lập, hãy sử dụng cú pháp ESM import và export:

import {onRequest} from "firebase-functions/https";

export const helloWorld = onRequest(async (req, res) => res.send("Hello from Firebase!"));

Cả hai hệ thống mô-đun đều được hỗ trợ đầy đủ. Bạn có thể chọn cách phù hợp nhất với dự án của mình. Tìm hiểu thêm trong tài liệu về mô-đun của Node.js.

Đặt phiên bản Python

Firebase SDK cho Cloud Functions phiên bản 12.0.0 trở lên cho phép chọn thời gian chạy Python. Đặt phiên bản thời gian chạy trong firebase.json như minh hoạ:

  {
    "functions": {
      "runtime": "python310" // or python311
    }
  }

Kiểm soát hành vi điều chỉnh tỷ lệ

Theo mặc định, Cloud Functions for Firebase sẽ điều chỉnh số lượng thực thể đang chạy dựa trên số lượng yêu cầu gửi đến, có thể giảm xuống còn 0 thực thể khi lưu lượng truy cập giảm. Tuy nhiên, nếu ứng dụng của bạn yêu cầu giảm độ trễ và bạn muốn giới hạn số lần khởi động nguội, thì bạn có thể thay đổi hành vi mặc định này bằng cách chỉ định số lượng thực thể vùng chứa tối thiểu cần được giữ ấm và sẵn sàng phân phát yêu cầu.

Tương tự, bạn có thể đặt số lượng tối đa để giới hạn việc điều chỉnh quy mô của các thực thể nhằm phản hồi các yêu cầu đến. Hãy sử dụng chế độ cài đặt này để kiểm soát chi phí hoặc giới hạn số lượng kết nối với một dịch vụ sao lưu, chẳng hạn như cơ sở dữ liệu.

Khi sử dụng các chế độ cài đặt này cùng với chế độ cài đặt đồng thời cho mỗi thực thể (mới trong thế hệ thứ 2), bạn có thể kiểm soát và điều chỉnh hành vi điều chỉnh tỷ lệ cho các hàm của mình. Bản chất của ứng dụng và hàm sẽ xác định chế độ cài đặt nào tiết kiệm chi phí nhất và mang lại hiệu suất tốt nhất.

Đối với một số ứng dụng có lưu lượng truy cập thấp, lựa chọn CPU thấp hơn mà không có tính năng đa đồng thời là lựa chọn tối ưu. Đối với những người khác, khi khởi động nguội là một vấn đề nghiêm trọng, việc đặt số lượng thực thể tối thiểu và đồng thời cao có nghĩa là một tập hợp các thực thể luôn được giữ ấm để xử lý lưu lượng truy cập tăng đột biến.

Đối với các ứng dụng quy mô nhỏ nhận được rất ít lưu lượng truy cập, việc đặt số lượng thực thể tối đa thấp với tính đồng thời cao có nghĩa là ứng dụng có thể xử lý các đợt lưu lượng truy cập tăng đột biến mà không phải chịu chi phí quá cao. Tuy nhiên, hãy lưu ý rằng khi số lượng thực thể tối đa được đặt quá thấp, các yêu cầu có thể bị loại bỏ khi đạt đến giới hạn.

Cho phép yêu cầu đồng thời

Trong Cloud Functions for Firebase (thế hệ thứ 1), mỗi thực thể có thể xử lý một yêu cầu tại một thời điểm, vì vậy, hành vi điều chỉnh quy mô chỉ được đặt bằng chế độ cài đặt thực thể tối thiểu và tối đa. Ngoài việc kiểm soát số lượng thực thể, trong Cloud Functions for Firebase (thế hệ thứ 2), bạn có thể kiểm soát số lượng yêu cầu mà mỗi thực thể có thể phân phát cùng lúc bằng tuỳ chọn concurrency. Giá trị mặc định cho tính đồng thời là 80, nhưng bạn có thể đặt thành bất kỳ số nguyên nào từ 1 đến 1000.

Các hàm có chế độ cài đặt đồng thời cao hơn có thể hấp thụ các mức tăng đột biến về lưu lượng truy cập mà không cần khởi động nguội vì mỗi thực thể có thể có một số khoảng trống. Nếu một thực thể được định cấu hình để xử lý tối đa 50 yêu cầu đồng thời nhưng hiện chỉ xử lý 25 yêu cầu, thì thực thể đó có thể xử lý thêm 25 yêu cầu tăng đột biến mà không cần khởi động nguội một thực thể mới. Ngược lại, với chế độ cài đặt đồng thời chỉ là 1, mức tăng đột biến về số yêu cầu đó có thể dẫn đến 25 lần khởi động nguội.

Tình huống đơn giản này minh hoạ mức tăng hiệu quả tiềm năng của tính năng đồng thời. Trên thực tế, hành vi điều chỉnh quy mô để tối ưu hoá hiệu quả và giảm số lần khởi động nguội bằng tính năng đồng thời sẽ phức tạp hơn. Tính năng đồng thời trong Cloud Functions for Firebase thế hệ thứ 2 được hỗ trợ bởi Cloud Run và tuân theo các quy tắc của Cloud Run về tự động điều chỉnh quy mô thực thể vùng chứa.

Khi thử nghiệm các chế độ cài đặt đồng thời cao hơn trong Cloud Functions for Firebase (thế hệ thứ 2), hãy lưu ý những điều sau:

• Chế độ cài đặt số lượng yêu cầu đồng thời cao hơn có thể yêu cầu CPU và RAM cao hơn để đạt hiệu suất tối ưu cho đến khi đạt đến giới hạn thực tế. Ví dụ: một hàm xử lý hình ảnh hoặc video nặng có thể thiếu tài nguyên để xử lý 1.000 yêu cầu đồng thời, ngay cả khi chế độ cài đặt CPU và RAM của hàm đó được đặt ở mức tối đa.
• Vì Cloud Functions for Firebase (thế hệ thứ 2) được Cloud Run hỗ trợ, nên bạn cũng có thể tham khảo hướng dẫn của Google Cloud về cách tối ưu hoá tính đồng thời.
• Hãy nhớ kiểm thử kỹ lưỡng tính năng đa đồng thời trong môi trường thử nghiệm trước khi chuyển sang tính năng đa đồng thời trong môi trường thực tế.

Duy trì số lượng thực thể tối thiểu ở trạng thái ấm

Bạn có thể đặt số lượng thực thể tối thiểu cho một hàm trong mã nguồn. Ví dụ: hàm này đặt tối thiểu 5 thực thể để giữ ấm:

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

@https_fn.on_call(min_instances=5)
def get_autocomplete_response(event: https_fn.CallableRequest) -> https_fn.Response:

Sau đây là một số điều cần cân nhắc khi đặt giá trị số thực thể tối thiểu:

• Nếu Cloud Functions for Firebase điều chỉnh ứng dụng của bạn vượt quá mức cài đặt, bạn sẽ gặp phải tình trạng khởi động nguội cho mỗi thực thể vượt quá ngưỡng đó.
• Khởi động nguội có ảnh hưởng nghiêm trọng nhất đến các ứng dụng có lưu lượng truy cập tăng đột biến. Nếu ứng dụng của bạn có lưu lượng truy cập tăng đột biến và bạn đặt giá trị đủ cao để giảm số lần khởi động nguội mỗi khi lưu lượng truy cập tăng, thì bạn sẽ thấy độ trễ giảm đáng kể. Đối với các ứng dụng có lưu lượng truy cập liên tục, khởi động nguội không có khả năng ảnh hưởng nghiêm trọng đến hiệu suất.

• Việc đặt số lượng thực thể tối thiểu có thể phù hợp với môi trường thực tế, nhưng thường nên tránh trong môi trường thử nghiệm. Để giảm về 0 trong dự án thử nghiệm nhưng vẫn giảm số lần khởi động nguội trong dự án phát hành công khai, bạn có thể đặt giá trị thực thể tối thiểu trong cấu hình có tham số:

  Node.js

  const { onRequest } = require('firebase-functions/https');
  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 = onRequest(
    { minInstances: minInstancesConfig },
  (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.")
  

Giới hạn số lượng thực thể tối đa cho một hàm

Bạn có thể đặt giá trị cho số thực thể tối đa trong mã nguồn của hàm. Ví dụ: hàm này đặt giới hạn là 100 thực thể để không làm quá tải một cơ sở dữ liệu cũ giả định:

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

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

@pubsub_fn.on_message_published(topic="topic-name", max_instances=100)
def mirrorevents(event: pubsub_fn.CloudEvent):
#  Connect to legacy database

Nếu một hàm HTTP được tăng quy mô đến giới hạn thực thể tối đa, thì các yêu cầu mới sẽ được đưa vào hàng đợi trong 30 giây rồi bị từ chối kèm theo mã phản hồi 429 Too Many Requests nếu không có thực thể nào hoạt động vào thời điểm đó.

Để tìm hiểu thêm về các phương pháp hay nhất khi sử dụng chế độ cài đặt số lượng thực thể tối đa, hãy xem các phương pháp hay nhất để đặt số lượng thực thể tối đa.

Thiết lập tài khoản dịch vụ

Tài khoản dịch vụ mặc định cho các hàm có một nhóm quyền rộng để cho phép bạn tương tác với các dịch vụ khác của Firebase và Google Cloud:

• Hàm thế hệ thứ 2: PROJECT_NUMBER-compute@developer.gserviceaccount.com (có tên là Tài khoản dịch vụ mặc định của Compute Engine)
• Hàm thế hệ thứ 1: PROJECT_ID@appspot.gserviceaccount.com (có tên là Tài khoản dịch vụ mặc định của App Engine)

Bạn nên ghi đè tài khoản dịch vụ mặc định và giới hạn một hàm ở các tài nguyên cần thiết. Bạn có thể thực hiện việc này bằng cách tạo một tài khoản dịch vụ tuỳ chỉnh và chỉ định tài khoản đó cho hàm thích hợp bằng cách sử dụng giá trị cấu hình serviceAccount:

const { onRequest } = require("firebase-functions/https");

exports.helloWorld = onRequest(
    {
        // This function doesn't access other Firebase project resources, so it uses a limited service account.
        serviceAccount:
            "my-limited-access-sa@", // or prefer the full form: "my-limited-access-sa@my-project.iam.gserviceaccount.com"
    },
    (request, response) => {
        response.send("Hello from Firebase!");
    },
);

Nếu muốn đặt cùng một tài khoản dịch vụ cho tất cả các hàm, bạn có thể thực hiện việc đó bằng hàm setGlobalOptions.

Đặt thời gian chờ và phân bổ bộ nhớ

Trong một số trường hợp, các hàm của bạn có thể có yêu cầu đặc biệt về giá trị thời gian chờ dài hoặc mức phân bổ bộ nhớ lớn. Bạn có thể đặt các giá trị này trong bảng điều khiển Google Cloud hoặc trong mã nguồn hàm (chỉ Firebase), sử dụng các giá trị thời gian chờ trong giới hạn thời lượng tối đa sau:

• Hàm HTTP và hàm có thể gọi: 3.600 giây (60 phút)
• Hàm theo lịch/hàng đợi tác vụ: 1.800 giây (30 phút)
• Các hàm khác dựa trên sự kiện: 540 giây (9 phút)

Để đặt mức phân bổ bộ nhớ và thời gian chờ trong mã nguồn của hàm, hãy sử dụng các tuỳ chọn chung cho bộ nhớ và số giây chờ để tuỳ chỉnh máy ảo chạy các hàm của bạn. Ví dụ: hàm Cloud Storage này sử dụng 1GiB bộ nhớ và hết thời gian chờ sau 300 giây:

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

@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.

Cách đặt mức phân bổ bộ nhớ và thời gian chờ trong bảng điều khiển Google Cloud:

1. Trong bảng điều khiển Google Cloud, hãy chọn Cloud Functions for Firebase trong trình đơn bên trái.
2. Chọn một hàm bằng cách nhấp vào tên hàm đó trong danh sách hàm.
3. Nhấp vào biểu tượng Chỉnh sửa trong trình đơn trên cùng.
4. Chọn một mức phân bổ bộ nhớ trong trình đơn thả xuống có nhãn Memory allocated (Bộ nhớ được phân bổ).
5. Nhấp vào Xem thêm để hiển thị các tuỳ chọn nâng cao, rồi nhập số giây vào hộp văn bản Thời gian chờ.
6. Nhấp vào Lưu để cập nhật hàm.

Ghi đè các giá trị mặc định của CPU

Bộ nhớ được phân bổ lên đến 2 GB, mỗi hàm trong Cloud Functions for Firebase (thế hệ thứ 2) mặc định là một CPU, sau đó tăng lên 2 CPU cho 4 và 8 GB. Xin lưu ý rằng điều này khác biệt đáng kể so với hành vi mặc định của thế hệ thứ 1 theo những cách có thể dẫn đến chi phí cao hơn một chút cho các hàm có bộ nhớ thấp như được trình bày trong bảng sau:

Nếu bạn muốn các hàm thế hệ thứ 2 hoạt động như thế hệ thứ 1, hãy đặt giá trị mặc định của thế hệ thứ 1 làm tuỳ chọn chung:

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

# Use 1st gen behavior
set_global_options(cpu="gcf_gen1")

Đối với các hàm cần nhiều CPU, thế hệ thứ 2 mang đến sự linh hoạt để định cấu hình thêm CPU. Bạn có thể tăng CPU cho từng hàm như sau:

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

# Boost CPU in a function:
@storage_fn.on_object_finalized(cpu=2)
def analyze_image(event: storage_fn.CloudEvent):
# computer vision goes here