Abilita i nuovi tentativi per le funzioni basate su eventi
Questo documento descrive come abilitare il nuovo tentativo per funzioni basate su eventi, I tentativi automatici non sono disponibili per le funzioni HTTP.
Semantica del nuovo tentativo
Le funzioni di Cloud Run consentono l'esecuzione "at-least-once" di una funzione basata su eventi per ogni evento generato da un'origine evento. Per impostazione predefinita, se una funzione la chiamata termina con un errore, la funzione non viene richiamata di nuovo e l'evento viene eliminato. Quando attivi i nuovi tentativi su un modello basato su eventi , le funzioni Cloud Run ritentano una chiamata di funzione non riuscita fino a quando il completamento o la finestra di nuovo tentativo scade.
Questa finestra di ripetizione dell'operazione scade dopo 24 ore. Cloud Run functions riprova le funzioni basate sugli eventi appena create utilizzando una strategia di backoff esponenziale, con un backoff crescente compreso tra 10 e 600 secondi.Quando i nuovi tentativi non sono abilitati per una funzione (impostazione predefinita), la funzione
segnala sempre che è stata eseguita correttamente e i codici di risposta 200 OK
potrebbero
vengono visualizzate nei log. Ciò si verifica anche se la funzione ha rilevato un errore. Per chiarire quando la funzione rileva un errore, assicurati di segnalare gli errori in modo appropriato.
Perché le funzioni basate su eventi non vengono completate
In rari casi, una funzione potrebbe uscire prematuramente a causa di un errore interno e, per impostazione predefinita, il tentativo potrebbe essere ripetuto automaticamente o meno.
Più in generale, una funzione basata su eventi potrebbe non essere completata correttamente a causa di errori generati nel codice della funzione stessa. Ecco alcuni motivi per cui questo potrebbe accadere:
- La funzione contiene un bug e il runtime genera un'eccezione.
- La funzione non riesce a raggiungere un endpoint del servizio o il timeout si verifica durante il tentativo di farlo.
- La funzione genera intenzionalmente un'eccezione (ad esempio quando un parametro non supera la convalida).
- Una funzione Node.js restituisce una promessa rifiutata o passa un valore diverso da
null
a un callback.
In ognuno di questi casi, l'esecuzione della funzione viene interrotta per impostazione predefinita e l'evento viene ignorato. Per riprovare la funzione quando si verifica un errore, puoi modifica il criterio predefinito per i nuovi tentativi l'impostazione del "ritenta in caso di errore" proprietà. In questo modo l'evento viene ritentato più volte fino alla viene completata correttamente o il timeout per il nuovo tentativo scade.
Abilita o disabilita i nuovi tentativi
Per attivare o disattivare i tentativi di nuovo invio, puoi utilizzare lo strumento a riga di comando gcloud
o la console Google Cloud. Per impostazione predefinita, i nuovi tentativi sono disattivati.
Configurare i tentativi di nuovo invio dallo strumento a riga di comando gcloud
Per abilitare i tentativi di nuovo utilizzando lo strumento a riga di comando gcloud
, includi il flag --retry
durante il deployment della funzione:
gcloud functions deploy FUNCTION_NAME --retry FLAGS...
Per disabilitare i nuovi tentativi, esegui nuovamente il deployment della funzione senza il flag --retry
:
gcloud functions deploy FUNCTION_NAME FLAGS...
Configura i nuovi tentativi dalla console
Se stai creando una nuova funzione:
- Nella schermata Crea funzione, in Attivati, scegli il tipo di evento da utilizzare come attivatore per la funzione.
- Seleziona la casella di controllo Riprova in caso di errore per abilitare i nuovi tentativi.
Se stai aggiornando una funzione esistente:
- Nella pagina Panoramica delle funzioni di Cloud Run, fai clic sul nome del che stai aggiornando per aprire la schermata Dettagli funzione, quindi Scegli Modifica dalla barra dei menu per visualizzare il riquadro Trigger.
- Seleziona o deseleziona la casella di controllo Riprova in caso di errore per attivare o disattivare i tentativi di nuovo invio.
Best practice
In questa sezione vengono descritte le best practice per l'utilizzo di nuovi tentativi.
Utilizza Riprova per gestire gli errori temporanei
Poiché la funzione viene ripetuta continuamente fino a quando l'esecuzione non riesce, gli errori permanenti, come i bug, dovrebbero essere eliminati dal codice tramite test prima di abilitare i nuovi tentativi. I tentativi sono ideali per gestire errori intermittenti o temporanei con un'alta probabilità di risoluzione al successivo tentativo, ad esempio un endpoint di servizio inaffidabile o un timeout.
Imposta una condizione di fine per evitare loop infiniti di nuovi tentativi
Una best practice consiste nel proteggere la funzione dal loop continuo quando usando nuovi tentativi. Puoi farlo includendo una condizione di fine ben definita, prima dell'inizio dell'elaborazione della funzione. Tieni presente che questa tecnica funziona solo se la funzione si avvia correttamente ed è in grado di valutare la condizione di fine.
Un approccio semplice ma efficace è eliminare gli eventi con timestamp precedenti a un determinato momento. Ciò aiuta a evitare esecuzioni eccessive in caso di errori. duraturi o più a lungo del previsto.
Ad esempio, questo snippet di codice ignora tutti gli eventi precedenti a 10 secondi:
Node.js
Python
Vai
Java
C#
Ruby
PHP
Distinguere tra funzioni che possono essere riprovate ed errori irreversibili
Se per la funzione sono abilitati nuovi tentativi, qualsiasi errore non gestito attiverà un nuovo tentativo. Assicurati che il codice catturi eventuali errori che non devono comportare un nuovo tentativo.
Node.js
Python
Vai
Java
C#
Ruby
PHP
Rendere idempotenti le funzioni basate su eventi ripetibili
Le funzioni basate su eventi per le quali è possibile ripetere il tentativo devono essere idempotenti. Ecco alcune linee guida generali per rendere idempotente una funzione di questo tipo:
- Molte API esterne (come Stripe) ti consentono di fornire una chiave di idempotenza come parametro. Se utilizzi un'API di questo tipo, devi utilizzare l'ID evento come chiave di iride.
- L'idempotenza funziona bene con la consegna "at-least-once", perché consente di riprova. Una best practice generale per scrivere codice affidabile è combinare idempotenza con nuovi tentativi.
- Assicurati che il tuo codice sia internamente idempotente. Ad esempio:
- Assicurati che le mutazioni possano verificarsi più di una volta senza modificare il risultato.
- Esegui query sullo stato del database in una transazione prima di modificarlo.
- Assicurati che tutti gli effetti collaterali siano idempotenti.
- Imporre un controllo transazionale all'esterno della funzione, indipendentemente dal codice. Ad esempio, mantieni lo stato da qualche parte registrando che un determinato ID evento è stato già elaborato.
- Gestire chiamate di funzione duplicate fuori banda. Ad esempio, puoi avere un processo di pulizia distinto che elimina i dati dopo le chiamate di funzioni duplicate.
Configura il criterio per i nuovi tentativi
A seconda delle esigenze della tua funzione Cloud Run, ti consigliamo di configurare nuovo criterio di ripetizione. Questo ti consente di impostare qualsiasi combinazione di seguenti:
- Riduci il periodo di attesa per il nuovo tentativo da 7 giorni a un minimo di 10 minuti.
- Modifica il tempo di attesa minimo e massimo per la strategia di ripetizione con tempo di attesa esponenziale.
- Modifica la strategia per riprovare immediatamente.
- Configura un argomento messaggi non recapitabili.
- Imposta un numero massimo e minimo di tentativi di consegna.
Per configurare il criterio di ripetizione:
- Scrivi una funzione HTTP.
- Utilizza l'API Pub/Sub per creare un abbonamento Pub/Sub, specificando l'URL della funzione come target.
Per ulteriori informazioni sulla configurazione diretta di Pub/Sub, consulta la documentazione di Pub/Sub sulla gestione degli errori.
Passaggi successivi
- Deployment delle funzioni di Cloud Run.
- Chiamata delle funzioni di trigger Pub/Sub.
- Chiamata delle funzioni di attivazione Cloud Storage.
- Tutorial sulle funzioni di Cloud Run con Pub/Sub.
- Tutorial sulle funzioni di Cloud Run con Cloud Storage.