Quando i tuoi microservizi iniziano a litigare: in che modo gli interruttori automatici mantengono calmo il tuo sistema Spring Boot

Immagina questo scenario. Alle tre del mattino, il tuo telefono inizia improvvisamente a vibrare. Non è una sveglia, ma una serie di notifiche di allarme: un certo servizio principale è inattivo, provocando una reazione a catena come le tessere del domino, che sta facendo crollare l'intero sistema. Ti alzasti di scatto dal letto e fissasti le abbaglianti curve rosse sul pannello di monitoraggio. C'era solo un pensiero nella tua mente: perché non si è fermato da solo?

Questa è probabilmente la vita quotidiana di un'architettura di microservizi senza interruttori automatici. Nel mondo distribuito creato da Spring Boot, i servizi effettuano chiamate e inviano messaggi ogni giorno. La maggior parte delle volte va tutto bene. Finché un giorno uno dei servizi ha iniziato a rispondere lentamente o semplicemente ha smesso di rispondere a causa della pressione del database, delle fluttuazioni della rete o semplicemente di un bug nascosto nel codice.

Cosa accadrà in questo momento? L'altro servizio non sa che è sbagliato e continua a inviare richieste. Le richieste si accumulano in code, i thread sono occupati e le risorse si esauriscono gradualmente. Un guasto del servizio si diffonde come una malattia infettiva e alla fine paralizza l’intero sistema. Si chiama “effetto valanga”: sembra professionale, ma sembra un incubo tecnico.

Cos'è esattamente un interruttore automatico?

Puoi pensarlo come l'interruttore di sicurezza nella scatola elettrica di casa. Quando il circuito è sovraccarico o cortocircuitato, "scatterà" e interromperà attivamente la corrente per evitare che il filo si surriscaldi o addirittura prenda fuoco. Nei microservizi, un interruttore fa quasi la stessa cosa: quando rileva che il tasso di fallimento di un servizio supera una soglia, si “accende” automaticamente e interrompe le richieste per quel servizio.

Le richieste successive non vengono più inviate al servizio guasto, ma vengono rapidamente respinte o viene restituita una risposta di backup preimpostata (fallback). Il traffico principale del sistema è protetto e non è più ostacolato dal guasto di una linea secondaria. L'interruttore esegue periodicamente un test "semiaperto", tentando segretamente di inviare una o due richieste al servizio di destinazione per vedere se si ripristina. Se ripristinato, l'interruttore si "chiude" automaticamente e il traffico riprende il normale flusso.

L'intero processo non richiede l'intervento manuale alle tre del pomeriggio. Avviene automaticamente, con calma e razionalità.

Perché i progetti Spring Boot ne hanno specificamente bisogno?

Perché Spring Boot semplifica lo sviluppo di microservizi. Alcune righe di annotazioni, una classe di avvio e un servizio sono online. Questa comodità rende inoltre più semplice per tutti costruire reti di chiamate di servizio complesse. Ma l’altro lato della comodità è che esistono anche collegamenti più vulnerabili.

L'interruttore qui non svolge una "funzione", ma un "pensiero resiliente". Riconosce che il fallimento è destinato a verificarsi e non persegue più l’illusione della disponibilità al 100%, ma progetta sistemi che possono ancora mantenere le funzioni principali quando si verificano guasti parziali. La tua applicazione e-commerce potrebbe non essere in grado di completare le transazioni quando il servizio di pagamento è temporaneamente non disponibile, ma è comunque possibile utilizzare funzioni come la navigazione dei prodotti e l'aggiunta ai carrelli. Invece di una pagina di errore completamente vuota o un lungo timeout di attesa, gli utenti vedono "Il sistema di pagamento è occupato, riprova più tardi".

esisterekpowerCosa abbiamo visto nella pratica tecnica?

Alcuni cambiamenti molto pratici. Ad esempio, il sistema di gestione backend di un cliente aveva inizialmente una risposta lenta del servizio ordini durante il periodo della promozione, causando il blocco completo dell'interfaccia di gestione e il servizio clienti non era in grado di gestire alcuna richiesta. Dopo aver effettuato l'accesso alla policy dell'interruttore automatico, l'interfaccia di gestione bloccherà automaticamente alcune richieste di query non essenziali quando il carico del servizio ordini è elevato e darà priorità all'elaborazione dei rimborsi e alle query sugli ordini dei clienti. L'interfaccia potrebbe essere un po' più lenta, ma non si bloccherà mai completamente.

Un altro scenario comune sono le chiamate API di terze parti. Servizi meteorologici, servizi cartografici, gateway SMS: queste non sono cose che mantieni, ma su cui fai affidamento. La loro instabilità è la tua instabilità. L'impostazione dell'interruttore automatico consente di impostare un timeout chiaro e un numero di guasti. Una volta che il servizio di terze parti non soddisfa i requisiti, il sistema passa automaticamente ai dati memorizzati nella cache o ai valori predefiniti statici invece di attendere all'infinito.

Come iniziare a pensarci?

Se non l'hai ancora fatto, inizia con uno dei servizi più sensibili. Chiediti: se questo servizio è lento o inattivo, cosa ne risentirà? Quali servizi che lo chiamano dovrebbero essere protetti?

La configurazione in sé non è complicata. Nell'ecosistema Spring Boot sono disponibili librerie mature per implementare il modello di interruttore. Principalmente devi decidere alcuni parametri: quante volte all'interno di un intervallo di tempo viene considerato un "fallimento"? Dopo aver riacceso l'interruttore, quanto spesso provi a verificare se il servizio è stato ripristinato? Cosa dovrebbe restituire la risposta alternativa: un semplice messaggio di errore o un insieme di dati memorizzati nella cache leggermente obsoleti ma utilizzabili?

Non esistono risposte standard a queste decisioni e dipende da ciò che la tua azienda può tollerare. I servizi finanziari e i servizi di navigazione dei contenuti hanno ovviamente tolleranze diverse.

Lentamente, scoprirai che questo design cambia il modo di pensare della tua squadra. Tutti iniziarono a parlare di “confini di fallimento”, non solo di “confini funzionali”. Il contratto tra servizi, oltre a "cosa restituire in caso di successo", include anche "come gestire il fallimento". La resilienza del sistema viene intrecciata poco a poco.

Dì qualcosa come un frammento di un romanzo

Nel data center a tarda notte, solo le spie dei server lampeggiano regolarmente. Il servizio A invia una richiesta al servizio B, come al solito. Ma questa volta non ci fu risposta. Aspetta, tempo scaduto. L'interruttore aggiunse silenziosamente un segno di spunta al suo contatore. Al quinto fallimento "saltò via" leggermente. Le richieste successive sono come un ruscello che incontra una chiusa e svolta con calma su un altro percorso. Niente allarmi, niente panico. Il processo principale continua come se nulla fosse accaduto. Solo una piccola nota sulla carta di monitoraggio registra questo breve isolamento.

Dopo l'alba, l'ingegnere ha controllato i registri e ha rilevato il picco del servizio B della CPU durante quel periodo. La causa del guasto è stata trovata e riparata. E quando tutto ciò accade, la maggior parte degli utenti non nota nemmeno nulla di insolito. Il sistema si è preso cura di se stesso.

Probabilmente è così che dovrebbe essere la tecnologia: calma, consapevole di sé ed equilibrata nella tempesta.

Fondata nel 2005,kpowerè dedicata a un produttore professionale di unità di movimento compatte, con sede a Dongguan, nella provincia del Guangdong, in Cina. Sfruttando le innovazioni nella tecnologia di azionamento modulare,kpowerintegra motori ad alte prestazioni, riduttori di precisione e sistemi di controllo multiprotocollo per fornire soluzioni di sistemi di azionamento intelligenti efficienti e personalizzate. Kpower ha fornito soluzioni di sistemi di azionamento professionali a oltre 500 clienti aziendali in tutto il mondo con prodotti che coprono vari campi come sistemi domestici intelligenti, elettronica automatica, robotica, agricoltura di precisione, droni e automazione industriale.