Cerca

Italiano

Accedi Account

Accedi / Registrati Account

Website

Microservizi

Cos'è una service mesh?

Una service mesh consente di controllare in che modo le diverse componenti di un'applicazione condividono i dati. A differenza di altri sistemi per la gestione della comunicazione tra i servizi, una service mesh costituisce un livello infrastrutturale integrato direttamente nell'app. Tale livello visibile è in grado di documentare la qualità dell'interazione tra le sue varie componenti, ottimizzando la comunicazione ed evitando i tempi di inattività dovuti all'espansione dell'app stessa.

Ogni parte o "servizio" di un'applicazione si affida ad altri servizi per offrire agli utenti ciò che desiderano. Ad esempio, se un utente di un'app di ecommerce vuole acquistare un prodotto, i servizi devono sapere se quell'articolo è disponibile in magazzino. Il servizio che comunica con il database dell'inventario dell'azienda deve quindi interagire con la pagina web del prodotto, che a sua volta deve interagire con il carrello online dell'utente. Per incrementare il valore aziendale, il rivenditore deve creare un servizio che offre agli utenti consigli sui prodotti in app. Questo nuovo servizio comunicherà con un database di tag di prodotti al fine di fornire consigli, ma dovrà comunicare anche con lo stesso database dell'inventario di cui aveva bisogno la pagina del prodotto. Ciò crea uno scambio continuo tra le componenti.

Le applicazioni moderne sono spesso scomposte in una rete di servizi, ognuno dei quali svolge una specifica funzione. Per poter svolgere la sua funzione, un servizio potrebbe aver bisogno di richiedere dati da diversi altri servizi. Cosa accade però se alcuni servizi vengono sovraccaricati dalle richieste di dati da altri servizi, come nel caso del database dell'inventario del rivenditore? Per gestire tale sovraccarico, ci si avvale di una service mesh, che reindirizza le richieste da un servizio all'altro bilanciando il carico complessivo di tutti gli elementi.


Microservizi e service mesh: le differenze

Un'architettura a microservizi permette agli sviluppatori di apportare modifiche ai servizi di un'app senza doverla redistribuire in toto. A differenza dello sviluppo di app in altri tipi di architetture, i singoli microservizi sono creati da piccoli team che hanno la possibilità di scegliere quali strumenti e quali linguaggi di codifica usare. Sostanzialmente, i microservizi pur comunicando tra loro sono totalmente indipendenti. Ciò significa che il mancato funzionamento di uno di loro, non comporta il mancato funzionamento dell'intera applicazione.

La comunicazione service to service è indispensabile per il funzionamento dei microservizi. La logica alla base della comunicazione può essere codificata in ogni servizio senza che sia necessaria la presenza di una service mesh. Tuttavia, una service mesh diventa utile quando la comunicazione inizia a diventare più complessa. Per le applicazioni cloud native integrate in un'architettura a microservizi, una service mesh consente di includere un numero elevato di servizi "piccoli" in un'applicazione funzionale.


Come funziona?

Una service mesh non introduce nuove funzionalità nell'ambiente di runtime di un'applicazione, infatti le applicazioni di qualsiasi tipo di architettura hanno sempre avuto bisogno di regole che specifichino in che modo le richieste si muovono da un punto all'altro. Una service mesh, però, estrapola la logica che regola la comunicazione service to service dai singoli servizi e la astrae in un livello dell'infrastruttura.

Questo è il motivo per cui una service mesh è integrata in un'app come un serie di proxy di rete. I proxy sono un concetto familiare all'IT di livello enterprise. Se hai effettuato l'accesso a questa pagina web da un computer sul posto di lavoro, è molto probabile che tu ne abbia appena usato uno:

  1. quando hai effettuato la richiesta di accesso a questa pagina, la richiesta è stata ricevuta dal web proxy della tua azienda.
  2. Dopo aver superato le misure di sicurezza del proxy, è stata inviata al server che ospita questa pagina.
  3. Successivamente, questa pagina è stata restituita al proxy e ricontrollata rispetto alle misure di sicurezza.
  4. Infine il proxy ha provveduto a inviartela.

In una service mesh, le richieste sono indirizzate tra i microservizi attraverso proxy presenti nel livello dell'infrastruttura. Ecco perché i singoli proxy che compongono una service mesh sono a volte chiamati "sidecar": si muovono a fianco di ogni servizio, anziché al loro interno. Tutti questi proxy "sidecar", disaccoppiati da ogni servizio, formano insieme una rete di mesh.

Un proxy sidecar affianca un microservizio e indirizza le richieste ad altri proxy. Tutti insieme, questi proxy sidecar formano una rete di mesh.

Senza una service mesh, ogni microservizio deve essere codificato mediante una logica che regoli la comunicazione service to service. Ciò impedisce agli sviluppatori non solo di dedicarsi agli obiettivi aziendali, ma anche di diagnosticare eventuali problemi di comunicazione, poiché la logica che regola la comunicazione tra i servizi è nascosta all'interno di ogni servizio.


Comunicazione ottimizzata grazie alla service mesh

Ogni nuovo servizio che viene aggiunto a un'app, oppure ogni nuova istanza di un servizio esistente eseguita in un container, rende più complesso l'ambiente in cui avviene la comunicazione e introduce nuovi possibili errori. Individuare il punto in cui si sono verificati dei problemi all'interno di un'architettura a microservizi complessa può diventare pressoché impossibile senza la presenza di una service mesh.

La service mesh, infatti, è in grado di acquisire ogni aspetto della comunicazione da servizio a servizio sotto forma di parametri prestazionali. Nel tempo, i dati messi a disposizione dalla service mesh possono essere applicati alle regole che governano la comunicazione tra i servizi, migliorando l'efficienza e l'affidabilità delle richieste di servizio.

Ad esempio, nel caso in cui un servizio non funzioni correttamente, una service mesh può raccogliere i dati sul tempo intercorso prima che un altro tentativo vada a buon fine. Grazie all'aggregazione dei dati sui tempi di errore di un determinato servizio, è possibile scrivere regole che determinino i tempi di attesa ottimali prima di ritentare quel servizio, assicurandosi che il sistema non sia sovraccaricato da tentativi inutili.


Prevedere scenari futuri per poterli gestire

Se stai creando dei microservizi, probabilmente hai riscontrato delle esigenze specifiche durante la progettazione, tra cui sfruttare una scalabilità in tempi rapidi e aggiungere nuove funzioni per soddisfare le esigenze aziendali. È probabile che, dal lancio, la tua architettura a microservizi sia cambiata notevolmente. All'inizio, le librerie integrate nei microservizi potrebbero riuscire a gestire la comunicazione da servizio a servizio con un'interruzione minima delle operazioni. Ma nel lungo periodo questo scenario non può rimanere invariato, in particolar modo se si sta sfruttando una sempre maggiore scalabilità e si stanno aggiungendo altre funzioni. I servizi risultano sovraccaricati dalle numerose richieste e gli sviluppatori dedicano sempre più tempo a decodificare la logica di richiesta per ogni servizio, cosa che porterà a dover gestire nuove criticità.

Con una service mesh:

  • Gli sviluppatori possono dedicarsi a incrementare il valore aziendale, anziché a connettere i servizi.
  • La logica di richiesta forma un livello di infrastruttura visibile a fianco dei servizi, semplificando l'individuazione e la diagnosi di eventuali criticità.
  • Le app resistono meglio ai tempi di inattività, poiché una service mesh è in grado di reindirizzare le richieste allontanandole dai servizi non funzionanti.
  • I parametri prestazionali possono suggerire modi per ottimizzare la comunicazione nell'ambiente di runtime.

Scopri gli altri vantaggi offerti dalle service mesh