Vị trí Cloud Functions

Cloud Functions là theo khu vực, nghĩa là cơ sở hạ tầng chạy hàm của bạn nằm ở các khu vực cụ thể và do Google quản lý để có thể sử dụng nhiều hơn mức cần thiết trên tất cả các vùng trong những khu vực đó.

Khi chọn khu vực để chạy các hàm, bạn nên cân nhắc chủ yếu đến độ trễ và khả năng hoạt động. Thông thường, bạn có thể chọn các khu vực gần người dùng, nhưng cũng nên cân nhắc vị trí của các sản phẩm và dịch vụ khác mà ứng dụng của bạn sử dụng. Việc sử dụng dịch vụ trên nhiều khu vực có thể ảnh hưởng đến độ trễ của ứng dụng cũng như giá.

Theo mặc định, Giao diện dòng lệnh (CLI) của Firebase triển khai các hàm cho một khu vực dựa trên cấu hình của dự án. Đối với các hàm dựa trên sự kiện, hàm này thường triển khai đến một khu vực trong khu vực của nguồn dữ liệu kích hoạt (như cơ sở dữ liệu Cloud Firestore hoặc bộ chứa Cloud Storage) và triển khai đến us-central1 làm phương án dự phòng.

Sau khi triển khai, bạn có thể xác minh khu vực trong bảng điều khiển Firebase hoặc bằng cách chạy firebase functions:list. Nếu muốn hàm của mình chạy ở một khu vực khác, bạn có thể thay đổi khu vực của hàm.

Khu vực được hỗ trợ

Trong các danh sách ở phần này, biểu tượng energy_savings_leaf cho biết điện năng ở khu vực này được sản xuất với lượng khí thải carbon thấp. Để biết thêm thông tin, hãy xem bài viết Năng lượng không phát thải khí carbon cho các khu vực của Google Cloud.

Giá cấp 1

Cloud Functions có tại các khu vực sau với mức giá Bậc 1:

Vùng Vị trí Các phiên bản sản phẩm được hỗ trợ Lượng khí thải CO2
africa-south1 Johannesburg Chỉ thế hệ thứ 2
asia-east1 Đài Loan thế hệ thứ 1, thế hệ thứ 2
asia-east2 Hong Kong Chỉ thế hệ thứ 1
asia-northeast1 Tokyo thế hệ thứ 1, thế hệ thứ 2
asia-northeast2 Osaka thế hệ thứ 1, thế hệ thứ 2
europe-north1 Phần Lan Chỉ thế hệ thứ 2 energy_savings_leaf
europe-southwest1 Madrid Chỉ thế hệ thứ 2
europe-west1 Bỉ thế hệ thứ 1, thế hệ thứ 2 energy_savings_leaf
europe-west4 Hà Lan Chỉ thế hệ thứ 2
europe-west8 Milan Chỉ thế hệ thứ 2
europe-west9 Paris Chỉ thế hệ thứ 2 energy_savings_leaf
me-west1 Tel Aviv Chỉ thế hệ thứ 2
europe-west2 London Chỉ thế hệ thứ 1
us-central1 Iowa thế hệ thứ 1, thế hệ thứ 2 energy_savings_leaf
us-east1 South Carolina thế hệ thứ 1, thế hệ thứ 2
us-east4 Bắc Virginia thế hệ thứ 1, thế hệ thứ 2
us-east5 Columbus Chỉ thế hệ thứ 2
us-south1 Dallas Chỉ thế hệ thứ 2
us-west1 Oregon thế hệ thứ 1, thế hệ thứ 2 energy_savings_leaf

Giá cấp 2

Cloud Functions có tại các khu vực sau đây với mức giá Cấp 2:

Vùng Vị trí Các phiên bản sản phẩm được hỗ trợ Lượng khí thải CO2
asia-east2 Hong Kong Chỉ thế hệ thứ 2
asia-northeast3 Seoul thế hệ thứ 1, thế hệ thứ 2
asia-southeast1 Singapore thế hệ thứ 1, thế hệ thứ 2
asia-southeast2 Jakarta thế hệ thứ 1, thế hệ thứ 2
asia-south1 Mumbai Chỉ thế hệ thứ 2
asia-south2 Delhi, Ấn Độ Chỉ thế hệ thứ 2
australia-southeast1 Sydney thế hệ thứ 1, thế hệ thứ 2
australia-southeast2 Melbourne Chỉ thế hệ thứ 2
europe-central2 Warsaw thế hệ thứ 1, thế hệ thứ 2
europe-west2 London Chỉ thế hệ thứ 2
europe-west3 Frankfurt thế hệ thứ 1, thế hệ thứ 2 energy_savings_leaf
europe-west6 Zurich thế hệ thứ 1, thế hệ thứ 2 energy_savings_leaf
europe-west10 Berlin Chỉ thế hệ thứ 2
europe-west12 Turin Chỉ thế hệ thứ 2
me-central1 Doha Chỉ thế hệ thứ 2
me-central2 Dammam Chỉ thế hệ thứ 2
northamerica-northeast1 Montreal thế hệ thứ 1, thế hệ thứ 2 energy_savings_leaf
northamerica-northeast2 Toronto Chỉ thế hệ thứ 2 energy_savings_leaf
southamerica-east1 Sao Paulo thế hệ thứ 1, thế hệ thứ 2 energy_savings_leaf
southamerica-west1 Santiago, Chile Chỉ thế hệ thứ 2
us-west2 Los Angeles thế hệ thứ 1, thế hệ thứ 2
us-west3 Thành phố Salt Lake thế hệ thứ 1, thế hệ thứ 2
us-west4 Las Vegas thế hệ thứ 1, thế hệ thứ 2

Các hàm trong một khu vực nhất định trong một dự án nhất định phải có tên riêng biệt (không phân biệt chữ hoa chữ thường), nhưng các hàm trên nhiều khu vực hoặc trên nhiều dự án có thể có cùng tên.

Các phương pháp hay nhất để chỉ định khu vực

Theo mặc định, Giao diện dòng lệnh (CLI) của Firebase triển khai các hàm cho một khu vực dựa trên cấu hình của dự án. Đối với các hàm dựa trên sự kiện, hàm này thường triển khai đến một khu vực trong khu vực của nguồn dữ liệu kích hoạt (như cơ sở dữ liệu Cloud Firestore hoặc bộ chứa Cloud Storage) và triển khai đến us-central1 làm phương án dự phòng.

Bạn nên đặt các khu vực cụ thể thay vì dựa vào chế độ mặc định của Firebase, vì chế độ này có thể thay đổi theo thời gian. Khi đặt vùng, hãy làm theo các đề xuất trong phần này cho từng loại điều kiện kích hoạt

Để đặt khu vực nơi hàm chạy, hãy đặt tham số region trong định nghĩa hàm như sau:

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

Bạn có thể chỉ định nhiều khu vực bằng cách truyền nhiều chuỗi khu vực được phân tách bằng dấu phẩy trong region. Ngoài ra, xin lưu ý rằng khi chỉ định một khu vực cho nhiều loại trình kích hoạt trong nền, bạn cần chỉ định bộ lọc sự kiện chính xác cùng với khu vực đó. Trong ví dụ trên, đây là Cloud Firestore document phát ra sự kiện. Đối với điều kiện kích hoạt Cloud Storage, bộ lọc sự kiện có thể là bucket; đối với điều kiện kích hoạt Pub/Sub, bộ lọc sự kiện sẽ là topic, v.v.

Hãy xem phần thay đổi khu vực của hàm để biết thêm thông tin về cách thay đổi khu vực cho một hàm đang xử lý lưu lượng truy cập thực tế.

Hàm HTTP và hàm có thể gọi từ máy khách

Đối với các hàm HTTP và hàm có thể gọi, bạn nên đặt hàm của mình thành khu vực đích hoặc gần nhất với nơi có hầu hết khách hàng dự kiến, sau đó thay đổi hàm ban đầu để chuyển hướng yêu cầu HTTP của hàm đó đến hàm mới (chúng có thể có cùng tên). Nếu ứng dụng khách của hàm HTTP hỗ trợ lệnh chuyển hướng, bạn chỉ cần thay đổi hàm ban đầu để trả về trạng thái chuyển hướng HTTP (301) cùng với URL của hàm mới. Nếu ứng dụng của bạn không xử lý tốt lệnh chuyển hướng, bạn có thể uỷ quyền yêu cầu từ hàm ban đầu sang hàm mới bằng cách bắt đầu một yêu cầu mới từ hàm ban đầu sang hàm mới. Bước cuối cùng là đảm bảo rằng tất cả ứng dụng đều gọi hàm mới.

Lựa chọn vị trí phía máy khách cho các hàm có thể gọi

Đối với hàm có thể gọi, các chế độ thiết lập có thể gọi của ứng dụng phải tuân theo các nguyên tắc giống như hàm HTTP. Ứng dụng cũng có thể chỉ định một khu vực và nên làm như vậy nếu hàm chạy ở một khu vực khác với khu vực mặc định của dự án.

Để đặt khu vực trên ứng dụng, hãy chỉ định khu vực mong muốn khi khởi chạy:

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

Hàm nền

Hàm nền áp dụng ngữ nghĩa phân phối sự kiện ít nhất một lần, nghĩa là trong một số trường hợp, hàm nền có thể nhận được các sự kiện trùng lặp. Vì vậy, bạn nên triển khai các hàm có tính idempotent (bất biến). Nếu hàm của bạn đã có tính chất luỹ đẳng, thì bạn có thể triển khai lại hàm đó trong khu vực mới bằng cùng một trình kích hoạt sự kiện và xoá hàm cũ sau khi xác minh rằng hàm mới đang nhận lưu lượng truy cập một cách chính xác. Trong quá trình chuyển đổi này, cả hai hàm đều sẽ nhận được sự kiện. Hãy xem phần thay đổi khu vực của hàm để biết trình tự lệnh được đề xuất nhằm thay đổi khu vực cho các hàm.

Nếu hàm của bạn hiện không có tính luỹ đẳng hoặc tính luỹ đẳng của hàm không vượt ra ngoài khu vực, thì bạn nên triển khai tính luỹ đẳng trước khi di chuyển hàm.

Đề xuất về khu vực tối ưu sẽ khác nhau tuỳ theo loại điều kiện kích hoạt sự kiện:

Loại trình kích hoạt Đề xuất khu vực
Cloud Firestore Khu vực gần nhất với vị trí của thực thể Cloud Firestore (xem phần tiếp theo)
Realtime Database Cùng khu vực với thực thể Realtime Database
Cloud Storage Khu vực gần nhất với vị trí bộ chứa Cloud Storage (xem phần tiếp theo)
Thiết bị khác Nếu bạn đang tương tác với một thực thể Realtime Database, một thực thể Cloud Firestore hoặc một bộ chứa Cloud Storage bên trong hàm, thì khu vực được đề xuất sẽ giống như khi bạn có một hàm được kích hoạt bởi một trong các tài nguyên đó. Các hàm được kết nối với Firebase Hosting có thể nằm ở bất kỳ khu vực nào, nhưng hãy xem tổng quan về dịch vụ lưu trữ không máy chủ để biết các đề xuất.

Chọn khu vực dựa trên vị trí của Cloud Firestore và Cloud Storage

Các khu vực có sẵn cho hàm không phải lúc nào cũng khớp chính xác với các khu vực có sẵn cho cơ sở dữ liệu Cloud Firestore và bộ chứa Cloud Storage của bạn.

Xin lưu ý rằng nếu hàm và tài nguyên (thực thể cơ sở dữ liệu hoặc Cloud Storagevùng lưu trữ) nằm ở các vị trí khác nhau, thì bạn có thể gặp phải tình trạng độ trễ tăng lên và chi phí được lập hoá đơn.

Dưới đây là thông tin liên kết các khu vực được hỗ trợ gần nhất cho Cloud Firestore và Cloud Storage, trong trường hợp cùng một khu vực không được hỗ trợ:

Khu vực/Nhiều khu vực cho Cloud Firestore và Cloud Storage Khu vực gần nhất cho các hàm
nam5 hoặc us-central (nhiều khu vực) us-central1
eur3 hoặc europe-west (nhiều khu vực) europe-west1
europe-west4 (Hà Lan) europe-west1
asia-south1 (Mumbai) asia-east2
asia-south2 (Delhi) asia-east2
australia-southeast2 (Melbourne) australia-southeast1