Quando i tuoi microservizi iniziano a "nascondere e cercare": risolvi i problemi di individuazione dei servizi

Immagina questo: gestisci un bar affollato. Alle otto del mattino è arrivata la folla. La cassiera deve chiamare il barista, il barista deve sapere dov'è il frigorifero del latte e il personale delle pulizie deve essere reperibile. Ma cosa succede se nessuno sa dove si trova l'altro? I cassieri urlano gli ordini nell'aria, i baristi si aggirano sullo sfondo alla ricerca di fagioli: l'intero sistema va rapidamente in tilt.

Questo è quasi ciò che appare in un'architettura di microservizi quando un servizio rileva un problema.

Potresti avere una dozzina o addirittura centinaia di piccoli servizi in esecuzione in background, ciascuno responsabile di una piccola funzionalità. Il servizio ordini deve contattare il servizio di pagamento e il servizio utente deve contattare il motore di raccomandazione... Come fanno a sapere dove si trova l'altro? Soprattutto quando un servizio viene improvvisamente riavviato o esteso a una nuova macchina? Il vecchio approccio, ad esempio codificando gli indirizzi nei file di configurazione, è come fornire una tabella dei posti fissa a ciascun dipendente. Ma cosa succede se qualcuno cambia posizione? Oppure sono state aggiunte temporaneamente nuove persone? L'orologio è diventato immediatamente inutilizzabile.

Perché questo è un mal di testa?

L'ho riscontrato io stesso. Quando il sistema è stato costruito per la prima volta, è stato utilizzato solo un semplice elenco di configurazione. I primi due mesi furono tranquilli. Successivamente, con l'aumento del volume d'affari, abbiamo iniziato ad espandere dinamicamente alcuni servizi. All'improvviso, la probabilità che gli utenti non riuscissero a effettuare un ordine è aumentata silenziosamente. I registri sono pieni di errori di "connessione rifiutata": non è che il servizio sia inattivo, ma che il chiamante sta ancora tentando di connettersi al vecchio indirizzo. Quel servizio è stato ovviamente spostato sul nuovo server, ma altre parti non lo sanno.

Ancora più problematico è il bilanciamento del carico. Anche se conosci gli indirizzi di tutti i servizi, come distribuisci ragionevolmente il traffico? Lasciare che le nuove richieste vadano sempre all'istanza più occupata? Non è una mossa saggia.

Ciò porta alla domanda fondamentale: in un ambiente in continua evoluzione, come possono i servizi trovarsi automaticamente tra loro e allocare i compiti in modo intelligente?

Un sistema di directory più "vivo".

Il metodo tradizionale è come un elenco telefonico, che non può essere modificato una volta stampato. Ciò che serve ora è più simile a un'app di comunicazione interna che si aggiorni in tempo reale: registri automaticamente qualcuno quando è online e lo rimuova immediatamente quando va offline. Può anche dirti facilmente chi è libero in questo momento.

Questo è ciò che fa il meccanismo di rilevamento dei servizi. Di solito è composto da due parti: un registro di servizio affidabile (come un elenco dinamico) e un meccanismo di rilevamento (che consente ai servizi di interrogare questo elenco).

Come funziona esattamente? Quando un microservizio si avvia, si reca al centro di registrazione per "fare il check-in": "Ciao, sono qui, questo è l'indirizzo, cosa posso fare." Il centro di registrazione lo annota. Quando altri servizi hanno bisogno di trovarlo, vanno al registro e chiedono: "Chi può gestire i pagamenti?" Il registro restituisce un elenco degli indirizzi attualmente disponibili. Il chiamante di solito aggiunge anche un livello di memorizzazione nella cache locale e controlli sanitari per evitare di dover andare lontano per chiedere ogni volta.

In questo modo, anche se il servizio di pagamento si sposta da un server all'altro, purché effettui nuovamente il check-in nella nuova sede, gli altri servizi riceveranno il nuovo indirizzo la prossima volta che lo richiederanno. L'intero sistema "vive".

Costruire questo ponte nel mondo Java

Esistono diversi strumenti comuni per implementare questo insieme di logica in Java. Netflix Eureka, ad esempio, è progettato per essere leggero e il servizio può essere facilmente registrato e scoperto. Per quanto riguarda Consul, oltre al rilevamento dei servizi, viene fornito anche con il controllo dello stato e l'archiviazione di valori-chiave, che ha più funzioni. ZooKeeper è apparso prima ed è stabile, ma richiede un piccolo sforzo per la configurazione.

Cosa considerare nella scelta? La familiarità con la squadra è importante. C'è anche il supporto della comunità: quando incontri una trappola, puoi trovare molte informazioni? Si adatta al tuo stack tecnologico? Ad esempio, la famiglia Spring Cloud si trova molto a suo agio nell'integrare Eureka. Se stai utilizzando Spring Boot, questo percorso potrebbe essere più agevole.

Ma non importa quale scegli, alcuni modelli di base sono gli stessi. Il tuo servizio deve integrarsi con la libreria client per inviare periodicamente heartbeat per dire "Sono ancora vivo". Il chiamante deve decidere come scegliere: scegliere un'istanza a caso o ruotarla? Oppure scegli quello più veloce in base alla velocità di risposta? Questa parte della logica è spesso nascosta nel codice.

Evita le trappole comuni

Quando inizi, è facile cadere in diverse trappole. Ad esempio, la situazione del servizio offline non è stata gestita bene. Un servizio si blocca, ma il registro non lo ha espulso dall'elenco. Altri servizi potrebbero comunque inviare richieste fino allo scadere del tempo. Ciò richiede l'impostazione di intervalli e timeout ragionevoli per il controllo dello stato sul client o sul centro di registrazione.

C'è anche il problema della coerenza della cache. Per motivi di prestazioni, i client in genere memorizzano nella cache l'elenco dei servizi. Tuttavia, se la cache non viene aggiornata in tempo, la richiesta potrebbe essere inviata a un'istanza che era offline. L'impostazione di una strategia di aggiornamento della cache adeguata è un piccolo sforzo che non può essere risparmiato.

È necessario considerare anche il partizionamento della rete. Se il centro di registrazione stesso fallisce o la rete viene disconnessa, i servizi verranno interrotti? Una buona progettazione prevede un meccanismo di tolleranza agli errori, ad esempio il client che si affida alla cache locale per sopravvivere a brevi periodi di errore.

Da utile a utile: sii più intelligente

Una volta impostato il meccanismo di rilevamento di base, il sistema può essere convertito. Ma se vuoi renderlo più robusto, puoi pensare a un ulteriore passo. Ad esempio, aggiungi un meccanismo di interruzione del circuito. Quando un'istanza del servizio fallisce continuamente, rimuovila temporaneamente dall'elenco dei candidati e concedigli un po' di tempo per riprendersi invece di lasciare che tutte le richieste continuino a raggiungerla.

Puoi anche eseguire un po' di bilanciamento del carico. Invece del semplice polling, il traffico viene allocato in base al carico effettivo dell'istanza (come CPU, tempo di risposta). Lasciamo che le macchine inattive lavorino di più e quelle indaffarate prendano una pausa.

Naturalmente il monitoraggio è indispensabile. Controlla lo stato della registrazione, la percentuale di successo delle chiamate e le modifiche dei ritardi di ciascun servizio. Se c'è qualche problema con questi numeri, sarai in grado di rilevarlo presto.

Quindi, torniamo alla domanda originale

Perché non lasciare che i microservizi giochino a "nascondino"? La chiave è utilizzare un centro dinamico per registrare le loro tracce e consentire loro di sviluppare l’abitudine di effettuare check-in e interrogazioni in modo proattivo. Allontanati dagli elenchi statici e codificati per passare a un sistema di scoperta dinamico e adattabile. Questo cambiamento costituisce quasi la base per la creazione di un'architettura di microservizi elasticamente scalabile.

Anche i vantaggi che comporta sono reali: funzionamento e manutenzione sono privi di preoccupazioni e non è necessario modificare manualmente una serie di configurazioni quando il servizio viene ampliato o ridotto; il sistema è più stabile e le istanze difettose possono essere isolate in tempo; è anche più semplice eseguire rilasci di versioni e test in scala di grigi: puoi registrare tranquillamente una nuova versione del servizio e lasciare che solo una parte del traffico venga deviata per provarla.

E il percorso di implementazione? Nell'ecosistema Java hai ruote già pronte tra cui scegliere. Dalla valutazione dei requisiti, alla selezione, all'integrazione e all'implementazione, fino all'evitare le insidie ​​iniziali. Passo dopo passo, il gioco del "nascondino" che una volta ti faceva venire il mal di testa diventerà una rete di collaborazione ben organizzata.

Proprio come prendersi cura del metodo di comunicazione dei dipendenti in un bar, gli ordini fluiranno in modo naturale, i clienti saranno soddisfatti e non dovrai essere impegnato come fattorino tutto il giorno. Il sistema si prende cura di se stesso, ecco come dovrebbero essere i microservizi.

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.