Rilevamento dei servizi come procedura necessaria per l’esecuzione corretta di un’applicazione. La premessa è che l’architettura dei microservizi è particolarmente adatta per applicazioni complesse e di lunga durata che richiedono notevoli risorse e esigenze di gestione. Un’applicazione basata su microservizi è costituita da una granularizzazione della programmazione che consente:
- massima interoperabilità
- migliore scalabilità
- manutenzione più semplice
- distribuzione senza soluzione di continuità
Rilevamento dei servizi: come funziona e a che cosa serve
Per funzionare in modo efficiente, i servizi devono essere interallacciati a una rete di elaborazione delle richieste. È qui che entra in gioco il rilevamento dei servizi. Perché è necessario?
Quando si lavora su applicazioni basate su microservizi, in fase di esecuzione potrebbe essere necessario modificare il numero di istanze di microservizi in base al carico sul servizio. Ridimensionamento automatico, errori o aggiornamenti del servizio, infatti, possono modificare la portata. È necessario assicurarsi che i servizi dipendenti siano a conoscenza di queste istanze.
Il numero di istanze di un microservizio può variare. Se questi microservizi risiedono su server fisici a cui un team di sviluppo ha accesso, è possibile utilizzare un file di configurazione per assicurarsi che altri servizi conoscano la quantità di servizi esistenti in qualsiasi momento. Attenzione però: a causa di possibili percorsi di rete dinamici, nel cloud può essere difficile tenere traccia del numero di servizi. Il rilevamento del servizio nei microservizi aiuta queste istanze del servizio ad adattare e distribuire il carico tra i microservizi di conseguenza.
Nel rilevamento del servizio bisogna considerare tre componenti:
- Il fornitore di servizi, che fornisce servizi su una rete
- Il registro di servizio, ovvero un database che contiene le posizioni delle istanze di servizio disponibili.
- Consumatore del servizio, che recupera la posizione del fornitore di servizi dal registro dei servizi e quindi parla con l’istanza del servizio.
I dati che risiedono nel registro dei servizi devono essere sempre aggiornati in modo che i client (gli altri microservizi) possano rilevare le istanze del servizio in fase di esecuzione. Quando il registro dei servizi non è attivo impatta negativamente sia sui fornitori di servizi che sui consumatori. Per evitare il problema, le aziende come registro di servizio utilizzano in genere un database distribuito come, ad esempio, Apache ZooKeeper.
Modelli di rilevamento del servizio
Esistono essenzialmente due principali modelli di rilevamento del servizio: rilevamento lato client e rilevamento lato server. Diamo un’occhiata a ciò che ciascuno comporta.
Modello di rilevamento lato client
In questo modello, il consumatore del servizio (noto anche come client del servizio o client) cerca nel registro dei servizi per individuare un fornitore di servizi, seleziona un’istanza di servizio appropriata e disponibile utilizzando un algoritmo di bilanciamento del carico e quindi effettua una richiesta. La posizione dell’istanza del servizio è registrata nel registro del servizio al momento del suo avvio. Non appena l’istanza del servizio viene terminata, queste informazioni vengono eliminate dal registro del servizio.
Il modello è relativamente semplice da comprendere e può facilmente prendere decisioni intelligenti di bilanciamento del carico perché l’utente del servizio è a conoscenza delle istanze di servizio disponibili.
Si noti che in questo modello, il servizio di rilevamento può o meno essere collocato dietro un gateway API. Se non si trova dietro un gateway API è necessario reimplementare il bilanciamento, l’autenticazione e altre attività correlate al servizio di rilevamento.
Un grave svantaggio di questo modello è che il consumatore del servizio e il registro del servizio sono strettamente collegati, il che significa che è necessario implementare la logica richiesta per il rilevamento del servizio sul lato client per ciascun linguaggio di programmazione che è possibile utilizzare. Dal momento che l’architettura dei microservizi è un insieme di tecnologie, strumenti, framework e linguaggi disparati, la gestione delle applicazioni diventa sempre più complessa.
Modello di rilevamento lato server
In questo modello, gli utenti del servizio lato client non sono a conoscenza del registro dei servizi ed effettuano richieste tramite un router. Il router cerca nel registro di servizio e, una volta trovata l’istanza di servizio applicabile, procede a inoltrare la richiesta. Il client non deve preoccuparsi della scoperta del servizio e del bilanciamento del carico mente il gateway API può selezionare l’endpoint giusto per una richiesta sul lato client.
Un vantaggio principale del modello di rilevamento lato server è che è indipendente dal linguaggio e dal framework. Tuttavia, l’ambiente di distribuzione dovrebbe fornire il bilanciamento del carico e dovrebbe essere altamente disponibile. Gli esperti suggeriscono di gestirlo e replicarlo in modo appropriato tenendo conto della disponibilità e della capacità.
Modelli di registrazione del servizio
Il modello di registrazione del servizio è costituito da due sottoschemi:
- Schema di autoregistrazione: l’istanza del servizio registra il proprio indirizzo con il registro del servizio e il servizio si cancella automaticamente dal registro non appena termina l’istanza.
- Modello di registrazione di terze parti: le istanze del servizio non si registrano o si cancellano da sole. Piuttosto, il processo di registrazione è gestito da un componente di sistema chiamato service
Una volta terminato un servizio, va ricordato sempre che potrebbe non cancellarsi in maniera automatica. Il che significa che se un consumatore di servizi cerca un’istanza di questo servizio nel registro, riceverà un errore di indirizzo non valido. Per evitarlo, il fornitore di servizi dovrebbe connettere i propri servizi con il registro a intervalli di tempo regolari e specifici per dimostrare che il servizio è ancora operativo. Il registro dei servizi può quindi annullare la registrazione di un servizio se il provider non ha inviato una risposta dopo un determinato lasso di tempo.
