Region Cloud Functions jest regionalny, co oznacza, że infrastruktura, w której działa funkcja, znajduje się w określonych regionach i jest zarządzana przez Google w celu zapewnienia nadmiarowości we wszystkich strefach w tych regionach.
Wybierając regiony, w których mają być wykonywane funkcje, należy przede wszystkim wziąć pod uwagę opóźnienie i dostępność. Zazwyczaj możesz wybrać regiony zlokalizowane blisko użytkowników, ale musisz też wziąć pod uwagę lokalizację innych produktów i usług, z których korzysta Twoja aplikacja. Korzystanie z usług w różnych regionach może wpływać na opóźnienia w aplikacji oraz na ceny.
Domyślnie funkcje są wykonywane w regionie us-central1. Pamiętaj, że może to być inny region niż region źródła zdarzenia, np. zasobnika Cloud Storage.
Jak określić region, w którym ma działać funkcja, dowiesz się dalej na tej stronie.
Obsługiwane regiony
Na listach w tej sekcji ikona energy_savings_leaf wskazuje, że energia elektryczna w danym regionie jest produkowana z niską emisją dwutlenku węgla. Więcej informacji znajdziesz w artykule Energetyka bezemisyjna w regionach Google Cloud.
Cennik poziomu 1
Usługa Cloud Functions jest dostępna w tych regionach w ramach ceny poziomu 1:
| Region | Lokalizacja | Obsługiwane wersje usługi | Emisja CO2 |
|---|---|---|---|
asia-east1 |
Tajwan | 1 generacji, 2 generacji | |
asia-east2 |
Hongkong | Tylko pierwsza generacja | |
asia-northeast1 |
Tokio | 1 generacji, 2 generacji | |
asia-northeast2 |
Osaka | 1 generacji, 2 generacji | |
europe-north1 |
Finlandia | Tylko 2 generacja | liść_oszczędności_energii |
europe-southwest1 |
Madryt | Tylko 2 generacja | |
europe-west1 |
Belgia | 1 generacji, 2 generacji | energy_savings_leaf |
europe-west4 |
Holandia | Tylko 2 generacja | |
europe-west8 |
Mediolan | Tylko 2 generacja | |
europe-west9 |
Paryż | Tylko 2 generacja | energy_savings_leaf |
me-west1 |
Tel Awiw | Tylko 2 generacja | |
europe-west2 |
Londyn | Tylko 1 generacja | |
us-central1 |
Iowa | 1 generacji, 2 generacji | liść_oszczędności_energii |
us-east1 |
Karolina Południowa | 1 generacji, 2 generacji | |
us-east4 |
Północna Wirginia | 1 generacji, 2 generacji | |
us-east5 |
Columbus | Tylko 2 generacja | |
us-south1 |
Dallas | Tylko 2 generacja | |
us-west1 |
Oregon | 1 generacji, 2 generacji | energy_savings_leaf |
Cennik poziomu 2
Cloud Functions jest dostępny w tych regionach w ramach poziomu 2 cen:
| Region | Lokalizacja | Obsługiwane wersje usługi | Emisja CO2 |
|---|---|---|---|
asia-east2 |
Hongkong | Tylko 2 generacja | |
asia-northeast3 |
Seul | 1 generacja, 2 generacja | |
asia-southeast1 |
Singapur | 1 generacji, 2 generacji | |
asia-southeast2 |
Dżakarta | 1 generacji, 2 generacji | |
asia-south1 |
Mumbaj | Tylko 2 generacja | |
asia-south2 |
Delhi, Indie | Tylko 2 generacja | |
australia-southeast1 |
Sydney | 1 generacja, 2 generacja | |
australia-southeast2 |
Melbourne | Tylko 2 generacja | |
europe-central2 |
Warszawa | 1 generacji, 2 generacji | |
europe-west2 |
Londyn | Tylko 2 generacja | |
europe-west3 |
Frankfurt | 1 generacji, 2 generacji | energy_savings_leaf |
europe-west6 |
Zurych | 1 generacji, 2 generacji | energy_savings_leaf |
europe-west10 |
Berlin | Tylko 2 generacja | |
europe-west12 |
Turyn | Tylko 2 generacja | |
me-central1 |
Doha | Tylko 2 generacja | |
me-central2 |
Dammam | Tylko 2 generacja | |
northamerica-northeast1 |
Montreal | 1 generacja, 2 generacja | energy_savings_leaf |
northamerica-northeast2 |
Toronto | Tylko 2 generacja | energy_savings_leaf |
southamerica-east1 |
Săo Paulo | 1 generacja, 2 generacja | energy_savings_leaf |
southamerica-west1 |
Santiago, Chile | Tylko 2 generacja | |
us-west2 |
Los Angeles | 1 generacji, 2 generacji | |
us-west3 |
Salt Lake City | 1 generacja, 2 generacja | |
us-west4 |
Las Vegas | 1 generacji, 2 generacji |
Funkcje w danym regionie w danym projekcie muszą mieć unikalne nazwy (niezależnie od wielkości liter), ale funkcje w różnych regionach lub projektach mogą mieć tę samą nazwę.
Sprawdzone metody określania regionu
Domyślnie funkcje są wykonywane w regionie us-central1. Pamiętaj, że może to być inny region niż region źródła zdarzenia, np. zasobnika Cloud Storage. Jeśli musisz określić region, w którym ma działać funkcja, postępuj zgodnie z zaleceniami w tej sekcji dla każdego typu funkcji.
Aby ustawić region, w którym ma działać funkcja, w definicji funkcji ustaw parametr region w ten sposób:
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
Możesz określić wiele regionów, podając w parametrze region wiele ciągów znaków oddzielonych przecinkami. Pamiętaj też, że podczas określania regionu dla wielu typów reguł działających w tle musisz podać odpowiedni filtr zdarzeń wraz z regionem. W przykładzie powyżej jest to Cloud Firestore document emitujący zdarzenie. W przypadku aktywatora Cloud Storage filtr zdarzeń może mieć wartość bucket, w przypadku aktywatora Pub/Sub – topic itd.
Więcej informacji o zmianie regionu funkcji obsługującej ruch produkcyjny znajdziesz w sekcji o zmienianiu regionu funkcji.
Funkcje wywoływane przez klienta i HTTP
W przypadku funkcji HTTP i funkcji wywoływalnych zalecamy najpierw ustawienie funkcji w regionie docelowym lub w najbliższym regionie docelowym, w którym znajduje się najwięcej klientów, a potem zmodyfikowanie pierwotnej funkcji w celu przekierowania jej żądania HTTP do nowej funkcji (mogą mieć one tę samą nazwę). Jeśli klienci Twojej funkcji HTTP obsługują przekierowania, możesz po prostu zmienić pierwotną funkcję, aby zwracała stan przekierowania HTTP (301) wraz z adresem URL nowej funkcji. Jeśli Twoi klienci nie radzą sobie z przekierowaniami, możesz przekazać żądanie z pierwotnej funkcji do nowej, inicjując nowe żądanie z pierwotnej funkcji do nowej. Ostatnim krokiem jest sprawdzenie, czy wszyscy klienci wywołują nową funkcję.
Wybór lokalizacji po stronie klienta dla funkcji wywoływalnych
W przypadku funkcji wywoływalnej konfiguracja wywołania przez klienta powinna być zgodna z wytycznymi dotyczącymi funkcji HTTP. Klient może też określić region i musi to zrobić, jeśli funkcja działa w regionie innym niż us-central1.
Aby ustawić regiony na kliencie, określ żądany region podczas inicjalizacji:
Swift
lazy var functions = Functions.functions(region:"europe-west1")
Objective-C
@property(strong, nonatomic) FIRFunctions *functions;
// ...
self.functions = [FIRFunctions functionsWithRegion:@"europe-west1"];
Sieć
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");
Funkcje działające w tle
Funkcje działające w tle korzystają z semantyki dostarczania zdarzeń co najmniej raz, co oznacza, że w pewnych okolicznościach mogą otrzymywać zduplikowane zdarzenia. Dlatego funkcje powinny być idempotentne. Jeśli funkcja jest już idempotentna, możesz ją ponownie wdrożyć w nowym regionie przy użyciu tego samego wyzwalacza zdarzenia i usunąć starą funkcję po potwierdzeniu, że nowa funkcja prawidłowo odbiera ruch. Podczas tej zmiany obie funkcje będą otrzymywać zdarzenia. Zapoznaj się z artykułem Zmiana regionu funkcji, aby poznać zalecaną sekwencję poleceń do zmiany regionów funkcji.
Jeśli funkcja nie jest obecnie idempotentna lub jej idempotentność nie wykracza poza region, przed jej przeniesieniem zalecamy wdrożenie idempotentności.
Rekomendacje dotyczące optymalnego regionu różnią się w zależności od typu reguły zdarzenia:
| Typ aktywatora | Rekomendacja regionu |
|---|---|
| Cloud Firestore | region najbliży lokalizacji instancji Cloud Firestore (patrz następna sekcja); |
| Realtime Database | Zawsze us-central1 |
| Cloud Storage | region najbliżej zasobnika Cloud Storage (patrz następna sekcja); |
| Inne | Jeśli wewnątrz funkcji nawiązujesz interakcję z instancją Realtime Database, Cloud Firestore lub zasobnikiem Cloud Storage, zalecany region jest taki sam, jak w przypadku funkcji wywołanej przez jeden z tych zasobów. W przeciwnym razie użyj domyślnego regionu us-central1.
Funkcje połączone z Firebase Hosting mogą działać w dowolnym regionie, ale zalecenia znajdziesz w opisie hostowania treści bezserwerowych. |
Wybieranie regionów na podstawie lokalizacji Cloud Firestore i Cloud Storage
Regiony dostępne dla funkcji nie zawsze dokładnie odpowiadają regionom dostępnym dla bazy danych Cloud Firestore i zasobów danych Cloud Storage.
Pamiętaj, że jeśli Twoja funkcja i zasób (instancja bazy danych lub zasobnik Cloud Storage) znajdują się w różnych lokalizacjach, czas oczekiwania i koszty mogą być większe.
Oto mapowanie regionów obsługiwanych przez Cloud Firestore i Cloud Storage w przypadku, gdy ten sam region jest nieobsługiwany:
| Region/wiele regionów dla: Cloud Firestore i Cloud Storage | Najbliższy region dla funkcji |
|---|---|
nam5 lub us-central (wiele regionów) |
us-central1 |
eur3 lub europe-west (wiele regionów) |
europe-west1 |
europe-west4 (Holandia) |
europe-west1 |
asia-south1 (Mumbaj) |
asia-east2 |
asia-south2 (Delhi) |
asia-east2 |
australia-southeast2 (Melbourne) |
australia-southeast1 |