Ereignisgesteuerte Architekturen mit Eventarc erstellen

Mit Eventarc und Firestore zum Erstellen ereignisgesteuerte Architekturen Firestore-Trigger für Eventarc generieren Ereignisse aus Änderungen an bestimmten Dokumenten in Ihrer Datenbank. Der Trigger kann Ereignisse an ein unterstütztes Ziel weiterleiten:

Eventarc bietet eine standardisierte Lösung zur Verwaltung des Datenflusses Zustandsänderungen, sogenannte Ereignisse, zwischen entkoppelten Mikrodiensten. Bei Auslösung leitet Eventarc diese Ereignisse an verschiedene Ziele weiter und verwaltet dabei die Bereitstellung, Sicherheit, Autorisierung, Beobachtbarkeit und Fehlerbehandlung.

Beschränkungen

Beachten Sie die folgenden Einschränkungen für Firestore-Trigger für Eventarc:

  • Die Reihenfolge ist nicht garantiert. Schnelle Änderungen können Ereignisse in einer unerwarteten Reihenfolge auslösen.

  • Ereignisse werden mindestens einmal gesendet.

    Achten Sie darauf, dass Ihr Ereignis-Handler idempotent ist, und vermeiden Sie unerwartete Ergebnisse oder Nebenwirkungen, wenn ein Ereignis mehrmals gesendet wird. Weitere Informationen finden Sie unter Idempotente Funktionen erstellen.

  • Ein Trigger ist mit einer einzelnen Datenbank verknüpft. Sie können keinen Trigger erstellen, der mit mehreren Datenbanken übereinstimmt.

  • Wenn Sie eine Datenbank löschen, werden nicht automatisch die Trigger für diese Datenbank gelöscht. Der Trigger sendet keine Ereignisse mehr, bleibt aber bestehen, bis Sie ihn löschen. Wenn die Datenbank neu erstellt wird, müssen alle zugehörigen Trigger ebenfalls gelöscht und neu erstellt werden, um die Ereignisübermittlung wiederherzustellen.

Eventarc- und Firestore-Standorte

Eventarc unterstützt keine Mehrfachregionen für Firestore-Ereignistrigger. Sie können jedoch weiterhin Trigger für Firestore-Datenbanken an Standorten mit mehreren Regionen erstellen. In Eventarc werden Firestore-Standorte mit mehreren Regionen den folgenden Eventarc-Regionen zugeordnet:

Firestore (multiregional) Eventarc-Region
nam5 us-central1
eur3 europe-west4

Unterschiede zwischen Cloud Run-Funktionen der 2. Generation und der 1. Generation

Cloud Run-Funktionen (2. Generation) verwenden Eventarc-Ereignisse für alle Laufzeiten. Bisher haben Cloud Run-Funktionen (1. Generation) Eventarc-Ereignisse für nur einige Laufzeiten. Eventarc-Ereignisse unterscheiden sich von Cloud Run-Funktionen (1. Generation) in folgenden Punkten:

  • Die Firestore-Trigger für Eventarc unterstützen neben Cloud Run-Funktionen auch zusätzliche Ziele. Du kannst CloudEvents. mit einer Reihe von Zielen, darunter: aber nicht beschränkt auf Cloud Run, GKE und Workflows

  • Firestore-Trigger für Eventarc rufen die Triggerdefinition zu Beginn eines Datenbankschreibvorgangs um zu entscheiden, ob Firestore ein Ereignis ausgeben soll. Die Beim Schreibvorgang werden keine Änderungen an der Triggerdefinition berücksichtigt. was während der Ausführung passieren kann.

    Bei Cloud Run Functions (1. Generation) wird die Triggerdefinition während der Auswertung des Datenbankschreibens abgerufen. Änderungen am Trigger während der Auswertung können sich darauf auswirken, ob Firestore ein Ereignis ausgibt oder nicht.

Interoperabilität von Ereignissen im Datastore-Modus und im nativen Modus

Eventarc unterstützt Ereignistrigger sowohl für den Datastore-Modus als auch für den nativen Modus. Diese Ereignistrigger sind mit beiden Datenbanktypen interoperabel. Eine Firestore-Datenbank im nativen Modus kann Datastore-Ereignisse empfangen und eine Firestore-Datenbank im Datastore-Modus kann native Ereignisse empfangen.

Mit der Ereignisinteroperabilität können Sie Eventarc-Code für Firestore-Datenbanken verschiedener Typen freigeben.

Ereignis-Conversions

Wenn Sie einen Ereignistrigger im nativen Modus auf einen Datastore anwenden verwendet Eventarc folgende Conversions:

  • Der Namespace der Entität wird im Attribut PartitionId des Ereignisses gespeichert.
  • Eingebettete Entitäten werden in map-Typen des Native-Modus konvertiert.

Nächste Schritte