Google utilizza la tecnologia AI per tradurre i contenuti nella tua lingua preferita. Le traduzioni generate dall'AI potrebbero contenere errori.

Panoramica di Eventarc Standard

Eventarc ti consente di creare architetture basate su eventi senza dover implementare, personalizzare o gestire l'infrastruttura sottostante.

Eventarc è disponibile in due versioni: Eventarc Advanced e Eventarc Standard. Entrambe le versioni offrono una soluzione di eventi scalabile, serverless e completamente gestita che ti consente di instradare in modo asincrono gli eventi dalle origini alle destinazioni. Per saperne di più, vedi Scegliere Eventarc Advanced o Eventarc Standard.

Eventarc Standard offre una soluzione standardizzata per gestire il flusso delle modifiche dello stato, chiamate eventi, tra microservizi disaccoppiati. Quando viene attivato, Eventarc Standard indirizza questi eventi a varie destinazioni (in questo documento, vedi Destinazioni evento) e gestisce per te la distribuzione, la sicurezza, l'autorizzazione, l'osservabilità e la gestione degli errori.

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

Eventarc indirizza gli eventi dai provider di eventi alle destinazioni di eventi. — Eventarc Standard ti consente di instradare gli eventi dai provider di eventi alle destinazioni evento (fai clic sul diagramma per ingrandirlo).

¹ Gli eventi dei provider Google vengono inviati direttamente dall'origine (ad esempio Cloud Storage) o tramite le voci di Cloud Audit Logs e utilizzano Pub/Sub come livello di trasporto. Gli eventi provenienti da origini Pub/Sub possono utilizzare un argomento Pub/Sub esistente oppure Eventarc creerà e gestirà automaticamente un argomento per te.

² Eventi per le destinazioni Google Kubernetes Engine (GKE), inclusi i servizi Knative Serving in esecuzione in un cluster GKE, utilizzano il forwarder di eventi di Eventarc per recuperare 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 del forwarder di eventi è gestito da Eventarc e, se elimini accidentalmente il forwarder di eventi, Eventarc ripristinerà questo componente.

³ Gli eventi per l'esecuzione di un flusso di lavoro vengono trasformati e passati al flusso di lavoro come argomenti runtime. Workflows possono combinare e orchestrare Google Cloud i servizi API basati su HTTP in un ordine definito dall'utente.

⁴ Tutte le funzioni basate su eventi in Cloud Run Functions utilizzano i trigger Eventarc per distribuire gli eventi. Puoi configurare i trigger Eventarcquando esegui il deployment di una funzione Cloud Run utilizzando l' interfaccia di Cloud Run Functions.

Casi d'uso principali

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

Configurare e monitorare	Configurazione del sistema: installa uno strumento di gestione della configurazione su una nuova VM all'avvio. Correzione automatica: rileva se un servizio non risponde correttamente e riavvialo automaticamente. Avvisi e notifiche: monitora il saldo di un indirizzo del portafoglio di criptovalute e attiva le notifiche.
Armonizzare	Registrazioni di directory: attiva un badge dipendente quando un nuovo dipendente entra a far parte di 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 il creatore di una VM al momento della creazione.
Analizzare	Analisi del sentiment: utilizza l'API Cloud Natural Language per addestrare ed eseguire il deployment di un modello di machine learning che assegna un punteggio di soddisfazione a un ticket di assistenza clienti al termine. Ritocco e analisi delle immagini: rimuovi lo sfondo e classifica automaticamente un'immagine quando un rivenditore la aggiunge a un archivio di oggetti.

Eventi

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

Consulta i tipi di eventi Google supportati da Eventarc.

Provider di eventi

Gli eventi vengono instradati da un provider di eventi (l'origine) ai consumatori di eventi interessati. Il routing viene eseguito in base alle informazioni contenute nell'evento, ma un evento non identifica una destinazione di routing specifica. Eventarc supporta eventi provenienti da più di 130 provider Google. Questi provider inviano eventi (ad esempio, un aggiornamento di un oggetto in un bucket Cloud Storage o un messaggio pubblicato in un argomento Pub/Sub) direttamente dall'origine o tramite le voci di Cloud Audit Logs.

Destinazioni evento

Gli eventi vengono instradati a una destinazione specifica (il target) nota come ricevitore di eventi (o consumer) tramite le sottoscrizioni push di Pub/Sub.

Cloud Run

Scopri come creare un servizio di ricezione di eventi che può essere sottoposto a deployment in Cloud Run.

Per determinare il modo migliore per instradare gli eventi a un servizio Cloud Run, vedi Percorsi degli eventi.

Cloud Run Functions

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

GKE

Eventarc supporta la creazione di trigger che hanno come target i servizi Google Kubernetes Engine (GKE). Sono inclusi gli endpoint pubblici dei servizi 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 al account di servizio Eventarc le autorizzazioni necessarie.
Devi abilitare Workload Identity Federation for GKE sul cluster GKE su cui è in esecuzione il servizio di destinazione. Workload Identity Federation for GKE è necessario per configurare correttamente il forwarder di eventi ed è il metodo consigliato per accedere Google Cloud ai servizi dalle applicazioni in esecuzione in GKE grazie al miglioramento delle sue proprietà di sicurezza e della sua gestibilità. Per maggiori informazioni, consulta Abilitare Workload Identity.

Endpoint HTTP interni in una rete VPC

Puoi configurare il routing degli eventi a un endpoint HTTP interno in una rete Virtual Private Cloud (VPC). Per configurare il trigger, devi anche fornire un ID di collegamento di rete. Per saperne di più, vedi Instradare gli eventi a un endpoint HTTP interno in una rete VPC.

Workflows

Puoi attivare l'esecuzione di un flusso di lavoro. Workflows richiedono un indirizzo email del account di servizio IAM che il trigger Eventarc utilizzerà per richiamare le esecuzioni del flusso di lavoro. Ti consigliamo di utilizzare un account di servizio con i privilegi minimi necessari per accedere alle risorse richieste. Per saperne di più, vedi Creare e gestire service account.

Formato ed eventi delle librerie

Eventarc distribuisce gli eventi, indipendentemente dal provider, alla destinazione target in formato CloudEvents utilizzando una richiesta HTTP in modalità di contenuti binari. CloudEvents è una specifica per descrivere i metadati degli eventi in modo comune.

A seconda del provider di eventi, puoi specificare la codifica dei dati del payload dell'evento come application/json o application/protobuf. I buffer di protocollo (o Protobuf) sono un meccanismo estensibile indipendente dalla lingua e dalla piattaforma per la serializzazione dei dati strutturati. Tieni presente quanto segue:

Per le origini personalizzate, i provider di terze parti o gli eventi diretti da Pub/Sub, questa opzione di formattazione non è supportata.
Un payload di eventi formattato in JSON è più grande di uno formattato in Protobuf e questo potrebbe influire sull'affidabilità a seconda della destinazione dell'evento e dei relativi limiti di dimensioni dell'evento. Per maggiori informazioni, vedi Problemi noti.

Le destinazioni target come Cloud Run Functions, Cloud Run, e GKE utilizzano gli eventi in formato HTTP. Per le destinazioni dei flussi di lavoro , il servizio Workflows converte l'evento in un oggetto JSON e lo passa all'esecuzione del flusso di lavoro come argomento runtime.

L'utilizzo di un modo standard per descrivere i metadati degli eventi garantisce coerenza, accessibilità e portabilità. I consumatori di eventi possono leggere questi eventi direttamente, oppure puoi utilizzare le librerie client Cloud in varie lingue (tra cui C++, C#, Go, Java, Node.js, PHP, Python e Ruby) per leggere e analizzare gli eventi. Esiste anche un insieme di SDK CloudEvents specifici per la lingua .

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

Eventarc pubblica gli eventi in formato CloudEvents. Puoi leggere gli eventi
direttamente o utilizzare gli SDK o le librerie Google CloudEvents per analizzarli. — **Figura 2.** Eventarc distribuisce gli eventi in formato CloudEvents alle destinazioni evento. Puoi leggere questi eventi direttamente oppure utilizzare gli SDK CloudEvents o le librerie Google per leggere e analizzare gli eventi.

Retrocompatibilità

Eventarc considera retrocompatibile l'aggiunta dei seguenti attributi e campi:

Attributi di filtro facoltativi o attributi di sola lettura
Campi facoltativi per il payload dell'evento

Trigger Eventarc

Gli eventi si verificano indipendentemente dal fatto che una destinazione target reagisca o meno. Crea 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 i filtri per il trigger che ti consentono di acquisire e agire su eventi specifici, incluso il loro routing da un'origine evento a una destinazione target. Per saperne di più, vedi la rappresentazione REST di una risorsa trigger e i provider e le destinazioni di eventi.

Tieni presente che le sottoscrizioni Pub/Sub create per Eventarc persistono indipendentemente dall'attività e non scadono. Per modificare le proprietà della sottoscrizione, vedi Proprietà della sottoscrizione.

Eventarc supporta i trigger per questi tipi di eventi:

Eventi di Cloud Audit Logs (CAL)
Descrizione	Cloud Audit Logs fornisce audit log di attività di amministrazione e accesso ai dati per ogni progetto, cartella e organizzazione Cloud. Google Cloud I servizi scrivono le voci in questi log. Puoi creare filtri per i trigger Eventarc utilizzando i valori `serviceName` e `methodName` negli audit log. Per i valori esatti, consulta Google Cloud i servizi con audit log. Per saperne di più, vedi Determinare i filtri eventi per Cloud Audit Logs.
Tipo di filtro eventi	I trigger Eventarc con `type=google.cloud.audit.log.v1.written` inviano richieste al tuo servizio o flusso di lavoro quando viene creato un audit log che corrisponde ai criteri di filtro del trigger.
Eventi diretti
Descrizione	Eventarc può essere attivato da vari eventi diretti, ad esempio un aggiornamento di un bucket Cloud Storage un aggiornamento di un modello di Firebase Remote Config o modifiche alle risorse sui Google Cloud servizi. Eventarc può essere attivato anche dai messaggi pubblicati negli argomenti Pub/Sub. Pub/Sub è un bus di messaggi distribuito a livello globale che scala automaticamente in base alle esigenze. Poiché Eventarc può essere richiamato dai messaggi in un argomento Pub/Sub, puoi integrarlo con qualsiasi altro servizio che supporti Pub/Sub come destinazione.
Tipo di filtro eventi	I trigger Eventarc con tipi di filtri eventi specifici inviano richieste al tuo servizio o flusso di lavoro quando si verifica un evento che corrisponde ai criteri di filtro del trigger; ad esempio, `type=google.cloud.storage.object.v1.finalized` (quando viene creato un oggetto in un bucket Cloud Storage) o `type=google.cloud.pubsub.topic.v1.messagePublished` (quando viene pubblicato un messaggio nell'argomento Pub/Sub specificato).

Località del trigger

Google Cloud I servizi come Cloud Storage possono essere configurati in modo da essere regionali o multiregionali. Alcuni servizi, come Cloud Build, possono essere configurati a livello globale.

Importante: poiché Eventarc Standard utilizza Pub/Sub come livello di trasporto, i trigger Cloud Storage possono non riuscire se un evento Cloud Storage proviene da una regione non consentita dalla policy di archiviazione dei messaggi Pub/Sub e se le operazioni in transito sono applicate ("enforceInTransit": true). Quando crei un trigger Cloud Storage in una località multiregionale, assicurati che la policy di archiviazione dei messaggi consenta tutte le regioni di origine all'interno di quella multiregione. Per saperne di più, vedi Configurare le policy di archiviazione dei messaggi.

Eventarc ti consente di creare trigger regionali o, per alcuni eventi, puoi creare un trigger globale e ricevere eventi da tutte le regioni. Per saperne di più, vedi Informazioni sulle località Eventarc.

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

Puoi specificare le località dei trigger utilizzando un flag --location con ogni comando. Per le destinazioni Cloud Run, se non viene specificato un flag --destination-run-region, si presuppone che il servizio si trovi nella stessa regione del trigger. Per saperne di più, consulta il riferimento a Google Cloud CLI.

Affidabilità e distribuzione

Le aspettative di distribuzione sono le seguenti:

Gli eventi che utilizzano Cloud Audit Logs vengono distribuiti in meno di un minuto. (Tieni presente che, sebbene un trigger Cloud Audit Logs venga creato immediatamente, possono essere necessari fino a due minuti prima che un trigger si propaghi e filtri gli eventi.)
Gli eventi che utilizzano Pub/Sub vengono distribuiti in pochi secondi.

Non è garantita la distribuzione in ordine, FIFO (First-In-First-Out). Tieni presente che un ordinamento rigoroso comprometterebbe le funzionalità di disponibilità e scalabilità di Eventarc, che corrispondono a quelle del livello di trasporto, Cloud Pub/Sub. Per saperne di più, vedi Ordinare i messaggi.

La latenza e la velocità effettiva sono il massimo sforzo. Variano in base a diversi fattori, tra cui se il trigger Eventarc è regionale, multiregionale o globale, la configurazione di un servizio specifico e il carico di rete sulle risorse in una Google Cloud regione.

Tieni presente che esistono quote e limiti di utilizzo che si applicano in generale a Eventarc. Esistono anche quote e limiti di utilizzo specifici per Workflows.

Policy di ripetizione degli eventi

Le caratteristiche di ripetizione di Eventarc corrispondono a quelle del livello di trasporto, Cloud Pub/Sub. La durata predefinita di conservazione dei messaggi impostata da Eventarc è di 24 ore con un ritardo di backoff esponenziale.

Puoi aggiornare la policy di ripetizione tramite la sottoscrizione Pub/Sub associata al trigger Eventarc. Per saperne di più, vedi Ripetere gli eventi.

Facoltativamente, per le destinazioni Cloud Run (incluse Cloud Run Functions), puoi configurare un singolo tentativo di distribuzione senza ripetizioni. Questa è la configurazione predefinita quando utilizzi la Google Cloud console per creare un trigger Eventarc per una destinazione Cloud Run. Per saperne di più, vedi Creare trigger con Eventarc.

Osservabilità

Google Cloud Observability fornisce strumenti di monitoraggio, logging e diagnostica. Questi strumenti possono aiutarti a monitorare e analizzare l'attività e la crescita di Eventarc e a comprendere il comportamento, l'integrità e le prestazioni delle tue applicazioni. Per saperne di più, vedi Osservabilità in Eventarc.

I log dettagliati per Eventarc, Cloud Run, Cloud Run Functions, GKE, Pub/Sub e Flussi di lavoro sono disponibili in Cloud Audit Logs.

Disaster recovery

Puoi sfruttare le zone e le regioni per ottenere affidabilità in caso di interruzioni. Per saperne di più su come garantire che gli obiettivi RTO (Recovery Time Objective) e RPO (Recovery Point Objective) vengano soddisfatti per i tempi di backup e ripristino quando utilizzi Eventarc, vedi Progettare ripristino di emergenza per le interruzioni dell'infrastruttura cloud.

Standard di conformità

Eventarc Standard è conforme a certificazioni e standard specifici certificazioni e standard. Per evitare di utilizzare risorse Eventarc Advanced non conformi, puoi creare una policy dell'organizzazione personalizzata che disattiva le risorse Eventarc Advanced. Per saperne di più, vedi Disattivare le risorse Eventarc Advanced.