Cloud Functions-Standorte

Cloud Functions ist regional , was bedeutet, dass sich die Infrastruktur, die Ihre Cloud-Funktion ausführt, in bestimmten Regionen befindet und von Google so verwaltet wird, dass sie in allen Zonen innerhalb dieser Regionen redundant verfügbar ist.

Bei der Auswahl der Regionen, in denen Ihre Funktionen ausgeführt werden sollen, sollten Ihre Hauptüberlegungen Latenz und Verfügbarkeit sein. Sie können im Allgemeinen Regionen in der Nähe Ihrer Benutzer auswählen, aber Sie sollten auch den Standort der anderen Produkte und Dienste berücksichtigen, die Ihre App verwendet. Die Verwendung von Diensten in mehreren Regionen kann sich auf die Latenz Ihrer App sowie auf die Preise auswirken .

Unterstützte Regionen

In den Listen in diesem Abschnitt zeigt das Energiesparblatt- Symbol an, dass der Strom für diese Region mit geringen CO2-Emissionen produziert wird. Weitere Informationen finden Sie unter Kohlenstofffreie Energie für Google Cloud-Regionen .

Cloud Functions ist in den folgenden Regionen mit Tier-1-Preisen verfügbar:

• asia-east1 (Taiwan)
• asia-east2 (Hongkong)
• asia-northeast1 (Tokio)
• asia-northeast2 (Osaka)
• europe-west1 (Belgien) energy_savings_leaf
• europe-west2 (London)
• us-central1 (Iowa) energy_savings_leaf
• us-east1 (South Carolina)
• us-east4 (Nord-Virginia)
• us-west1 (Oregon) energy_savings_leaf

Cloud Functions ist in den folgenden Regionen mit Tier-2-Preisen verfügbar:

• asia-northeast3 (Seoul)
• asia-southeast1 (Singapur)
• asia-southeast2 (Jakarta)
• asia-south1 (Mumbai)
• australia-southeast1 (Sydney)
• europe-central2 (Warschau)
• europe-west3 (Frankfurt)
• europe-west6 (Zürich) energy_savings_leaf
• northamerica-northeast1 (Montreal) energy_savings_leaf
• southamerica-east1 (Sao Paulo) energy_savings_leaf
• us-west2 (Los Angeles)
• us-west3 (Salt Lake City)
• us-west4 (Las Vegas)

Funktionen in einer bestimmten Region in einem bestimmten Projekt müssen eindeutige Namen (ohne Berücksichtigung der Groß-/Kleinschreibung) haben, aber Funktionen in verschiedenen Regionen oder Projekten können denselben Namen haben.

Best Practices für den Regionswechsel

Standardmäßig werden Funktionen in der Region us-central1 ausgeführt. Beachten Sie, dass sich diese möglicherweise von der Region einer Ereignisquelle, z. B. einem Cloud Storage-Bucket, unterscheidet. Wenn Sie die Region ändern müssen, in der eine Funktion ausgeführt wird, befolgen Sie die Empfehlungen in diesem Abschnitt für jeden Funktionstriggertyp.

Um die Region festzulegen, in der eine Funktion ausgeführt wird, legen Sie den region Parameter in der Funktionsdefinition wie gezeigt fest:

exports.myStorageFunction = functions
    .region('europe-west1')
    .storage
    .object()
    .onFinalize((object) => {
      // ...
    });

Sie können mehrere Regionen angeben, indem Sie mehrere durch Kommas getrennte Regionszeichenfolgen in functions.region() übergeben. Weitere Informationen zu empfohlenen Verfahren finden Sie unter Ändern der Region einer Funktion .

HTTP und vom Client aufrufbare Funktionen

Für HTTP- und aufrufbare Funktionen empfehlen wir, dass Sie Ihre Funktion zuerst auf die Zielregion oder den Ort, an dem sich die meisten erwarteten Kunden befinden, einstellen und dann Ihre ursprüngliche Funktion ändern, um ihre HTTP-Anforderung an die neue Funktion umzuleiten (sie können dieselbe haben Name). Wenn Clients Ihrer HTTP-Funktion Umleitungen unterstützen, können Sie Ihre ursprüngliche Funktion einfach ändern, um einen HTTP-Umleitungsstatus (301) zusammen mit der URL Ihrer neuen Funktion zurückzugeben. Wenn Ihre Clients Umleitungen nicht gut handhaben, können Sie die Anfrage von der ursprünglichen Funktion an die neue Funktion weiterleiten , indem Sie eine neue Anfrage von der ursprünglichen Funktion an die neue Funktion initiieren. Der letzte Schritt besteht darin sicherzustellen, dass alle Clients die neue Funktion aufrufen.

Clientseitige Standortauswahl für aufrufbare Funktionen

In Bezug auf die aufrufbare Funktion sollten aufrufbare Client-Setups denselben Richtlinien folgen wie HTTP-Funktionen. Der Client kann auch eine Region angeben und muss dies tun, wenn die Funktion in einer anderen Region als us-central1 ausgeführt wird.

Um Regionen auf dem Client festzulegen, geben Sie die gewünschte Region bei der Initialisierung an:

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

Hintergrundfunktionen

Hintergrundfunktionen verwenden eine Ereignisübermittlungssemantik, die mindestens einmal erfolgt, was bedeutet, dass sie unter bestimmten Umständen doppelte Ereignisse empfangen können. Daher sollten Sie Funktionen implementieren, die idempotent sind. Wenn Ihre Funktion bereits idempotent ist, können Sie die Funktion in der neuen Region mit demselben Ereignisauslöser erneut bereitstellen und die alte Funktion entfernen, nachdem Sie überprüft haben, dass die neue Funktion Datenverkehr korrekt empfängt. Während dieses Übergangs empfangen beide Funktionen Ereignisse. Siehe Bereich einer Funktion ändern für die empfohlene Befehlsfolge zum Ändern von Bereichen für Funktionen.

Wenn Ihre Funktion derzeit nicht idempotent ist oder ihre Idempotenz nicht über die Region hinausreicht, empfehlen wir, dass Sie zuerst Idempotenz implementieren, bevor Sie die Funktion verschieben.

Die Empfehlungen für die optimale Region unterscheiden sich je nach Art des Ereignisauslösers:

Auswählen von Regionen basierend auf Cloud Firestore- und Cloud Storage-Standorten

Die verfügbaren Regionen für Funktionen stimmen nicht immer genau mit den Regionen überein, die für Ihre Cloud Firestore-Datenbank und Ihre Cloud Storage-Buckets verfügbar sind.

Beachten Sie, dass, wenn sich Ihre Funktion und Ihre Ressource (Datenbankinstanz oder Cloud Storage-Bucket) an unterschiedlichen Standorten befinden, möglicherweise erhöhte Latenz- und Abrechnungskosten auftreten .

Hier ist eine Zuordnung der nächstgelegenen funktionsunterstützten Regionen für Cloud Firestore und Cloud Storage für Fälle, in denen dieselbe Region nicht unterstützt wird: