Lokalizacje Cloud Functions

Cloud Functions jest regionalnym, co oznacza, że infrastruktura, w której działa Twój funkcja znajduje się w określonych regionach i jest zarządzana przez Google, nadmiarowo dostępne na we wszystkich strefach w tych regionach.

Wybierając regiony, w których mają działać funkcje, podstawą należy uwzględnić czas oczekiwania i dostępność. Dostępne opcje zwykle wybieramy regiony blisko Twoich użytkowników, ale również należy wziąć pod uwagę lokalizację inne produkty i usługi z których korzysta Twoja aplikacja. Korzystanie z usług w wielu regionach może mieć wpływ czas oczekiwania aplikacji oraz cenę.

Domyślnie funkcje są uruchamiane w regionie us-central1. Pamiętaj, że może to być inny niż region źródła zdarzeń, takiego jak zasobnik Cloud Storage. Dowiedz się, jak określ region, w którym działa funkcja później na tej stronie.

Obsługiwane regiony

Na listach w tej sekcji liść_oszczędności_energii wskazuje, że energia elektryczna w tym regionie jest wytwarzana niskiej emisji dwutlenku węgla. Więcej informacji: Bezemisyjna energia dla regionów Google Cloud.

Usługa Cloud Functions jest dostępna w tych regionach, w których Ceny poziomu 1:

• asia-east1 (Tajwan)
• asia-east2 (Hongkong) tylko 1 generacji
• asia-northeast1 (Tokio)
• asia-northeast2 (Osaka)
• europe-north1 (Finlandia) liść_oszczędności_energii Tylko 2 generacja
• europe-west1 (Belgia) liść_oszczędności_energii
• europe-west2 (Londyn) Tylko 1 generacji
• us-central1 (Iowa) liść_oszczędności_energii
• us-east1 (Karolina Południowa)
• us-east4 (Wirginia Północna)
• us-west1 (Orgon) liść_oszczędności_energii

Usługa Cloud Functions jest dostępna w tych regionach, w których Ceny poziomu 2:

• asia-east2 (Hongkong) tylko 2 generacji
• asia-northeast3 (Seul)
• asia-southeast1 (Singapur)
• asia-southeast2 (Dżakarta)
• asia-south1 (Mumbaj) Tylko 2 generacji
• australia-southeast1 (Sydney)
• australia-southeast2 (Melbourne) tylko 2 generacji
• europe-central2 (Warszawa)
• europe-west2 (Londyn) Tylko 2 generacji
• europe-west3 (Frankfurt)
• europe-west6 (Zurych) liść_oszczędności_energii
• northamerica-northeast1 (Montreal) liść_oszczędności_energii
• northamerica-northeast2 (Toronto) liść_oszczędności_energii Tylko 2 generacja
• southamerica-east1 (São Paulo) liść_oszczędności_energii
• southamerica-west1 (Santiago, Chile) tylko 2 generacji
• us-west2 (Los Angeles)
• us-west3 (Salt Lake City)
• us-west4 (Las Vegas)

Funkcje w danym regionie w projekcie muszą mieć unikalne (przypadek niewrażliwe), ale funkcje w różnych regionach lub projektach mogą mieć takie same o tej samej nazwie.

Sprawdzone metody określania regionu

Domyślnie funkcje są uruchamiane w regionie us-central1. Pamiętaj, że może to być inny niż region źródła zdarzeń, takiego jak zasobnik Cloud Storage. Jeśli musisz podać region, w którym działa funkcja, postępuj zgodnie z zalecenia w tej sekcji dla każdego typu aktywatora funkcji.

Aby określić region, w którym działa funkcja, ustaw parametr region w sekcji jak poniżej:

exports.firestoreAsia = 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

Możesz podać wiele regionów, rozdzielając je przecinkami ciągi w argumencie region. Pamiętaj również, że przy określaniu regionu dla wielu typów reguł działających w tle, musisz określić odpowiedni filtr zdarzeń. wraz z regionem. W przykładzie powyżej jest to Cloud Firestore document emitujące zdarzenie. W przypadku reguły Cloud Storage włącz filtr zdarzeń może wynosić bucket; dla aktywatora Pub/Sub będzie to topic itd.

Zobacz zmień region funkcji , aby dowiedzieć się więcej o zmianie regionu dla funkcji, która obsługuje w przypadku ruchu produkcyjnego.

Funkcje HTTP i możliwe do wywołania przez klienta

W przypadku funkcji HTTP i wywoływanych zalecamy najpierw ustawienie jej na region docelowy lub obszar położony w pobliżu miejsca, w którym znajduje się najwięcej spodziewanych klientów, a potem zmień pierwotną funkcję, by przekierowywała żądanie HTTP do nowej (mogą mieć tę samą nazwę). Jeśli klienty funkcji HTTP obsługują możesz zmienić pierwotną funkcję, tak by zwracała ona kod HTTP stan przekierowania (301) wraz z adresem URL nowej funkcji. Jeśli Twoi klienci gdy nie radzą sobie dobrze z przekierowaniami, możesz proxy do nowej funkcji przez zainicjowanie nowego żądania do nowej funkcji. Ostatnim krokiem jest sprawdzenie, czy wszyscy klienci wywołając nową funkcję.

Wybór lokalizacji po stronie klienta na potrzeby funkcji z możliwością wywoływania

W przypadku funkcji wywoływanej przez klienta konfiguracje możliwe do wywołania powinny być takie same jak w przypadku funkcji HTTP. Klient może także określić region musisz zrobić to, jeśli funkcja działa w regionie innym niż us-central1.

Aby ustawić regionów na kliencie określ żądany region podczas inicjowania:

lazy var functions = Functions.functions(region:"europe-west1")

@property(strong, nonatomic) FIRFunctions *functions;
// ...
self.functions = [FIRFunctions functionsWithRegion:@"europe-west1"];

var functions = firebase.app().functions('europe-west1');

private FirebaseFunctions mFunctions;
// ...
mFunctions = FirebaseFunctions.getInstance("europe-west1");

firebase::functions::Functions* functions;
// ...
functions = firebase::functions::Functions::GetInstance("europe-west1");

firebase.Functions.FirebaseFunctions functions;

functions = Firebase.Functions.FirebaseFunctions.GetInstance("europe-west1");

Funkcje działające w tle

Funkcje działające w tle przyjmują semantykę realizacji zdarzenia co najmniej raz, co oznacza, że że w pewnych okolicznościach mogą one odnotować zduplikowane zdarzenia. Zalecamy zaimplementuj funkcje, które będą idempotent. Jeśli Twoja funkcja jest już idempotentny, możesz ponownie wdrożyć tę funkcję w nowym regionie za pomocą tę samą regułę zdarzeń, a następnie usunąć starą funkcję po sprawdzeniu, czy nowa funkcja prawidłowo odbiera ruch. W trakcie tego przejścia funkcje będą odbierać zdarzenia. Zobacz zmień region funkcji dla zalecanej sekwencji poleceń do zmiany regionów funkcji.

Jeśli funkcja nie jest obecnie idempotentna lub jej idempotentność nie wykraczać poza region, zalecamy więc najpierw idempotentnością przed przeniesieniem funkcji.

Rekomendacje dotyczące optymalnego regionu różnią się w zależności od typu reguły zdarzenia:

Wybieram regiony na podstawie lokalizacji: Cloud Firestore i Cloud Storage

Dostępne regiony dla funkcji nie zawsze są dokładnie takie same jak regiony dostępne w bazie danych Cloud Firestore i Cloud Storage zasobników.

Pamiętaj, że jeśli Twoja funkcja i Twój zasób (instancja bazy danych lub Cloud Storage) zasobnika) znajdują się w różnych lokalizacjach, istnieje ryzyko, i zwiększenie czasu oczekiwania kosztów rozliczeń.

Oto mapowanie najbliższych regionów obsługujących funkcje w: Cloud Firestore i Cloud Storage, jeśli ten sam region nie jest obsługiwany: