Ciao di nuovo!.. Alla vigilia dell'inizio del corso Abbiamo preparato un'altra traduzione utile.
Una rete di servizi è un livello di infrastruttura configurabile a bassa latenza necessario per gestire grandi volumi di comunicazioni interprocesso basate sulla rete tra le interfacce di programmazione delle applicazioni (API). Service Mesh consente una comunicazione veloce, affidabile e sicura tra servizi di infrastruttura applicativa containerizzati e spesso effimeri. Service Mesh offre funzionalità quali individuazione dei servizi, bilanciamento del carico, crittografia, trasparenza, tracciabilità, autenticazione e autorizzazione e supporto dei modelli di arresto automatico (interruttore).
Una rete di servizi viene in genere implementata fornendo a ciascuna istanza del servizio un'istanza proxy, denominata Sidecar. Sidecar gestire le comunicazioni tra servizi, monitorare e risolvere problemi di sicurezza, ovvero tutto ciò che può essere astratto dai singoli servizi. In questo modo, gli sviluppatori possono scrivere, gestire e servire il codice dell'applicazione nei servizi e gli amministratori di sistema possono lavorare con Service Mesh ed eseguire l'applicazione.
Istio di Google, IBM e Lyft è attualmente l'architettura service mesh più famosa. E Kubernetes, originariamente sviluppato da Google, è ora l’unico framework di orchestrazione dei contenitori supportato da Istio. I fornitori stanno cercando di creare versioni di Istio supportate commercialmente. Sarà interessante vedere quali novità potranno apportare al progetto open source.
Tuttavia, Istio non è l'unica opzione poiché sono in fase di sviluppo altre implementazioni di Service Mesh. Modello sidecar proxy è l'implementazione più popolare, come si può giudicare dai progetti Buoyant, HashiCorp, Solo.io e altri. Esistono anche architetture alternative: il toolkit tecnologico Netflix è uno degli approcci in cui la funzionalità Service Mesh viene implementata attraverso le librerie Ribbon, Hysterix, Eureka, Archaius, oltre a piattaforme come Azure Service Fabric.
Service Mesh dispone inoltre di una propria terminologia per i componenti e le funzioni del servizio:
- Framework di orchestrazione dei contenitori. Poiché sempre più contenitori vengono aggiunti all'infrastruttura applicativa, è necessario uno strumento separato per il monitoraggio e la gestione dei contenitori: un framework di orchestrazione dei contenitori. Kubernetes ha occupato saldamente questa nicchia, tanto che anche i suoi principali concorrenti Docker Swarm e Mesosphere DC/OS offrono come alternativa l'integrazione con Kubernetes.
- Servizi e istanze (pod Kubernetes). Un'istanza è una singola copia in esecuzione di un microservizio. A volte un'istanza è un contenitore. In Kubernetes, un'istanza è costituita da un piccolo gruppo di contenitori indipendenti chiamati pod. I client raramente accedono direttamente a un'istanza o a un pod; più spesso accedono a un servizio, che è un insieme di istanze o pod (repliche) identici, scalabili e con tolleranza agli errori.
- Proxy Sidecar. Sidecar Proxy funziona con una singola istanza o pod. Lo scopo di Sidecar Proxy è instradare o proxy il traffico proveniente dal contenitore con cui funziona e restituire il traffico. Sidecar interagisce con altri proxy Sidecar ed è gestito da un framework di orchestrazione. Molte implementazioni di Service Mesh utilizzano Sidecar Proxy per intercettare e gestire tutto il traffico in entrata e in uscita da un'istanza o un pod.
- Scoperta del servizio. Quando un'istanza deve comunicare con un altro servizio, deve trovare (scoprire) un'istanza integra e disponibile dell'altro servizio. In genere, l'istanza esegue ricerche DNS. Il framework di orchestrazione del contenitore mantiene un elenco di istanze pronte a ricevere richieste e fornisce un'interfaccia per le query DNS.
- Bilancio del carico. La maggior parte dei framework di orchestrazione dei contenitori fornisce il bilanciamento del carico al livello 4 (trasporto). Service Mesh implementa un bilanciamento del carico più complesso al layer 7 (livello applicazione), ricco di algoritmi e più efficace nella gestione del traffico. Le impostazioni di bilanciamento del carico possono essere modificate utilizzando l'API, consentendoti di orchestrare distribuzioni blue-green o canary.
- Шифрование. Service Mesh può crittografare e decrittografare richieste e risposte, eliminando questo onere dai servizi. Service Mesh può anche migliorare le prestazioni assegnando priorità o riutilizzando le connessioni persistenti esistenti, riducendo la necessità di calcoli costosi per creare nuove connessioni. L'implementazione più comune della crittografia del traffico è TLS reciproco (mTLS), in cui un'infrastruttura a chiave pubblica (PKI) genera e distribuisce certificati e chiavi utilizzabili da Sidecar Proxy.
- Autenticazione e autorizzazione. Il Service Mesh può autorizzare e autenticare le richieste effettuate dall'esterno o dall'interno dell'applicazione, inviando solo richieste convalidate alle istanze.
- Supporto del modello di spegnimento automatico. Supporta Service Mesh , che isola le istanze non integre e le restituisce gradualmente al pool di istanze integre quando necessario.
Viene chiamata la parte di un'applicazione Service Mesh che gestisce il traffico di rete tra le istanze Piano dati. Crea e distribuisci una configurazione che controlla il comportamento Piano dati, viene eseguito utilizzando un separato Piano di controllo. Piano di controllo in genere include o è progettato per connettersi a un'API, CLI o GUI per controllare l'applicazione.
Il piano di controllo nel Service Mesh distribuisce la configurazione tra il proxy Sidecar e il piano dati.
L'architettura Service Mesh viene spesso utilizzata per risolvere problemi operativi complessi utilizzando contenitori e microservizi. Pionieri nel campo sono aziende come Lyft, Netflix e Twitter, che forniscono servizi stabili a milioni di utenti in tutto il mondo. (). Per le applicazioni meno impegnative, probabilmente saranno sufficienti architetture più semplici.
È improbabile che l'architettura Service Mesh possa mai essere la risposta a tutti i problemi di funzionamento e distribuzione delle applicazioni. Architetti e sviluppatori hanno un enorme arsenale di strumenti e solo uno di questi è un martello, che, tra i tanti compiti, deve risolverne solo uno: martellare i chiodi. , ad esempio, include diversi modelli che forniscono un continuum di approcci alla risoluzione dei problemi utilizzando i microservizi.
Gli elementi che si uniscono in un'architettura Service Mesh, come NGINX, contenitori, Kubernetes e microservizi come approccio architetturale, possono essere ugualmente produttivi nelle implementazioni non Service Mesh. Ad esempio, Istio è stato progettato come un'architettura mesh di servizi completa, ma la sua modularità consente agli sviluppatori di selezionare e implementare solo i componenti tecnologici di cui hanno bisogno. Tenendo presente questo, è importante sviluppare una chiara comprensione del concetto di Service Mesh, anche se non sei sicuro di riuscire a implementarlo completamente nella tua applicazione.
Fonte: habr.com