Infrastruttura di comunicazione con mesh di servizi
Suggerimento
Questo contenuto è un estratto dell'eBook, Progettazione di applicazioni .NET native del cloud per Azure, disponibile in .NET Docs o come PDF scaricabile gratuitamente che può essere letto offline.
In questo capitolo sono state esaminate le sfide della comunicazione di microservizi. Abbiamo detto che i team di sviluppo devono essere sensibili al modo in cui i servizi back-end comunicano tra loro. Idealmente, meno i servizi comunicano tra loro, meglio è. Tuttavia, l'elusione non è sempre possibile perché i servizi back-end spesso si basano l'uno sull'altro per completare le operazioni.
Sono stati esaminati diversi approcci per implementare la comunicazione HTTP sincrona e la messaggistica asincrona. In ognuno dei casi, lo sviluppatore è gravato dall’implementazione del codice di comunicazione. Il codice di comunicazione è complesso e richiede molto tempo. Le decisioni non corrette possono causare problemi di prestazioni significativi.
Un approccio più moderno alle comunicazioni di microservizio si concentra su una tecnologia nuova e in rapida evoluzione intitolata Service Mesh. Un mesh di servizi è un livello di infrastruttura configurabile con funzionalità predefinite per gestire la comunicazione da servizio a servizio, la resilienza e molte problematiche trasversali. Sposta la responsabilità di questi problemi dai microservizi e nel livello mesh del servizio. La comunicazione viene astratta dai microservizi.
Un componente chiave di una mesh di servizi è un proxy. In un'applicazione nativa del cloud, un'istanza di un proxy viene in genere inserita in un percorso condiviso con ogni microservizio. Mentre vengono eseguiti in processi separati, i due sono strettamente collegati e condividono lo stesso ciclo di vita. Questo modello, noto come modello Sidecar, è illustrato nella figura 4-24.
Figura 4-24. Mesh di servizio con un side car
Si noti nella figura precedente come i messaggi vengono intercettati da un proxy eseguito insieme a ogni microservizio. Ogni proxy può essere configurato con regole di traffico specifiche del microservizio. Comprende i messaggi e può instradarli tra i servizi e il mondo esterno.
Oltre alla gestione della comunicazione da servizio a servizio, Service Mesh offre il supporto per l'individuazione dei servizi e il bilanciamento del carico.
Una volta configurata, una mesh di servizi è altamente funzionale. La mesh recupera un pool corrispondente di istanze da un endpoint di individuazione del servizio. Invia una richiesta a un'istanza del servizio specifica, registrando la latenza e il tipo di risposta del risultato. Sceglie l'istanza più probabile che restituisca una risposta rapida in base a diversi fattori, inclusa la latenza osservata per le richieste recenti.
Una mesh di servizi gestisce il traffico, la comunicazione e le problematiche di rete a livello di applicazione. Comprende messaggi e richieste. Una mesh di servizi si integra in genere con un agente di orchestrazione del contenitore. Kubernetes supporta un'architettura estendibile in cui è possibile aggiungere una mesh di servizi.
Nel capitolo 6 vengono approfondite le tecnologie di Service Mesh, tra cui una discussione sull'architettura e sulle implementazioni open source disponibili.
Riepilogo
In questo capitolo sono stati illustrati i modelli di comunicazione nativi del cloud. Si è iniziato esaminando il modo in cui i client front-end comunicano con i microservizi back-end. Nel corso della procedura sono stati illustrate le piattaforme del gateway API e la comunicazione in tempo reale. Si è quindi esaminato il modo in cui i microservizi comunicano con altri servizi back-end. Sono stati esaminati sia la comunicazione HTTP sincrona che la messaggistica asincrona tra i servizi. Abbiamo trattato gRPC, una tecnologia futura nel mondo nativo del cloud. Infine, è stata introdotta una tecnologia nuova e in rapida evoluzione intitolata Service Mesh che consente di semplificare la comunicazione di microservizi.
Particolare attenzione è stata rivolta ai servizi di Azure gestiti che consentono di implementare la comunicazione nei sistemi nativi del cloud:
- Gateway applicazione di Azure
- Gestione API di Azure
- Servizio Azure SignalR
- Code di Archiviazione di Azure
- Bus di servizio di Azure
- Griglia di eventi di Azure
- Hub eventi di Azure
Passiamo quindi ai dati distribuiti nei sistemi nativi del cloud e ai vantaggi e alle sfide che presenta.
Riferimenti
Commenti e suggerimenti
Presto disponibile: Nel corso del 2024 verranno gradualmente disattivati i problemi di GitHub come meccanismo di feedback per il contenuto e ciò verrà sostituito con un nuovo sistema di feedback. Per altre informazioni, vedere https://aka.ms/ContentUserFeedback.
Invia e visualizza il feedback per