E ancora, benvenuti!.. In vista dell'inizio del corso abbiamo preparato un'altra traduzione utile.
Il Service Mesh è un livello infrastrutturale configurabile con bassa latenza, necessario per gestire un elevato volume di comunicazioni di rete tra i vari interfacce di programmazione delle applicazioni (API). Il Service Mesh garantisce comunicazioni rapide, affidabili e sicure tra servizi containerizzati e spesso effimeri nell'infrastruttura delle applicazioni. Il Service Mesh offre funzionalità come la scoperta dei servizi, il bilanciamento del carico, la crittografia, la trasparenza, il tracciamento, l'autenticazione e l'autorizzazione, oltre al supporto per il modello di interruzione automatica (circuit breaker).
Il Service Mesh è generalmente implementato fornendo a ciascun istanza di servizio un'istanza di proxy chiamata Sidecar. gestisce le comunicazioni tra i servizi, esegue monitoraggi e risolve i problemi di sicurezza, ovvero tutto ciò che può essere astratto dai singoli servizi. In questo modo, gli sviluppatori possono scrivere, mantenere e gestire il codice dell'applicazione nei servizi, mentre gli amministratori di sistema possono lavorare con il Service Mesh e avviare l'applicazione.
Istio, sviluppato da Google, IBM e Lyft, è attualmente l'architettura Service Mesh più nota. Kubernetes, originariamente sviluppato in Google, è ora l'unico framework per l'orchestrazione dei container supportato da Istio. I fornitori stanno tentando di creare versioni commerciali supportate di Istio. È interessante vedere cosa di nuovo riusciranno ad apportare al progetto open source.
Tuttavia, Istio non è l'unica opzione, poiché sono in fase di sviluppo anche altre implementazioni del Service Mesh. Il modello sidecar proxy è la realizzazione più popolare, come dimostrano i progetti Buoyant, HashiCorp, Solo.io e altri. Esistono anche architetture alternative: l'insieme tecnologico di Netflix è uno degli approcci in cui la funzionalità di Service Mesh è realizzata tramite librerie come Ribbon, Hysterix, Eureka, Archaius, oltre a piattaforme come Azure Service Fabric.
Service Mesh ha anche una propria terminologia per componenti e funzioni di servizio:
- Framework di orchestrazione dei container. Man mano che sempre più container vengono aggiunti all'infrastruttura dell'applicazione, sorgere la necessità di uno strumento separato per il monitoraggio e la gestione dei container – il framework di orchestrazione dei container. Kubernetes ha occupato questo spazio in modo così significativo che anche i suoi principali concorrenti Docker Swarm e Mesosphere DC/OS offrono come alternativa l'integrazione con Kubernetes.
- Servizi e istanze (pod di Kubernetes). Un'istanza è una singola copia attiva di un microservizio. A volte un'istanza corrisponde a un singolo contenitore. In Kubernetes, un'istanza è composta da un piccolo gruppo di contenitori indipendenti, noto come pod. I client raramente si rivolgono direttamente a un'istanza o a un pod, ma più comunemente interagiscono con un servizio che rappresenta un insieme di istanze o pod (repliche) identici, scalabili e resilienti.
- Sidecar Proxy. Il Sidecar Proxy lavora con una singola istanza o pod. La funzione del Sidecar Proxy è quella di indirizzare o fare da proxy al traffico in arrivo dal contenitore con cui lavora e al traffico di ritorno. Il Sidecar interagisce con altri Sidecar Proxy ed è gestito da un framework di orchestrazione. Molte implementazioni di Service Mesh utilizzano il Sidecar Proxy per intercettare e gestire tutto il traffico in entrata e in uscita dell'istanza o del pod.
- Rilevamento dei servizi. Quando un'istanza deve interagire con un altro servizio, deve trovare (scoprire) un'istanza funzionante e disponibile di quell'altro servizio. Di norma, l'istanza esegue una ricerca tramite DNS. Il framework di orchestrazione dei container mantiene un elenco di istanze pronte a ricevere richieste e fornisce un'interfaccia per le richieste DNS.
- Bilanciamento del carico. La maggior parte dei framework di orchestrazione dei container fornisce bilanciamento del carico al livello 4 (livello di trasporto). Il Service Mesh implementa un bilanciamento del carico più complesso a livello 7 (livello applicativo), ricco di algoritmi e più efficace nella gestione del traffico. I parametri di bilanciamento del carico possono essere modificati tramite API, consentendo di orchestrare distribuzioni blue-green o canary.
- Crittografia. Il Service Mesh può crittografare e decrittografare richieste e risposte, sollevando questo onere dai servizi. Inoltre, il Service Mesh può migliorare le prestazioni privilegiando o riutilizzando connessioni permanenti esistenti, riducendo così la necessità di costose operazioni per stabilire nuove connessioni. La realizzazione più comune della crittografia del traffico è mutual TLS (mTLS), dove l'infrastruttura a chiave pubblica (PKI) genera e distribuisce certificati e chiavi per utilizzarli nel Sidecar Proxy.
- Autenticazione e autorizzazione. Il Service Mesh può autorizzare e autenticare richieste provenienti dall'esterno o dall'interno dell'applicazione, inviando agli istanze solo richieste validate.
- Supporto per il pattern di circuit breaker. Il Service Mesh supporta il , che isola le istanze non sane e poi le reintegra nel pool delle istanze sane gradualmente, se necessario.
La parte dell'applicazione del Service Mesh che gestisce il traffico di rete tra le istanze si chiama Data Plane. Creazione e distribuzione di una configurazione che gestisce il comportamento Data Plane, realizzata tramite una struttura separata Control Plane. Control Plane di solito include o è progettata per connettersi a API, CLI o GUI per gestire l'applicazione.
Il Control Plane nel Service Mesh distribuisce la configurazione tra Sidecar Proxy e Data Plane.
Spesso l'architettura del Service Mesh viene utilizzata per affrontare complesse sfide operative sfruttando contenitori e microservizi. I pionieri in questo campo sono aziende come Lyft, Netflix e Twitter, che forniscono servizi affidabili a milioni di utenti in tutto il mondo. (). Per compiti applicativi meno impegnativi, è probabile che siano sufficienti architetture più semplici.
L'architettura del Service Mesh difficilmente diventerà mai la soluzione a tutte le questioni legate al funzionamento delle applicazioni e alla loro distribuzione. Architetti e sviluppatori dispongono di un vasto arsenale di strumenti, e solo uno di essi è un martello, il quale, tra i molteplici compiti, deve risolvere solo uno: piantare chiodi. , ad esempio, include diversi modelli che offrono una gamma continua di approcci per risolvere problemi con i microservizi.
Gli elementi che si integrano nell'architettura Service Mesh, come NGINX, i contenitori, Kubernetes e i microservizi come approccio architettonico, possono essere utilizzati in modo altrettanto produttivo anche in implementazioni senza Service Mesh. Ad esempio, Istio è stato sviluppato come un'architettura Service Mesh completa, ma la modularità significa che gli sviluppatori possono scegliere e applicare solo i componenti tecnologici di cui hanno bisogno. Tenendo presente ciò, è importante avere una chiara comprensione del concetto di Service Mesh, anche se non si è certi di poterlo implementare completamente in un'applicazione.
Fonte: habr.com
