Cloud Functions jest regionalna, co oznacza, że infrastruktura, która uruchamia Twoją funkcję, znajduje się w określonych regionach i jest zarządzana przez Google w taki sposób, aby była nadmiarowo dostępna we wszystkich strefach w tych regionach.
Wybierając regiony, w których mają być uruchamiane funkcje, należy przede wszystkim wziąć pod uwagę opóźnienie i dostępność. Zazwyczaj możesz wybrać regiony znajdujące się blisko Twoich 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 wielu regionach może wpłynąć na opóźnienie aplikacji, a także na ceny.
Domyślnie wiersz poleceń Firebase wdraża funkcje w regionie na podstawie konfiguracji projektu. W przypadku funkcji wywoływanych przez zdarzenia zwykle wdraża się je w regionie źródła danych wywołujących (np. w Cloud Firestorebazie danych lub Cloud Storagezasobniku), a w razie potrzeby w us-central1.
Po wdrożeniu możesz sprawdzić region w Firebase konsoli lub uruchamiając firebase functions:list. Jeśli chcesz, aby funkcja działała w innym regionie, możesz zmienić jej region.
Obsługiwane regiony
Na listach w tej sekcji ikona energy_savings_leaf oznacza, że energia elektryczna w tym regionie jest produkowana przy niskiej emisji dwutlenku węgla. Więcej informacji znajdziesz w artykule Energia bezemisyjna w regionach Google Cloud.
Ceny na poziomie 1
Cloud Functions jest dostępny w tych regionach w cenach na poziomie 1:
| Region | Lokalizacja | Obsługiwane wersje usługi | Emisje CO2 |
|---|---|---|---|
africa-south1 |
Johannesburg | Tylko 2 generacja | |
asia-east1 |
Tajwan | 1 generacja, 2 generacja | |
asia-east2 |
Hongkong | Tylko 1 generacja | |
asia-northeast1 |
Tokio | 1 generacja, 2 generacja | |
asia-northeast2 |
Osaka | 1 generacja, 2 generacja | |
europe-north1 |
Finlandia | Tylko 2 generacja | energy_savings_leaf |
europe-southwest1 |
Madryt | Tylko 2 generacja | |
europe-west1 |
Belgia | 1 generacja, 2 generacja | 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 generacja, 2 generacja | energy_savings_leaf |
us-east1 |
Karolina Południowa | 1 generacja, 2 generacja | |
us-east4 |
Północna Wirginia | 1 generacja, 2 generacja | |
us-east5 |
Columbus | Tylko 2 generacja | |
us-south1 |
Dallas | Tylko 2 generacja | |
us-west1 |
Oregon | 1 generacja, 2 generacja | energy_savings_leaf |
Cennik poziomu 2
Cloud Functions jest dostępny w tych regionach w cenach na poziomie 2:
| Region | Lokalizacja | Obsługiwane wersje usługi | Emisje CO2 |
|---|---|---|---|
asia-east2 |
Hongkong | Tylko 2 generacja | |
asia-northeast3 |
Seul | 1 generacja, 2 generacja | |
asia-southeast1 |
Singapur | 1 generacja, 2 generacja | |
asia-southeast2 |
Dżakarta | 1 generacja, 2 generacja | |
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 generacja, 2 generacja | |
europe-west2 |
Londyn | Tylko 2 generacja | |
europe-west3 |
Frankfurt | 1 generacja, 2 generacja | energy_savings_leaf |
europe-west6 |
Zurych | 1 generacja, 2 generacja | 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 generacja, 2 generacja | |
us-west3 |
Salt Lake City | 1 generacja, 2 generacja | |
us-west4 |
Las Vegas | 1 generacja, 2 generacja |
Funkcje w danym regionie w danym projekcie muszą mieć unikalne nazwy (bez rozróżniania wielkości liter), ale funkcje w różnych regionach lub w różnych projektach mogą mieć tę samą nazwę.
Sprawdzone metody określania regionu
Domyślnie wiersz poleceń Firebase wdraża funkcje w regionie na podstawie konfiguracji projektu. W przypadku funkcji wywoływanych przez zdarzenia zwykle wdraża się je w regionie źródła danych wywołujących (np. w Cloud Firestorebazie danych lub Cloud Storagezasobniku), a w razie potrzeby w us-central1.
Zalecamy ustawienie konkretnych regionów zamiast korzystania z domyślnych ustawień Firebase, które mogą się z czasem zmieniać. Podczas ustawiania regionów postępuj zgodnie z zaleceniami w tej sekcji dla każdego typu wyzwalacza.
Aby ustawić region, w którym ma działać funkcja, ustaw parametr region w definicji funkcji, jak pokazano poniżej:
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, przekazując w parametrze region kilka ciągów znaków regionu oddzielonych przecinkami. Pamiętaj też, że w przypadku wielu typów aktywatorów w tle musisz podać nie tylko region, ale też odpowiedni filtr zdarzeń. W przykładzie powyżej jest to Cloud Firestore document, które emituje zdarzenie. W przypadku reguły Cloud Storage filtr zdarzeń może mieć postać bucket, w przypadku reguły Pub/Sub – topic itd.
Więcej informacji o zmianie regionu funkcji obsługującej ruch produkcyjny znajdziesz w artykule Zmiana regionu funkcji.
Funkcje HTTP i funkcje wywoływane przez klienta
W przypadku funkcji HTTP i wywoływanych zalecamy najpierw ustawić funkcję w regionie docelowym lub w regionie najbliższym lokalizacji większości oczekiwanych klientów, a następnie zmodyfikować pierwotną funkcję, aby przekierowywała żądanie HTTP do nowej funkcji (mogą mieć tę samą nazwę). Jeśli klienci Twojej funkcji HTTP obsługują przekierowania, możesz po prostu zmienić pierwotną funkcję tak, aby zwracała stan przekierowania HTTP (301) wraz z adresem URL nowej funkcji. Jeśli Twoi klienci nie radzą sobie dobrze z przekierowaniami, możesz przekierować żądanie z pierwotnej funkcji do nowej, inicjując nowe żądanie z pierwotnej funkcji do nowej. Ostatnim krokiem jest upewnienie się, że wszystkie aplikacje klienckie wywołują nową funkcję.
Wybór lokalizacji po stronie klienta w przypadku funkcji wywoływanych
W przypadku funkcji wywoływalnej konfiguracje wywoływane przez klienta powinny być zgodne z tymi samymi wytycznymi co funkcje HTTP. Klient może też określić region. Powinien to zrobić, jeśli funkcja jest uruchamiana w regionie innym niż domyślny region projektu.
Aby ustawić regiony na kliencie, określ żądany region podczas inicjowania:
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 w tle
Funkcje w tle korzystają z semantyki dostarczania zdarzeń co najmniej raz, co oznacza, że w pewnych okolicznościach mogą otrzymywać zduplikowane zdarzenia. Dlatego warto zaimplementować funkcje, które są idempotentne. Jeśli funkcja jest już idempotentna, możesz wdrożyć ponownie funkcję w nowym regionie z tym samym aktywatorem zdarzeń i usunąć starą funkcję po sprawdzeniu, czy nowa funkcja prawidłowo odbiera ruch. Podczas tego przejścia obie funkcje będą otrzymywać zdarzenia. Aby poznać zalecaną kolejność poleceń do zmiany regionów funkcji, zobacz zmiana regionu funkcji.
Jeśli Twoja funkcja nie jest obecnie idempotentna lub jej idempotentność nie wykracza poza region, zalecamy najpierw wdrożenie idempotentności przed przeniesieniem funkcji.
Zalecenia dotyczące optymalnego regionu różnią się w zależności od typu aktywatora zdarzenia:
| Typ aktywatora | Rekomendacja regionu |
|---|---|
| Cloud Firestore | Region najbliższy Cloud Firestore lokalizacji instancji (patrz następna sekcja) |
| Realtime Database | Ten sam region co instancja Realtime Database |
| Cloud Storage | Region najbliższy lokalizacji zasobnika Cloud Storage (patrz następna sekcja) |
| Inne | Jeśli w funkcji korzystasz z instancji Realtime Database, instancji Cloud Firestore lub zasobnika Cloud Storage, zalecany region jest taki sam, jak w przypadku funkcji wywoływanej przez jeden z tych zasobów. Funkcje połączone z Firebase Hosting mogą znajdować się w dowolnym regionie, ale zalecenia znajdziesz w przeglądzie hostingu bezserwerowego. |
Wybieranie regionów na podstawie lokalizacji Cloud Firestore i Cloud Storage
Dostępne regiony dla funkcji nie zawsze dokładnie odpowiadają regionom dostępnym dla bazy danych Cloud Firestore i zasobników Cloud Storage.
Pamiętaj, że jeśli Twoja funkcja i zasób (instancja bazy danych lub Cloud Storagezasobnik) znajdują się w różnych lokalizacjach, czas oczekiwania i koszty mogą być większe.
Oto mapowanie najbliższych regionów obsługujących funkcje dla Cloud Firestore i Cloud Storage w przypadkach, gdy ten sam region nie jest obsługiwany:
| Region lub wiele regionów w przypadku 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 |