E ciao di nuovo!.. 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 grande volume di comunicazioni interprocesso in rete tra le interfacce di programmazione delle applicazioni (API). Il Service Mesh garantisce comunicazioni rapide, affidabili e sicure tra servizi containerizzati e frequentemente efimeri dell'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, insieme al supporto per il modello di spegnimento automatico (circuit breaker).
Il Service Mesh viene solitamente implementato fornendo a ogni istanza di servizio un'istanza di proxy, chiamata Sidecar. Il Sidecar gestisce le comunicazioni tra i servizi, esegue monitoraggio e risolve 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 di Google, IBM e Lyft è attualmente la più nota architettura Service Mesh. Kubernetes, originariamente sviluppato da Google, è ora l'unico framework per l'orchestrazione dei container supportato da Istio. I fornitori stanno cercando di creare versioni commerciali supportate di Istio. È interessante vedere cosa potranno portare di nuovo al progetto open source.
Tuttavia, Istio non è l'unica opzione, poiché altre implementazioni di Service Mesh sono in fase di sviluppo. Il modello sidecar proxy è l'implementazione più popolare, come può essere visto nei progetti di Buoyant, HashiCorp, Solo.io e altri. Esistono anche architetture alternative: il toolkit tecnologico di Netflix è uno degli approcci, dove la funzionalità del Service Mesh viene realizzata attraverso librerie come Ribbon, Hysterix, Eureka, Archaius, oltre a piattaforme come Azure Service Fabric.
Il Service Mesh ha anche una propria terminologia per i componenti-servizi e le funzioni:
- Framework per l'orchestrazione dei container. Con l'aumento del numero di container all'interno dell'infrastruttura dell'applicazione, sorge la necessità di uno strumento separato per monitorare e gestire i container: il framework di orchestrazione dei container. Kubernetes ha occupato questa nicchia in modo così forte che anche i suoi principali concorrenti, Docker Swarm e Mesosphere DC/OS, offrono come alternativa integrazioni con Kubernetes.
- Servizi e istanze (pod Kubernetes). Un'istanza è una singola copia in esecuzione di un microservizio. A volte un'istanza corrisponde a un solo container. In Kubernetes, un'istanza è costituita da un piccolo gruppo di container indipendenti, chiamato pod. I client raramente si rivolgono direttamente a un'istanza o a un pod; più frequentemente si rivolgono a un servizio, che rappresenta un insieme di istanze o pod identici, scalabili e resilienti (repliche).
- Sidecar Proxy. Il Sidecar Proxy lavora con un'istanza o un pod. La funzione del Sidecar Proxy è di instradare o fare il proxy del traffico in arrivo dal container con cui lavora e del traffico di ritorno. Il Sidecar interagisce con altri Sidecar Proxy ed è gestito dal framework di orchestrazione. Molte implementazioni del Service Mesh usano il Sidecar Proxy per intercettare e gestire tutto il traffico in entrata e in uscita di un'istanza o di un pod.
- Scoperta dei servizi. Quando un'istanza deve interagire con un altro servizio, deve trovare (scoprire) un'istanza funzionante e disponibile dell'altro servizio. In genere, l'istanza effettua la ricerca tramite DNS. Il framework di orchestrazione dei container mantiene un elenco di istanze pronte a ricevere richieste e fornisce un'interfaccia per le query DNS.
- Il bilanciamento del carico. La maggior parte dei framework di orchestrazione dei container offre bilanciamento del carico a livello 4 (di trasporto). Il Service Mesh implementa un bilanciamento del carico più complesso a livello 7 (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.
- CrittografiaIl Service Mesh può crittografare e decrittografare le richieste e le risposte, sollevando questo onere dai servizi. Il Service Mesh può anche migliorare le prestazioni dando priorità o riutilizzando connessioni persistenti esistenti, riducendo la necessità di costose computazioni 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 fatte dall'esterno o dall'interno dell'applicazione, inviando solo richieste validate alle istanze.
- Supporto per il pattern di spegnimento automatico. Il Service Mesh supporta , che isola le istanze non sane e poi le reintegra gradualmente nel pool delle istanze sane quando necessario.
Quella parte dell'applicazione Service Mesh che gestisce il traffico di rete tra le istanze si chiama Data Plane. La creazione e il deployment della configurazione, che gestisce il comportamento Data Plane, avviene tramite un Control Plane. Control Plane che generalmente include o è progettato 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 applicata per affrontare compiti operativi complessi utilizzando container e microservizi. I pionieri in questo campo includono aziende come Lyft, Netflix e Twitter, che offrono servizi funzionanti a milioni di utenti in tutto il mondo. (). Per compiti applicativi meno esigenti, probabilmente sarà sufficiente un'architettura più semplice.
L'architettura del Service Mesh difficilmente sarà mai la risposta a tutte le questioni relative al funzionamento e alla consegna delle applicazioni. Architetti e sviluppatori hanno un enorme arsenale di strumenti, e solo uno di essi è il martello, il quale deve affrontare solo una delle molteplici sfide – battere chiodi. , ad esempio, include diversi modelli che offrono uno spettro continuo di approcci per affrontare le sfide tramite microservizi.
Gli elementi che si combinano nell'architettura del Service Mesh, come NGINX, contenitori, Kubernetes e microservizi come approccio architetturale, possono essere utilizzati in modo altrettanto produttivo anche in implementazioni senza Service Mesh. Ad esempio, Istio è stato progettato come un'architettura completa di Service Mesh, ma la modularità implica che gli sviluppatori possono scegliere e applicare solo i componenti tecnologici di cui hanno realmente bisogno. Tenendo presente ciò, è necessario sviluppare una chiara comprensione del concetto di Service Mesh, anche se non si è certi di riuscire mai a implementarlo completamente in un'applicazione.
Fonte: habr.com
