Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Suggerimento
Questo contenuto è un estratto dell'eBook Architecting Cloud Native .NET Applications for Azure, disponibile in .NET Docs o come PDF scaricabile gratuito che può essere letto offline.
In questo libro è stato adottato un approccio architetturale basato su microservizi. Anche se tale architettura offre vantaggi importanti, presenta molte sfide:
Comunicazione di rete out-of-process. Ogni microservizio comunica tramite un protocollo di rete che introduce congestione della rete, latenza e errori temporanei.
Individuazione dei servizi. In che modo i microservizi individuano e comunicano tra loro durante l'esecuzione in un cluster di computer con i propri indirizzi IP e porte?
Resilienza. Come si gestiscono gli errori di breve durata e si mantiene stabile il sistema?
Bilanciamento del carico. In che modo il traffico in ingresso viene distribuito tra più istanze di un microservizio?
Sicurezza. In che modo vengono applicati problemi di sicurezza, ad esempio la crittografia a livello di trasporto e la gestione dei certificati?
Monitoraggio distribuito. - Come si correla e si acquisisce la tracciabilità e il monitoraggio per una singola richiesta tra più microservizi che utilizzano?
È possibile risolvere questi problemi con librerie e framework diversi, ma l'implementazione può essere costosa, complessa e dispendiosa in termini di tempo. Si finisce anche con problemi di infrastruttura associati alla logica di business.
Mesh del servizio
Un approccio migliore è una tecnologia in evoluzione intitolata Service Mesh. Una mesh di servizi è un livello di infrastruttura configurabile con funzionalità predefinite per gestire la comunicazione del servizio e le altre sfide indicate in precedenza. Separa questi problemi spostandoli in un proxy di servizio. Il proxy viene distribuito in un processo separato (denominato sidecar) per fornire l'isolamento dal codice aziendale. Tuttavia, il sidecar è collegato al servizio, viene creato con esso e condivide il ciclo di vita. La figura 6-7 illustra questo scenario.
Figura 6-7. Mesh di servizio con un'auto laterale
Nella figura precedente si noti come il proxy intercetta e gestisce la comunicazione tra i microservizi e il cluster.
Una mesh di servizi è suddivisa logicamente in due componenti diversi: un piano dati e un piano di controllo. La figura 6-8 mostra questi componenti e le relative responsabilità.
Figura 6-8. Controllo mesh di servizio e piano dati
Una volta configurata, una mesh di servizi è altamente funzionale. Può recuperare un pool corrispondente di istanze da un endpoint di individuazione del servizio. La mesh può quindi inviare una richiesta a un'istanza specifica, registrando la latenza e il tipo di risposta del risultato. Una mesh può scegliere l'istanza più probabile che restituisca una risposta veloce in base a molti fattori, inclusa la latenza osservata per le richieste recenti.
Se un'istanza non risponde o non riesce, la mesh ritenta la richiesta in un'altra istanza. Se restituisce errori, una mesh rimuoverà l'istanza dal pool di bilanciamento del carico e la riristabilirà dopo la guarigione. Se si verifica il timeout di una richiesta, una mesh può avere esito negativo e quindi ripetere la richiesta. Una mesh acquisisce e genera metriche e traccia distribuita in un sistema di metriche centralizzato.
Istio e Envoy
Sebbene esistano attualmente alcune opzioni di mesh del servizio, Istio è il più popolare al momento della stesura di questo articolo. Istio è una joint venture di IBM, Google e Lyft. Si tratta di un'offerta open source che può essere integrata in un'applicazione distribuita nuova o esistente. La tecnologia offre una soluzione coerente e completa per proteggere, connettere e monitorare i microservizi. Le sue funzionalità includono:
- Proteggere la comunicazione da servizio a servizio in un cluster con autenticazione e autorizzazione basate su identità complesse.
- Bilanciamento del carico automatico per il traffico HTTP, gRPC, WebSocket e TCP.
- Controllo con granularità fine del comportamento del traffico con regole di gestione avanzate, tentativi, failover e inserimento di errori.
- Un livello di criteri collegabile e un'API di configurazione che supportano i controlli di accesso, i limiti di velocità e le quote.
- Metriche, log e tracce automatiche per tutto il traffico all'interno di un cluster, inclusi ingresso e uscita del cluster.
Un componente chiave per un'implementazione di Istio è un servizio proxy intitolato il proxy Envoy. Viene eseguito insieme a ogni servizio e fornisce una base indipendente dalla piattaforma per le funzionalità seguenti:
- Individuazione dinamica dei servizi.
- Bilanciamento del carico.
- Terminazione TLS.
- Proxy HTTP e gRPC.
- Resilienza dell'interruttore.
- Controlli di integrità.
- Aggiornamenti in sequenza con distribuzioni canary .
Come illustrato in precedenza, Envoy viene distribuito come sidecar in ogni microservizio nel cluster.
Integrazione con i servizi Azure Kubernetes
Il cloud di Azure abbraccia Istio e offre supporto diretto per il cloud all'interno dei servizi Azure Kubernetes. I collegamenti seguenti consentono di iniziare:
Riferimenti
Collabora con noi su GitHub
L'origine di questo contenuto è disponibile in GitHub, in cui è anche possibile creare ed esaminare i problemi e le richieste pull. Per ulteriori informazioni, vedere la guida per i collaboratori.
