Smetti di Martellare una Dipendenza in Difficoltà: Pattern di Retry per Azure Functions + Service Bus

Emiliano Montesdeoca — Thu, 21 May 2026 00:00:00 +0000

Ecco come un guasto recuperabile diventa un’interruzione in un’applicazione Functions: una dipendenza inizia a generare timeout, ogni istanza Function riprova immediatamente e indefinitamente, la dipendenza viene martellata con centinaia di richieste fallite concorrenti, e quello che è iniziato come un piccolo problema transitorio diventa un evento di contropressione a livello di sistema.

Probabilmente conosci questa storia. Azure Functions scala velocemente — questo è tutto il punto. Ma “scalare velocemente” e “riprovare immediatamente” insieme possono peggiorare drammaticamente i guasti.

Due pattern aiutano. Exponential backoff e circuit breaker. Entrambi sono ora supportati nativamente per le Azure Functions attivate da Service Bus.

Due Pattern, Ruoli Diversi

Questi pattern sono complementari, non alternative:

L’exponential backoff risponde a: quando dovrei riprovare? Aumenta il ritardo tra i tentativi in modo che una dipendenza abbia il tempo di recuperare. A livello di messaggio, regolando il ritmo dei retry.

Il circuit breaker risponde a: dovrei chiamare questa dipendenza adesso? Interrompe le chiamate ripetute a una dipendenza non sana dopo che viene raggiunta una soglia di errore, poi sonda con cautela dopo un periodo di raffreddamento. A livello di sistema, prevenendo le tempeste di retry.

Li vuoi entrambi. Il backoff gestisce il ritmo dei retry per messaggio. Il circuit breaker gestisce le decisioni di salute aggregate.

Perché è Importante Specialmente per Service Bus

La coda assorbe il traffico a burst, il che è positivo. Ma senza controlli, la coda può crescere mentre i worker continuano a sprecare risorse di calcolo su chiamate che falliranno. I messaggi avvelenati rimangono attivi più a lungo di quanto dovrebbero. Le partizioni calde o la capacità downstream limitata creano problemi a cascata.

Il design più sicuro:

Rilevare il guasto transitorio
Ritardare il prossimo tentativo con exponential backoff
Interrompere le chiamate alla dipendenza quando viene raggiunta una soglia di guasto (circuito aperto)
Riprendere con cautela dopo un periodo di raffreddamento (sonda del circuito)
Spostare il lavoro irrecuperabile in dead-letter o in un percorso di quarantena

Come Appare il Supporto Nativo

Il nuovo supporto si integra con il modello di host Azure Functions esistente — nessuna libreria aggiuntiva, nessuna implementazione personalizzata. La configurazione va nel tuo host.json:

{
 "extensions": {
 "serviceBus": {
 "messageHandlerOptions": {
 "maxRetryCount": 5,
 "retryPolicy": {
 "mode": "exponentialBackoff",
 "minBackoff": "00:00:02",
 "maxBackoff": "00:05:00",
 "maxRetryCount": 5
 }
 }
 }
 }
}

La configurazione del circuit breaker imposta la soglia di errore e l’intervallo di reset in modo che le dipendenze non sane non vengano bombardate durante il recupero.

Linguaggi Coperti

Questo non è solo per .NET. La funzionalità copre dotnet, JavaScript, TypeScript e Python — il set completo di linguaggi supportati dal trigger Service Bus in Azure Functions.

Conclusione

I pattern di retry non sono emozionanti da configurare fino alla prima volta che un’interruzione downstream fa sì che le tue Functions peggiorino il problema invece di degradarsi gradualmente. Configurarli in modo proattivo è economico. Adattarli durante un incidente non lo è.