Quando i microservizi iniziano a "nascondere": come fare in modo che le prestazioni non siano più nascoste?

Ricordi quel progetto dell'ultima volta? Alle tre del mattino, il server ha improvvisamente rallentato fino a rallentare, ma il grafico di monitoraggio era abbastanza tranquillo e verde da innervosire le persone. Il team ha frugato nei registri e solo all'alba ha scoperto che una catena di chiamate tra microservizi era segretamente "in sciopero". Questo genere di cose è come una perdita d'acqua in casa. La cosa più problematica è sentire il ticchettio ma non trovarne la fonte.

I microservizi scompongono il sistema e spezzettano il problema. Una certa interfaccia risponde improvvisamente lentamente, forse attraverso cinque o sei livelli di servizi; la memoria perde silenziosamente e quando viene scoperta ha interessato tre moduli. Ciò che è ancora più problematico è che gli strumenti di monitoraggio tradizionali spesso si concentrano su un singolo nodo, ma non riescono a vedere chiaramente dove si blocca la “conversazione” tra i servizi.

Dove è finita la performance?

Incontriamo spesso questa situazione: gli utenti lamentano che la pagina si carica lentamente, ma i dati della CPU e della memoria sono normali. Cosa fare in questo momento? ——Devi guardare il problema da un'altra angolazione. Nell’architettura dei microservizi, i veri colli di bottiglia sono spesso nascosti negli spazi tra le interazioni dei servizi. Una chiamata API può passare attraverso il gateway, il servizio di autenticazione, il modulo aziendale, il database e quindi la cache. Se un collegamento starnutisce, l'intero collegamento potrebbe prendere il raffreddore.

Pertanto, il monitoraggio non può solo misurare la temperatura corporea, ma richiede anche un “esame completo del corpo”. È necessario vedere il percorso completo della richiesta dall'ingresso all'uscita e sapere in quale corridoio e stanza si trascorre il tempo. È come fare una radiografia del sistema, tutte le ossa e le vene devono essere pulite.

Lascia che il monitoraggio "veda" di più

Cosa fa un buon strumento di monitoraggio? Deve scoprire automaticamente le dipendenze tra i servizi. Senza configurazione manuale, è possibile tracciare un diagramma della topologia delle chiamate: quale servizio chiama chi, con quale frequenza e qual è il tempo di risposta. Quando un certo collegamento rallenta, è possibile localizzare immediatamente le aree di impatto a monte e a valle.

Essere in grado di tracciare l'intero percorso di una singola richiesta. Assegna a ciascuna richiesta un "numero di passaporto" univoco che lascia un timbro mentre passa attraverso ciascun servizio. In questo modo, non importa quanta distanza percorre la richiesta o quanti giri faccia, il suo percorso e la sua distribuzione temporale possono essere completamente riprodotti. In quale punto di timbratura si verifica il ritardo improvviso? È chiaro a colpo d'occhio.

Inoltre, i dati devono essere in tempo reale. Aspetti il ​​rapporto tra un'ora? La colpa potrebbe essersi diffusa. Un buon sistema di monitoraggio dovrebbe essere come il cruscotto di un'auto. La velocità, il livello del carburante e la temperatura dell'acqua possono essere visualizzati in qualsiasi momento e le luci si accenderanno immediatamente in caso di anomalie. Ancora più importante, i dati devono essere correlati: le query lente sul database hanno causato timeout del servizio? L'invalidazione della cache ha innescato una reazione a catena?

Evitate queste trappole nella pratica

Abbiamo visto molti team cadere in trappole simili: monitorano solo gli indicatori hardware e ignorano le prestazioni del livello applicativo; i tronchi sono sparsi ovunque e puoi trovare un ago in un pagliaio quando c'è un problema; troppi allarmi diventano un "lupo che piange" e nessuno presta attenzione ai veri fallimenti.

Gli approcci efficaci sono spesso semplici: iniziare il monitoraggio dalle principali interfacce aziendali ed espanderlo gradualmente all’intero collegamento; impostare soglie intelligenti per evitare falsi allarmi causati da valori statici; stabilire livelli di riferimento prestazionali per individuare i primi segnali di deviazione dalla normalità. A volte, il tempo di risposta del 99° percentile di un servizio aumenta silenziosamente di 200 millisecondi: questo potrebbe essere un segnale precoce di un grave errore e ha un valore di avviso più precoce di un improvviso aumento della CPU al 100%.

Diverse considerazioni nella scelta

Quando valuti una soluzione di monitoraggio, chiediti: può identificare automaticamente le relazioni di servizio? Quanto codice deve essere modificato per tracciare il collegamento? La visualizzazione dei dati è sufficientemente chiara per comprendere il problema a colpo d'occhio? Le regole di allarme sono sufficientemente flessibili da distinguere tra piccole fluttuazioni al mattino presto e gravi malfunzionamenti durante il giorno?

Alcuni strumenti sembrano essere perfettamente funzionanti, ma sono complessi da implementare e richiedono diversi giorni di manutenzione ogni mese; altri sono leggeri e flessibili e si concentrano sulla risoluzione dei problemi principali di visibilità. La chiave è trovare quell’equilibrio, andando abbastanza in profondità per vedere la natura del problema, ma non così pesante da diventare un nuovo fardello.

L’arte dell’osservazione nell’era dei microservizi

Dopotutto, il monitoraggio dei microservizi non riguarda l’accumulo di dati, ma la creazione di una capacità di osservazione. Rende visibile il comportamento invisibile del sistema, consentendo ai team di rilevare i problemi prima che abbiano un impatto sugli utenti. È come dotare un complesso dispositivo meccanico di una rete di sensori, dove la rotazione di ogni ingranaggio e la tensione di ogni connessione diventano un segnale leggibile.

Quando possiamo vedere chiaramente ogni stretta di mano e ogni conversazione tra servizi, il sistema non è più una scatola nera. Inizierai a notare modelli interessanti: il tempo di risposta del servizio ordini aumenterà leggermente ogni venerdì pomeriggio perché il servizio di inventario associato genera un report settimanale; oppure un servizio downstream impiegherà dieci minuti per "riscaldarsi" dopo ogni nuova versione.

Queste informazioni spesso portano a approfondimenti più approfonditi: forse la regolazione dell'ordine delle chiamate può ridurre la latenza del 30%; oppure aggiungere una semplice cache a un servizio può alleviare la pressione sull'intero collegamento.

Nel mondo dei microservizi, i problemi prestazionali non sono più un punto di fallimento, ma si ripercuotono su una rete. Trovare il modo giusto di guardare significa poter lisciare delicatamente l'acqua prima che le increspature si diffondano. Dopotutto, la migliore risoluzione dei problemi è impedire che ciò accada.

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.kpowerha 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.