Cloud Functions mang tính khu vực, nghĩa là cơ sở hạ tầng chạy chức năng của bạn được đặt ở những khu vực cụ thể và được Google quản lý để có thể sử dụng dự phòng trên tất cả các vùng thuộc những khu vực đó.
Khi lựa chọn khu vực để chạy các hàm, các yếu tố chính cần cân nhắc là độ trễ và khả năng hoạt động. Thường thì bạn có thể chọn các khu vực gần người dùng của mình, nhưng bạn cũng nên xem xét vị trí của các sản phẩm và dịch vụ khác mà ứng dụng sử dụng. Việc sử dụng các dịch vụ ở 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, các hàm chạy trong vùng us-central1. Xin lưu ý rằng khu vực này có thể khác với khu vực của nguồn sự kiện, chẳng hạn như bộ chứa Cloud Storage.
Hãy tìm hiểu cách chỉ định khu vực chạy một hàm ở phần sau của trang này.
Các 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 của khu vực này được sản xuất với lượng khí thải cacbon 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 trên Google Cloud.
Cloud Functions hiện được cung cấp ở những khu vực sau đây với mức giá Bậc 1:
asia-east1(Đài Loan)- Chỉ
asia-east2(Hong Kong) thế hệ 1 asia-northeast1(Tokyo)asia-northeast2(Osaka)europe-north1(Phần Lan) energy_savings_leaf chỉ dành cho thế hệ thứ 2europe-west1(Bỉ) energy_savings_leaf- Chỉ
europe-west2(London) thế hệ 1 us-central1(Iowa) energy_savings_leafus-east1(Nam Carolina)us-east4(Bắc Virginia)us-west1(Oregon) energy_savings_leaf
Cloud Functions hiện có ở những khu vực sau đây với giá của Cấp 2:
- Chỉ
asia-east2(Hong Kong) thế hệ thứ 2 asia-northeast3(Seoul)asia-southeast1(Singapore)asia-southeast2(Jakarta)- Chỉ
asia-south1(Mumbai) thế hệ thứ 2 australia-southeast1(Sydney)- Chỉ
australia-southeast2(Melbourne) thế hệ thứ 2 europe-central2(Waraw)- Chỉ
europe-west2(London) thế hệ thứ 2 europe-west3(Frankfurt)europe-west6(Zurich) energy_savings_leafnorthamerica-northeast1(Montreal) energy_savings_leafnorthamerica-northeast2(Toronto) energy_savings_leaf chỉ dành cho thế hệ thứ 2southamerica-east1(Sao Paulo) energy_savings_leaf- Chỉ dành cho thế hệ thứ 2 ở
southamerica-west1(San Diego, Chile) us-west2(Los Angeles)us-west3(Thành phố Salt Lake)us-west4(Las Vegas)
Các hàm ở một khu vực nhất định trong một dự án nhất định phải có tên duy nhất (không phân biệt chữ hoa chữ thường), nhưng các hàm trên các khu vực hoặc dự án có thể trùng tên.
Các phương pháp hay nhất để chỉ định khu vực
Theo mặc định, các hàm chạy trong vùng us-central1. Xin lưu ý rằng khu vực này có thể khác với khu vực của nguồn sự kiện, chẳng hạn như bộ chứa Cloud Storage. Nếu bạn cần chỉ định khu vực nơi một hàm chạy, 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 hàm.
Để đặt khu vực chạy một hàm, 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, lưu ý rằng khi chỉ định một khu vực cho nhiều loại điều kiện kích hoạt trong nền, bạn cần chỉ định đúng bộ lọc sự kiện cùng với khu vực đó. Trong ví dụ trên, đây là document của Cloud Firestore 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.
Xem bài viết thay đổi khu vực của hàm để biết thêm thông tin về cách thay đổi khu vực của hàm xử lý lưu lượng truy cập thực tế.
HTTP và các hàm có thể gọi của máy khách
Đối với HTTP và các hàm có thể gọi, trước tiên bạn nên đặt hàm thành khu vực đích hoặc gần nhất với vị trí của hầu hết khách hàng mong đợi, sau đó thay đổi hàm gốc để chuyển hướng yêu cầu HTTP đến hàm mới (có thể có cùng tên). Nếu ứng dụng khách của hàm HTTP của bạn hỗ trợ chuyển hướng, bạn chỉ cần thay đổi hàm gốc để 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 các lệnh chuyển hướng, bạn có thể proxy yêu cầu từ hàm gốc sang hàm mới bằng cách khởi tạo 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 khách đang 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
Về hàm có thể gọi, cách thiết lập chức năng có thể gọi của ứng dụng khách 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à phải làm như vậy nếu hàm chạy ở bất kỳ khu vực nào khác ngoài us-central1.
Để đặt vùng 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, có nghĩa là trong một số trường hợp, chúng 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 không thay đổi. Nếu hàm của bạn không ổn định, thì bạn có thể triển khai lại hàm này trong khu vực mới bằng cùng một điều kiện kích hoạt sự kiện và xoá hàm cũ sau khi xác minh rằng hàm mới nhận được lưu lượng truy cập 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. Xem bài viết thay đổi vùng của hàm để biết trình tự các 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 ổn định hoặc giá trị không vượt ra ngoài khu vực, thì trước tiên bạn nên triển khai giá trị không thay đổi trước khi di chuyển hàm.
Các đề xuất tối ưu về khu vực 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 về 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) |
| Cơ sở dữ liệu theo thời gian thực | Luôn là us-central1 |
| Cloud Storage | Khu vực gần nhất với vị trí bộ chứa trong 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ể của Cơ sở dữ liệu theo thời gian thực, thực thể của Cloud Firestore hoặc một bộ chứa Cloud Storage bên trong hàm, thì khu vực đề xuất sẽ giống như khi bạn có hàm được kích hoạt bởi một trong các tài nguyên đó. Nếu không, hãy sử dụng khu vực mặc định là us-central1.
Các hàm được kết nối với tính năng Lưu trữ Firebase có thể ở bất kỳ khu vực nào, nhưng hãy xem bài viết tổng quan về tính năng lưu trữ không máy chủ để biết nội dung đề xuất. |
Chọn các khu vực dựa trên vị trí trong Cloud Firestore và Cloud Storage
Khu vực có sẵn cho các 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 trong cơ sở dữ liệu Cloud Firestore và bộ chứa của bạn trong Cloud Storage.
Xin lưu ý rằng nếu hàm và tài nguyên của bạn (thực thể cơ sở dữ liệu hoặc bộ chứa Cloud Storage) nằm ở nhiều vị trí, thì bạn có thể gặp phải tình trạng tăng độ trễ và chi phí thanh toán.
Dưới đây là bản đồ liên kết các khu vực được hỗ trợ các chức năng gần nhất cho Cloud Firestore và Cloud Storage, trong trường hợp không hỗ trợ cùng một khu vực:
| Khu vực/đa 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 vùng) |
us-central1 |
eur3 hoặc europe-west (nhiều vùng) |
europe-west1 |
europe-west4 (Hà Lan) |
europe-west1 |
asia-south1 (Mumbai) |
asia-east2 |
asia-south2 (Delhi) |
asia-east2 |
australia-southeast2 (Melbourne) |
australia-southeast1 |