Mit Eventarc können Sie ereignisgesteuerte Architekturen erstellen, ohne die zugrunde liegende Infrastruktur implementieren, anpassen oder verwalten zu müssen. Es bietet eine standardisierte Lösung, um den Ablauf der Statusänderungen, die sogenannten Ereignisse, zwischen entkoppelten Mikrodiensten zu verwalten. Eventarc leitet diese Ereignisse bei Auslösung an verschiedene Ziele weiter (in diesem Dokument finden Sie weitere Informationen unter Ereignisziele) und verwaltet dabei die Bereitstellung, Sicherheit, Autorisierung, Beobachtbarkeit und Fehlerbehandlung.
Sie können Eventarc über die Google Cloud Console, über die Befehlszeile mit der glcoud CLI oder über die Eventarc API verwalten.
Eventarc entspricht diesen Zertifizierungen und Standards.
1 Ereignisse von Google-Anbietern werden entweder direkt aus der Quelle (z. B. Cloud Storage) oder über Cloud-Audit-Logeinträge gesendet und verwenden Pub/Sub als Transportebene. Ereignisse aus Pub/Sub-Quellen können ein vorhandenes Pub/Sub-Thema verwenden oder Eventarc erstellt automatisch ein Thema und verwaltet es für Sie.
2 Ereignisse für Google Kubernetes Engine-Ziele (GKE), einschließlich Knative-Serving-Dienste, die in einem GKE-Cluster ausgeführt werden, verwenden die Ereignisweiterleitung von Eventarc, um neue Ereignisse aus Pub/Sub abzurufen und an das Ziel weiterzuleiten. Diese Komponente fungiert als Vermittler zwischen der Pub/Sub-Transportebene und dem Zieldienst. Es funktioniert mit vorhandenen Diensten und unterstützt auch Signalisierungsdienste (einschließlich Dienste, die nicht außerhalb des vollständig verwalteten Clusters verfügbar sind), während die Einrichtung und Wartung vereinfacht wird. Der Lebenszyklus des Ereignis-Forwarders wird von Eventarc verwaltet. Wenn Sie den Ereignis-Forwarder versehentlich löschen, wird diese Komponente von Eventarc wiederhergestellt.
3 Ereignisse für eine Workflowausführung werden transformiert und als Laufzeitargumente an den Workflow übergeben. Workflows können Google Cloud- und HTTP-basierte API-Dienste in einer von Ihnen definierten Reihenfolge kombinieren und orchestrieren.
4 Alle ereignisgesteuerten Funktionen in Cloud Run-Funktionen (2. Generation) verwenden Eventarc-Trigger, um Ereignisse bereitzustellen. Sie können Eventarc-Trigger konfigurieren, wenn Sie eine Cloud Run-Funktion über die Cloud Run-Funktionsoberfläche bereitstellen.
Gängige Anwendungsfälle
Eventarc unterstützt viele Anwendungsfälle für Zielanwendungen. Dazu einige Beispiele:
| Konfigurieren und Monitoring |
|
| Optimieren |
|
| Analysieren |
|
Ereignisse
Ein Ereignis ist ein Datensatz, der ein Vorkommen und seinen Kontext wiedergibt. Ein Ereignis ist eine von allen anderen Ereignissen unabhängige Kommunikationseinheit. Ein Ereignis kann z. B. eine Änderung von Daten in einer Datenbank, eine zu einem Speichersystem hinzugefügte Datei oder ein geplanter Auftrag sein.
Siehe Von Eventarc unterstützte Ereignistypen.
Ereignisanbieter
Ereignisse werden von einem Ereignisersteller (der Quelle) an interessierte Ereignisnutzer weitergeleitet. Das Routing wird auf der Grundlage der im Ereignis enthaltenen Informationen durchgeführt, aber ein Ereignis identifiziert kein bestimmtes Routing-Ziel. Derzeit unterstützt Eventarc Ereignisse aus den folgenden Quellen:
- Mehr als 130 Google Cloud-Anbieter: Diese Anbieter senden Ereignisse (z. B. eine Aktualisierung eines Objekts in einem Cloud Storage-Bucket oder eine in einem Pub/Sub-Thema veröffentlichte Nachricht) direkt aus der Quelle oder über Cloud-Audit-Logeinträge.
- Drittanbieter. Diese Anbieter senden Ereignisse direkt aus der Quelle (z. B. von SaaS-Drittanbietern wie Datadog oder der Check Point CloudGuard-Plattform).
Ereignisziele
Ereignisse werden über ein Pub/Sub-Push-Abo an ein bestimmtes Ziel weitergeleitet, das als Ereignisempfänger (oder Nutzer) bezeichnet wird.
Cloud Run-Funktionen (2. Generation)
Alle ereignisgesteuerten Funktionen in Cloud Run-Funktionen (2. Generation) verwenden Eventarc-Trigger, um Ereignisse bereitzustellen. Mit einem Eventarc-Trigger kann eine Funktion von jedem von Eventarc unterstützten Ereignistyp ausgelöst werden. Sie können Eventarc-Trigger konfigurieren, wenn Sie eine Cloud Run-Funktion über die Cloud Run-Funktionsoberfläche bereitstellen.
Cloud Run
Erfahren Sie, wie Sie einen Ereignisempfängerdienst erstellen, der in Cloud Run bereitgestellt werden kann.
Informationen zum Weiterleiten von Ereignissen an einen Cloud Run-Dienst finden Sie unter Optionen für die Ereignisweiterleitung.
GKE
Eventarc unterstützt das Erstellen von Triggern für GKE-Dienste (Google Kubernetes Engine). Dazu gehören die öffentlichen Endpunkte privater und öffentlicher Dienste, die in einem GKE-Cluster ausgeführt werden.
Damit Eventarc Dienste in einem bestimmten Cluster als Ziel verwenden und verwalten kann, müssen Sie dem Eventarc-Dienstkonto alle erforderlichen Berechtigungen erteilen.
Sie müssen Workload Identity Federation for GKE in dem GKE-Cluster aktivieren, in dem der Zieldienst ausgeführt wird. Workload Identity Federation for GKE ist für die ordnungsgemäße Einrichtung des Ereignis-Forwarders erforderlich und wird empfohlen, um aus den in GKE ausgeführten Anwendungen aufgrund seiner verbesserten Sicherheitseigenschaften und -verwaltung auf Google Cloud-Dienste zuzugreifen. Weitere Informationen finden Sie unter Workload Identity aktivieren.
Interne HTTP-Endpunkte in einem VPC-Netzwerk
Sie können das Ereignisrouting für einen internen HTTP-Endpunkt in einem VPC-Netzwerk (Virtual Private Cloud) konfigurieren. Zum Konfigurieren des Triggers müssen Sie auch eine Netzwerkanhang-ID angeben. Weitere Informationen finden Sie unter Ereignisse an einen internen HTTP-Endpunkt in einem VPC-Netzwerk weiterleiten.
Workflows
Die Ausführung Ihres Workflows wird anhand der folgenden Situationen ausgelöst:
- Wenn Nachrichten in einem Pub/Sub-Thema veröffentlicht werden
- Wenn ein Audit-Log erstellt wird, das den Filterkriterien des Triggers entspricht
- Als Reaktion auf ein unmittelbares Ereignis, z. B. die Aktualisierung eines Objekts in einem Cloud Storage-Bucket
Für Workflows ist eine IAM-Dienstkonto-E-Mail-Adresse erforderlich, mit der Ihr Eventarc-Trigger die Workflowausführungen aufruft. Es wird empfohlen, ein Dienstkonto mit den geringsten Berechtigungen zu verwenden, die für den Zugriff auf die erforderlichen Ressourcen erforderlich sind. Weitere Informationen finden Sie unter Dienstkonten erstellen und verwalten.
Ereignisformat und Bibliotheken
Eventarc liefert unabhängig von der Quelle Ereignisse an das Ziel in einem CloudEvents-Format mithilfe einer HTTP-Anfrage im Binärinhaltsmodus. CloudEvents ist eine Spezifikation für die allgemeine Beschreibung von Ereignis-Metadaten, die der Cloud Native Computing Foundation untersteht und von der Serverless Working Group der Foundation organisiert wird.
Je nach Ereignisanbieter können Sie die Codierung der Ereignisnutzlastdaten entweder als application/json oder application/protobuf angeben. Protocol Buffers (oder Protobuf) ist ein sprach- und plattformneutraler erweiterbarer Mechanismus zur Serialisierung strukturierter Daten. Wichtige Hinweise:
- Für benutzerdefinierte Quellen oder Drittanbieter oder für direkte Ereignisse aus Pub/Sub wird diese Formatierungsoption nicht unterstützt.
- Eine im JSON-Format formatierte Ereignisnutzlast ist größer als eine in Protobuf formatierte. Dies kann sich je nach Ereignisziel und seine Limits für die Ereignisgröße auf die Zuverlässigkeit auswirken. Weitere Informationen finden Sie unter Bekannte Probleme.
Ziele wie Cloud Run-Funktionen, Cloud Run und GKE verwenden Ereignisse im HTTP-Format. Bei Workflows-Zielen konvertiert der Workflows-Dienst das Ereignis in ein JSON-Objekt und übergibt das Ereignis als Laufzeitargument an die Workflowausführung.
Die Verwendung einer Standardmethode zum Beschreiben von Ereignismetadaten sorgt für Konsistenz, Barrierefreiheit und Übertragbarkeit. Ereignisnutzer können diese Ereignisse direkt lesen, oder Sie können Google CloudEvents SDKs und Bibliotheken in verschiedenen Sprachen (einschließlich C#, Go, Java, Node.js und Python) verwenden, um die Ereignisse zu lesen und zu analysieren:
Die Struktur des HTTP-Texts für alle Ereignisse ist im GitHub-Repository von Google CloudEvents verfügbar.
Abwärtskompatibilität
Eventarc berücksichtigt das Hinzufügen der folgenden Attribute und Felder abwärtskompatibel:
- Optionale Filterattribute oder reine Ausgabeattribute
- Optionale Felder für die Ereignisnutzlast
Eventarc-Trigger
Ereignisse geschehen, ob ein Ziel auf sie reagiert oder nicht. Mit einem Trigger können Sie eine Reaktion auf ein Ereignis erstellen. Sie geben damit an, dass Sie an einem bestimmten Ereignis oder an einer Reihe von Ereignissen interessiert sind. Wenn Sie einen Trigger erstellen, geben Sie Filter für den Trigger an, mit denen Sie diese spezifischen Ereignisse erfassen und darauf reagieren können, einschließlich ihres Routings von einer Ereignisquelle zu einem Ziel. Weitere Informationen finden Sie in der REST-Darstellung einer Triggerressource und unter Ereignisanbieter und -ziele.
Beachten Sie, dass für Eventarc erstellte Pub/Sub-Abos unabhängig von der Aktivität bestehen bleiben und nicht ablaufen. Informationen zum Ändern der Abo-Attribute finden Sie unter Abo-Attribute.
Eventarc unterstützt Trigger für diese Ereignistypen:
| CAL-Ereignisse (Cloud-Audit-Logs) | |
|---|---|
| Beschreibung | Cloud-Audit-Logs bieten Audit-Logs für Admin-Aktivitäten und Audit-Logs zum Datenzugriff für jedes Cloud-Projekt, jeden Ordner und jede Organisation. Google Cloud-Dienste schreiben Einträge in diese Logs. Eventarc unterstützt Audit-Logs auf Projektebene. Weitere Informationen finden Sie in den spezifischen Werten für serviceName und methodName, die von Eventarc als Ereignistypen unterstützt werden. |
| Ereignisfiltertyp | Eventarc-Trigger mit type=google.cloud.audit.log.v1.written senden Anfragen an Ihren Dienst oder Workflow, wenn ein Audit-Log erstellt wird, das den Filterkriterien des Triggers entspricht. |
| Direkte Ereignisse | |
| Beschreibung | Eventarc kann durch verschiedene direkte Ereignisse ausgelöst werden, z. B. eine Aktualisierung in einem Cloud Storage-Bucket, eine Aktualisierung einer Firebase Remote Config-Vorlage oder Änderungen an Ressourcen in Google Cloud-Diensten.
Eventarc kann auch durch Nachrichten ausgelöst werden, die in Pub/Sub-Themen veröffentlicht wurden. Pub/Sub ist ein global verteilter Nachrichtenbus, der automatisch nach Bedarf skaliert wird. Da Eventarc von Nachrichten in einem Pub/Sub-Thema aufgerufen werden kann, können Sie Eventarc in jeden anderen Dienst einbinden, der Pub/Sub als Ziel unterstützt. |
| Ereignisfiltertyp | Eventarc-Trigger mit bestimmten Ereignisfiltertypen senden Anfragen an Ihren Dienst oder Workflow, wenn ein Ereignis eintritt, das den Filterkriterien des Triggers entspricht. Beispiel: type=google.cloud.storage.object.v1.finalized (wenn ein Objekt in einem Cloud Storage-Bucket erstellt wird) oder type=google.cloud.pubsub.topic.v1.messagePublished (wenn eine Nachricht im angegebenen Pub/Sub-Thema veröffentlicht wird).
|
Triggerstandort
Google Cloud-Dienste wie Cloud Storage können als regional oder multiregional eingerichtet werden. Einige Dienste wie Cloud Build können global eingerichtet werden.
Mit Eventarc können Sie regionale Trigger erstellen. Für einige Ereignisse können Sie auch einen globalen Trigger erstellen und Ereignisse aus allen Regionen empfangen. Weitere Informationen finden Sie unter Informationen zu Eventarc-Standorten.
Sie sollten den Speicherort des Eventarc-Triggers so festlegen, dass er mit dem Speicherort des Google Cloud-Dienstes übereinstimmt, der die Ereignisse generiert, um Probleme mit der Leistung und dem Datenstandort zu vermeiden, die durch einen globalen Trigger verursacht werden.
Mit dem Flag --location für jeden Befehl können Sie Triggerstandorte angeben.
Wenn bei Cloud Run-Zielen kein --destination-run-region-Flag angegeben ist, wird davon ausgegangen, dass sich der Dienst in derselben Region wie der Trigger befindet. Weitere Informationen finden Sie in der Referenz zur Google Cloud CLI.
Zuverlässigkeit und Bereitstellung
Die Erwartungen an die Bereitstellung sind:
- Ereignisse, die Cloud-Audit-Logs verwenden, werden in weniger als einer Minute bereitgestellt. (Beachten Sie, dass es, obwohl ein Cloud-Audit-Log-Trigger sofort erstellt wird, bis zu zwei Minuten dauern kann, bis der Trigger weitergegeben wird und Ereignisse filtert.)
- Ereignisse, die Pub/Sub verwenden, werden in Sekunden bereitgestellt.
Es gibt keine garantierte Reihenfolge der Bereitstellung, etwa nach dem Prinzip "First-in-First-out". Beachten Sie, dass eine strikte Reihenfolge die Verfügbarkeits- und Skalierbarkeitsfunktionen von Eventarc beeinträchtigen würde, die mit denen der Transportebene Cloud Pub/Sub übereinstimmen. Weitere Informationen finden Sie unter Nachrichten sortieren.
Latenz und Durchsatz sind Best-Effort. Sie variieren auf Basis verschiedener Faktoren: ob der Eventarc-Trigger regional, multiregional oder global ist; der Konfiguration eines bestimmten Dienstes und der Netzwerkauslastung von Ressourcen in einer Google Cloud-Region.
Es gibt Nutzungskontingente und -limits, die im Allgemeinen für Eventarc gelten. Für Workflows gibt es außerdem Nutzungskontingente und -limits.
Richtlinie für Ereigniswiederholung
Die Wiederholungsmerkmale von Eventarc entsprechen denen der Transportebene, Cloud Pub/Sub. Weitere Informationen finden Sie unter Anfragen wiederholen und Push-Backoff.
Die von Eventarc festgelegte Standardaufbewahrungsdauer für Nachrichten beträgt 24 Stunden mit einer exponentiellen Backoff-Verzögerung.
Sie können die Wiederholungsrichtlinie über das Pub/Sub-Abo aktualisieren, das dem Eventarc-Trigger zugeordnet ist:
- Öffnen Sie die Seite "Trigger-Details".
- Klicken Sie auf das Thema.
- Klicken Sie auf den Tab Abos.
Alle von Eventarc automatisch erstellten Abos haben folgendes Format: projects/PROJECT_ID/subscriptions/eventarc-REGION-TRIGGER_ID-sub-SUBSCRIPTION_ID. Weitere Informationen zu Abolimits finden Sie unter Pub/Sub-Ressourcenlimits.
Wenn Pub/Sub eine Nachricht zustellen soll, das Ziel sie jedoch nicht bestätigen kann, sendet Pub/Sub die Nachricht noch einmal mit einem minimalen exponentiellen Backoff von zehn Sekunden. Wenn das Ziel die Nachricht weiterhin nicht bestätigt, wird der Verzögerung bei jedem Wiederholungsversuch (bis zu einem Maximum von 600 Sekunden) mehr Zeit hinzugefügt und die Nachricht wird noch einmal an das Ziel gesendet.
Beachten Sie, dass Workflows Ereignisse bestätigt, sobald die Workflowausführung beginnt.
Themen für unzustellbare Nachrichten
Wenn das Ziel die Nachricht nicht empfängt, können Sie nicht zugestellte Nachrichten an ein Thema für unzustellbare Nachrichten weiterleiten (auch als Dead-Letter-Warteschlange bezeichnet). In einem Thema für unzustellbare Nachrichten können Nachrichten gespeichert werden, die vom Ziel nicht bestätigt werden können. Sie müssen ein Thema für unzustellbare Nachrichten festlegen, wenn Sie ein Pub/Sub-Abo erstellen oder aktualisieren, und nicht, wenn Sie ein Pub/Sub-Thema erstellen oder wenn Eventarc ein Pub/Sub-Thema erstellt. Weitere Informationen finden Sie unter Umgang mit Nachrichtenfehlern.
Fehler, die keine Wiederholungen rechtfertigen
Wenn Anwendungen Pub/Sub als Ereignisquelle verwenden und das Ereignis nicht zugestellt wird, wird das Ereignis automatisch wiederholt, außer bei Fehlern, die keine Wiederholungen rechtfertigen. Ereignisse für das Workflowziel von einer beliebigen Quelle werden nicht wiederholt, wenn der Workflow nicht ausgeführt wird. Wenn die Workflowausführung beginnt, aber später fehlschlägt, werden die Ausführungen nicht wiederholt. Zum Beheben dieser Dienstprobleme sollten Sie Fehler und Wiederholungsversuche innerhalb des Workflows beheben.
Duplizierte Termine
Ereignis-Duplikate werden möglicherweise an Event-Handler gesendet. Gemäß der CloudEvents-Spezifikation wird die Kombination der Attribute source und id als eindeutig angesehen und daher werden alle Ereignisse mit derselben Kombination als Duplikate betrachtet.
Sie sollten idempotente Event-Handler als allgemeine Best Practice implementieren.
Beobachtbarkeit
Detaillierte Logs für Eventarc, Cloud Run, GKE, Pub/Sub und Workflows sind über Cloud-Audit-Logs verfügbar.
Notfallwiederherstellung
Sie können Zonen und Regionen nutzen, um bei Ausfällen Zuverlässigkeit zu erreichen. Weitere Informationen zur Sicherstellung, dass RTO-Ziele (Recovery Time Objective) und RPO-Ziele (Recovery Point Objective) für Sicherungs- und Wiederherstellungszeiten bei der Verwendung von Eventarc erfüllt werden, finden Sie unter Architektur der Notfallwiederherstellung für Ausfälle der Cloud-Infrastruktur entwickeln.