Panoramica di Eventarc

Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Eventarc consente di creare architetture basate sugli eventi senza dover implementare, personalizzare o gestire l'infrastruttura sottostante. Eventarc offre una soluzione standardizzata per gestire il flusso di modifiche dello stato, chiamate eventi, tra microservizi disaccoppiati. Quando viene attivato, Eventarc esegue il routing di questi eventi tramite gli abbonamenti Pub/Sub a varie destinazioni (in questo documento vedi Destinazioni evento) per la gestione della distribuzione, della sicurezza, dell'autorizzazione, dell'osservabilità e della gestione degli errori.

Puoi gestire Eventarc dalla console Google Cloud, dalla riga di comando utilizzando l'interfaccia a riga di comando gcloud o utilizzando l'API Eventarc.

Eventarc è conforme a questi standard e certificazioni.

Architettura di Eventarc

1 Gli eventi provenienti dai provider Google Cloud vengono inviati direttamente dall'origine (ad esempio, Cloud Storage) o tramite voci di audit log di Cloud e utilizzano Pub/Sub come livello di trasporto. Gli eventi da origini Pub/Sub possono utilizzare un argomento Pub/Sub esistente o Eventarc creano automaticamente un argomento e lo gestiscono per te.

2 Gli eventi per le destinazioni GKE utilizzano lo strumento di forwarding eventi Eventarc per estrarre i nuovi eventi da Pub/Sub e inoltrarli alla destinazione. Questo componente funge da mediatore tra il livello di trasporto Pub/Sub e il servizio di destinazione. Funziona sui servizi esistenti e supporta anche i servizi di segnalazione (inclusi quelli non esposti all'esterno del cluster completamente gestito) semplificando al contempo la configurazione e la manutenzione. Tieni presente che il ciclo di vita dell'inoltro degli eventi è gestito da Eventarc e se elimini accidentalmente l'inoltratore, Eventarc ripristinerà questo componente.

3 Gli eventi per un'esecuzione del flusso di lavoro vengono trasformati e trasmessi al flusso di lavoro come argomenti di runtime. I flussi di lavoro possono combinare e orchestrare servizi Google Cloud e API basati su HTTP in un ordine definito da te.

Principali casi d'uso

Eventarc supporta molti casi d'uso per le applicazioni di destinazione. Ecco alcuni esempi:

Configura e monitora
  • Configurazione di sistema: installa uno strumento di gestione della configurazione su una nuova VM non appena viene avviata.
  • Correzione automatica: rileva se un servizio non risponde correttamente e riavvialo automaticamente.
  • Avvisi e notifiche: monitora il saldo di un indirizzo di portafoglio di criptovalute e attiva le notifiche.
Armonizza
  • Registrazioni della directory: attiva un badge del dipendente non appena un nuovo dipendente entra in un'azienda.
  • Sincronizzazione dei dati: attiva un flusso di lavoro di contabilità quando un potenziale cliente viene convertito in un sistema CRM.
  • Etichettatura delle risorse: etichetta e identifica l'autore di una VM quando viene creata.
Analisi
  • Analisi del sentiment: utilizza l'API Cloud Natural Language per addestrare e sottoporre a deployment un modello ML che collega un punteggio di soddisfazione a un ticket di assistenza clienti non appena completato.
  • Ritocco e analisi delle immagini: rimuovi lo sfondo e categorizza automaticamente un'immagine quando un rivenditore la aggiunge a un negozio di oggetti.

Eventi

Un evento è un record di dati che esprime un'occorrenza e il relativo contesto. Un evento è un'unità di comunicazione separata, indipendente dagli altri eventi. Ad esempio, un evento potrebbe essere una modifica ai dati in un database, un file aggiunto a un sistema di archiviazione o un job programmato.

Consulta la pagina Tipi di eventi supportati da Eventarc.

Fornitori di eventi

Gli eventi vengono indirizzati da un fornitore di eventi (la sorgente) ai consumatori interessati. Il routing viene eseguito in base alle informazioni contenute nell'evento, ma non identifica una destinazione di routing specifica. Attualmente, Eventarc supporta gli eventi dai seguenti provider:

  • Più di 90 provider Google Cloud. Questi fornitori inviano eventi:
    • Direttamente dall'origine (ad esempio, Cloud Storage)
    • Tramite voci di Cloud Audit Logs.
  • Fornitori di Pub/Sub. Questi provider inviano gli eventi a Eventarc utilizzando i messaggi Pub/Sub.

Destinazioni evento

Gli eventi vengono instradati a una destinazione specifica (la destinazione) nota come destinatario dell'evento (o consumer) tramite abbonamenti push Pub/Sub.

Cloud Functions (2a generazione)

Tutte le funzioni basate su eventi in Cloud Functions (2a generazione) utilizzano i trigger Eventarc per fornire eventi. Un trigger Eventarc consente di attivare una funzione da qualsiasi tipo di evento supportato da Eventarc. Puoi configurare i trigger Eventarc quando esegui il deployment di una funzione Cloud utilizzando l'interfaccia di Cloud Functions.

Cloud Run

Scopri come creare un servizio di ricezione di eventi di cui è possibile eseguire il deployment in Cloud Run.

Per determinare il modo migliore per il routing degli eventi a un servizio Cloud Run, vedi Opzioni di routing degli eventi.

GKE

Eventarc supporta la creazione di trigger che hanno come target i servizi Google Kubernetes Engine (GKE). Sono inclusi i servizi Cloud Run for Anthos privati e pubblici in esecuzione in un cluster GKE.

  • Affinché Eventarc possa scegliere come target e gestire i servizi in un determinato cluster, devi concedere all'account di servizio Eventarc le autorizzazioni necessarie.

  • Devi abilitare Workload Identity nel cluster GKE su cui è in esecuzione il servizio di destinazione. Workload Identity è richiesto per configurare correttamente l'inoltro dell'evento ed è il metodo consigliato per accedere ai servizi Google Cloud dalle applicazioni in esecuzione su GKE grazie alle sue proprietà di sicurezza e alla gestibilità migliorate. Per ulteriori informazioni, consulta la pagina relativa all'uso di Workload Identity.

Workflows

L'esecuzione del tuo flusso di lavoro viene attivata dai messaggi pubblicati in un argomento Pub/Sub, quando viene creato un log di controllo che corrisponde ai criteri di filtro del trigger o in risposta a vari eventi all'interno di un bucket Cloud Storage: creazione, eliminazione, archiviazione e aggiornamenti dei metadati degli oggetti.

Workflows richiede un'email per l'account di servizio IAM che il trigger Eventarc utilizzerà per richiamare le esecuzioni del flusso di lavoro. Consigliamo di utilizzare un account di servizio con i privilegi minimi necessari per accedere alle risorse richieste. Per scoprire di più sugli account di servizio, consulta Creare e gestire account di servizio.

Formato e librerie eventi

Eventarc consegna gli eventi, indipendentemente dal provider, alla destinazione in un formato CloudEvents utilizzando una richiesta HTTP in modalità contenuti binari. CloudEvents è una specifica per descrivere i metadati degli eventi in modo comune, all'interno della Cloud Native Computing Foundation.

Le destinazioni Cloud Functions, Cloud Run e GKE utilizzano gli eventi in formato HTTP. Tuttavia, per le destinazioni di Workflows, il servizio Workflows converte l'evento in un oggetto JSON (secondo la specifica JSON CloudEvents) e lo trasferisce nell'esecuzione del flusso di lavoro come argomento di runtime.

L'utilizzo di un metodo standard per descrivere i metadati degli eventi garantisce coerenza, accessibilità e portabilità. I consumatori degli eventi possono leggere direttamente questi eventi oppure puoi utilizzare gli SDK e le librerie di Google CloudEvents in vari linguaggi (inclusi C#, Go, Java, Node.js e Python) per leggere e analizzare gli eventi:

Librerie di analisi Eventarc

La struttura del corpo HTTP per tutti gli eventi è disponibile nel repository GitHub di Google CloudEvents.

Compatibilità con le versioni precedenti

Eventarc considera l'aggiunta dei seguenti attributi e campi compatibili con le versioni precedenti:

  • Attributi di filtro facoltativi o attributi solo di output
  • Campi facoltativi per il payload dell'evento

Trigger Eventarc

Gli eventi si verificano se una destinazione target reagisce o meno a questi eventi. Puoi creare una risposta a un evento con un trigger. Con il trigger dichiari di essere interessato a un determinato evento o a una serie di eventi. Quando crei un trigger, specifichi filtri per l'attivatore che ti consentono di acquisire ed eseguire azioni su tali eventi specifici, incluso il relativo routing da un'origine evento a una destinazione. Per saperne di più, consulta la rappresentazione REST di una risorsa del trigger e scopri come creare un trigger.

Tieni presente che le sottoscrizioni Pub/Sub create per Eventarc rimangono indipendentemente dall'attività e non scadono. Per modificare le proprietà dell'abbonamento, consulta la pagina Gestire gli abbonamenti.

Eventarc supporta trigger per i seguenti tipi di eventi:

Eventi di Cloud Audit Logs (CAL)
DescrizioneGli audit log di Cloud forniscono audit log delle attività di amministrazione e dell'accesso ai dati per ogni progetto, cartella e organizzazione Cloud. I servizi Google Cloud scrivono le voci di questi log. Questo elenco di eventi supportati include una directory con valori di serviceName e methodName.
Tipo di filtro eventiI trigger Eventarc con type=google.cloud.audit.log.v1.written inviano richieste al tuo servizio o flusso di lavoro quando viene creato un log di controllo che corrisponde ai criteri di filtro dei trigger.
Eventi Cloud Pub/Sub
DescrizioneEventarc può essere attivato dai messaggi pubblicati negli argomenti Pub/Sub. Pub/Sub è un bus di messaggi distribuito a livello globale che scala automaticamente in base alle tue esigenze. Poiché Eventarc può essere richiamato dai messaggi su un argomento Pub/Sub, puoi facilmente integrare Eventarc con qualsiasi altro servizio che supporti Pub/Sub come destinazione.
Tipo di filtro eventiI trigger Eventarc con type=google.cloud.pubsub.topic.v1.messagePublished inviano richieste al tuo servizio o flusso di lavoro quando un messaggio viene pubblicato nell'argomento Pub/Sub specificato.
Eventi diretti
DescrizioneEventarc può essere attivato da vari eventi diretti, ad esempio un aggiornamento di un bucket Cloud Storage, un aggiornamento a un modello Firebase Remote Config o le modifiche alle risorse sui servizi Google Cloud.
Tipo di filtro eventiI trigger Eventarc con tipi di filtri di eventi specifici inviano richieste al servizio o flusso di lavoro quando si verifica un evento che corrisponde ai criteri di filtro dei trigger, ad esempio type=google.cloud.storage.object.v1.finalized.

Località trigger

I servizi Google Cloud come Cloud Storage possono essere configurati per essere a livello di una o più regioni. Alcuni servizi, come Cloud Build, possono essere configurati a livello globale.

Eventarc consente di creare trigger a livello di regione o, per alcuni eventi, puoi creare un trigger globale e ricevere eventi da tutte le regioni. Per ulteriori informazioni, consulta Informazioni sulle località di Eventarc.

Devi specificare la località del trigger Eventarc in modo che corrisponda alla località del servizio Google Cloud che genera gli eventi ed evitare problemi relativi alle prestazioni e alla residenza dei dati causati da un trigger globale.

Puoi specificare le località di attivazione utilizzando un flag --location con ciascun comando. Se non viene specificato un flag --destination-run-region, si presume che il servizio si trovi nella stessa area geografica del trigger. Per ulteriori informazioni, consulta il riferimento per Google Cloud CLI.

Affidabilità e consegna

Le aspettative di consegna sono le seguenti:

  • Gli eventi che utilizzano gli audit log di Cloud vengono distribuiti in meno di un minuto. Tieni presente che, anche se un trigger di Cloud Audit Logs viene creato immediatamente, la propagazione e il filtro degli eventi possono richiedere fino a due minuti.
  • Gli eventi che utilizzano Pub/Sub vengono distribuiti in pochi secondi.

Non è prevista una garanzia di consegna in base all'ordine di acquisto. Tieni presente che l'ordinamento rigide comprometterebbe la disponibilità e le caratteristiche di scalabilità di Eventarc che corrispondono a quelle del livello di trasporto Cloud Pub/Sub. Per ulteriori informazioni, vedi Ordinare i messaggi.

La latenza e la velocità effettiva sono le migliori. variano in base a più fattori, a seconda che il trigger Eventarc sia a livello di una o più aree geografiche o a livello globale, alla configurazione di un determinato servizio e al carico di rete sulle risorse in un'area geografica di Google Cloud.

Tieni presente che esistono quote di utilizzo e limiti che si applicano in genere a Eventarc. Esistono anche quote e limiti di utilizzo specifici dei flussi di lavoro.

Criterio nuovo tentativo evento

Le caratteristiche dei nuovi tentativi di Eventarc corrispondono a quelle del relativo livello di trasferimento, Cloud Pub/Sub. Per maggiori informazioni, vedi Riprovare le richieste e Backoff push.

L'impostazione predefinita per i nuovi tentativi è di 24 ore con un ritardo di backoff esponenziale. Puoi aggiornare il criterio di nuovo tentativo tramite la sottoscrizione Pub/Sub associata al trigger Eventarc: Apri la pagina Dettagli trigger, fai clic sull'argomento e quindi sulla scheda Abbonamenti. Qualsiasi abbonamento creato automaticamente da Eventarc avrà questo formato: projects/PROJECT_ID/subscriptions/eventarc-REGION-TRIGGER_ID-sub-SUBSCRIPTION_ID.

Se Pub/Sub tenta di consegnare un messaggio ma la destinazione non riesce a riconoscerlo, Pub/Sub proverà a inviare il messaggio immediatamente. Se le condizioni della destinazione che hanno impedito il riconoscimento del messaggio non sono cambiate, il messaggio verrà ricaricato continuamente, ma non ricevuto alla destinazione. Per risolvere questo problema, puoi configurare un criterio per i nuovi tentativi di sottoscrizione a Pub/Sub oppure inoltrare i messaggi non recapitati a un argomento messaggi non recapitabili (noto anche come coda dei messaggi non recapitabili). Per ulteriori informazioni, consulta la sezione Gestire gli errori relativi ai messaggi. Ad esempio, se il servizio di destinazione non accetta i messaggi, Pub/Sub conserva gli eventi per 7 giorni per impostazione predefinita e riprova a inviare gli eventi alla destinazione. Per ulteriori informazioni, consulta i limiti delle risorse Pub/Sub.

Quando le applicazioni utilizzano Pub/Sub come origine dell'evento e l'evento non viene consegnato, viene eseguito automaticamente un nuovo tentativo dell'evento, ad eccezione degli errori che non garantiscono tentativi ripetuti. Tieni presente che Workflows riconosce gli eventi non appena inizia l'esecuzione del flusso di lavoro. Se il flusso di lavoro non viene eseguito, verrà eseguito un nuovo tentativo per gli eventi alla destinazione del flusso di lavoro da qualsiasi origine. Se l'esecuzione del flusso di lavoro inizia ma poi non riesce, non viene eseguito un nuovo tentativo. Per risolvere tali problemi di servizio, devi gestire gli errori e i tentativi all'interno del flusso di lavoro.

Duplicare gli eventi

Gli eventi duplicati potrebbero essere inviati ai gestori di eventi. In base alla specifica CloudEvents, la combinazione di attributi source e id è considerata unica e di conseguenza tutti gli eventi con la stessa combinazione sono considerati duplicati. Devi implementare i gestore di eventi idempotenti come best practice generale.

Osservabilità

I log dettagliati per Eventarc, Cloud Run, Cloud Run for Anthos, Pub/Sub e Flussi di lavoro sono disponibili negli audit log di Cloud.

Passaggi successivi