Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Ereignisgesteuerte Architekturen mit Eventarc erstellen
Mit Eventarc und Firestore können Sie ereignisgesteuerte Architekturen erstellen.
Firestore-Trigger für Eventarc generieren Ereignisse aus Änderungen an einem bestimmten Dokument in Ihrer Datenbank. Der Trigger kann Ereignisse an ein unterstütztes Ziel weiterleiten:
Eventarc bietet eine standardisierte Lösung, um den Ablauf der Statusänderungen, die sogenannten Ereignisse, zwischen entkoppelten Mikrodiensten zu verwalten. 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 unvorhergesehenen Reihenfolge auslösen.
Ereignisse werden mindestens einmal übermittelt.
Achten Sie darauf, dass Ihr Event-Handler idempotent ist, und vermeiden Sie unerwartete Ergebnisse oder Nebeneffekte, wenn ein Ereignis mehrmals bereitgestellt 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 keine Trigger für diese Datenbank automatisch 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 Multi-Regionen für Firestore-Ereignistrigger im nativen Modus. Sie können aber weiterhin Trigger für Firestore-Datenbanken an Standorten mit mehreren Regionen erstellen. Eventarc ordnet Firestore-Mehrfachregionsstandorte den folgenden Eventarc-Regionen zu:
Firestore multiregional
Eventarc-Region
nam5
us-central1
eur3
europe-west4
Unterschiede zwischen Cloud Run-Funktionen der 2. und 1. Generation
Cloud Run-Funktionen (2. Generation) verwenden Eventarc-Ereignisse für alle Laufzeiten.
Bisher wurden in Cloud Run-Funktionen (1. Generation) Eventarc-Ereignisse nur für einige Laufzeiten verwendet.
Eventarc-Ereignisse weisen die folgenden Unterschiede zu Cloud Run-Funktionen (1. Generation) auf.
Die Firestore-Trigger für Eventarc unterstützen neben Cloud Run-Funktionen auch zusätzliche Ziele. Sie können CloudEvents an eine Reihe von Zielen weiterleiten, darunter Cloud Run, GKE und Workflows.
Firestore-Trigger für Eventarc rufen die Triggerdefinition zu Beginn eines Datenbankschreibvorgangs ab und verwenden diese Definition, um zu entscheiden, ob Firestore ein Ereignis ausgeben soll. Bei der Schreiboperation werden keine Änderungen an der Triggerdefinition berücksichtigt, die während der Ausführung auftreten.
Cloud Run Functions (1. Generation) ruft die Triggerdefinition während der Auswertung des Datenbankschreibvorgangs ab. Ä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 kompatibel.
Eine Firestore-Datenbank im nativen Modus kann Datastore-Ereignisse empfangen und eine Firestore-Datenbank im Datastore-Modus kann Ereignisse im nativen Modus empfangen.
Mit der Ereignisinteroperabilität können Sie Eventarc-Code für verschiedene Arten von Firestore-Datenbanken freigeben.
Event-Conversions
Wenn Sie einen Ereignistrigger im nativen Modus auf eine Datenbank im Datastore-Modus anwenden, führt Eventarc die folgenden Konvertierungen durch:
Der Namespace der Entität wird im Attribut PartitionId des Ereignisses gespeichert.
Eingebettete Entitäten werden in map-Typen im nativen Modus konvertiert.
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2025-08-25 (UTC)."],[],[],null,["# Create event-driven architectures with Eventarc\n===============================================\n\nYou can use [Eventarc](/eventarc/docs/overview) and\nFirestore to build\n[event-driven architectures](/eventarc/docs/event-driven-architectures).\nFirestore triggers for\nEventarc generate events from changes\nto a particular documents in your database. The trigger can route events to a\n[supported destination](/eventarc/docs/event-providers-targets):\n\n- Cloud Run functions (2nd gen) which supports the [Cloud Client Libraries](/firestore/docs/extend-with-functions-2nd-gen) and the [Firebase SDK](https://firebase.google.com/docs/firestore/extend-with-functions-2nd-gen)\n- [Cloud Run](/eventarc/docs/run/route-trigger-cloud-firestore)\n- [Google Kubernetes Engine](/eventarc/docs/gke/route-trigger-cloud-firestore)\n- [Workflows](/eventarc/docs/workflows/route-trigger-cloud-firestore)\n\nEventarc offers a standardized solution to manage the flow of\nstate changes, called *events*, between decoupled microservices. When triggered,\nEventarc routes these events to\nvarious destinations while managing delivery, security, authorization,\nobservability, and error-handling for you.\n| **Note:** Eventarc events use the [`CloudEvents`](https://cloudevents.io/) specification.\n\nLimitations\n-----------\n\nNote the following limitations for Firestore triggers for\nEventarc:\n\n- Ordering is not guaranteed. Rapid changes can trigger events in an unexpected order.\n- Events are delivered *at least* once.\n\n Make sure your event handler is idempotent and avoid producing unexpected results\n or side effects when an event is delivered more than once. Refer to\n [Building idempotent functions](https://cloud.google.com/blog/products/serverless/cloud-functions-pro-tips-building-idempotent-functions) to learn more.\n- A trigger is associated with a single database. You cannot create a trigger that matches multiple databases.\n\n- Deleting a database does not automatically delete any triggers for that database. The\n trigger stops delivering events but continues to exist until you [delete the trigger](/eventarc/docs/managing-triggers#trigger-delete). If the database is recreated, any associated triggers will also need to be deleted and recreated to restore event delivery.\n\nEventarc and Firestore locations\n--------------------------------\n\nEventarc does not support multi-regions for Firestore in Native Mode event\ntriggers, but you can still create triggers for Firestore databases\nin multi-region locations. Eventarc maps Firestore\nmulti-region locations to the following Eventarc regions:\n\nDifferences between Cloud Run functions 2nd gen and 1st gen\n-----------------------------------------------------------\n\nCloud Run functions (2nd gen) uses Eventarc events for all runtimes.\nPreviously, Cloud Run functions (1st gen) used Eventarc events for\n[only some runtimes](/functions/docs/writing/write-event-driven-functions).\nEventarc events introduce the following differences from\n[Cloud Run functions (1st gen)](/firestore/docs/extend-with-functions).\n\n- The Firestore triggers for Eventarc support\n additional destinations besides Cloud Run functions. You can route `CloudEvents`\n to a number of [destinations](/eventarc/docs/event-providers-targets) including,\n but not limited to Cloud Run, GKE, and\n Workflows.\n\n- Firestore triggers for Eventarc retrieve the\n trigger definition at the start of a database write operation and uses\n that definition to decide if Firestore should emit an event. The\n write operation does not take into account any changes to trigger definition\n that might happen as it runs.\n\n Cloud Run functions (1st gen) retrieves the trigger definition during the\n evaluation of the database write, and changes to the trigger during\n evaluation can affect if Firestore emits an event or not.\n\nDatastore mode and Native mode event interoperability\n-----------------------------------------------------\n\nEventarc supports event triggers for both Datastore mode and Native\nmode. These event triggers are interoperable with both database types.\nA Firestore in Native mode database can receive Datastore\nevents, and a Firestore in Datastore mode database can receive\nNative mode events.\n\nEvent interoperability lets you share Eventarc code across\nFirestore databases of different types.\n\n### Event conversions\n\nIf you apply a Native mode event trigger to a Datastore\nmode database, Eventarc makes the following conversions:\n\n- The namespace of the entity is stored in the event's `PartitionId` attribute.\n- Embedded entities are converted to Native mode `map` types.\n\nWhat's next\n-----------\n\n- Learn about [event-driven architectures](/eventarc/docs/event-driven-architectures)."]]
