Nota. trad.: Il service mesh è un fenomeno che non ha ancora una traduzione stabile in russo (più di 2 anni fa abbiamo offerto l'opzione "mesh for services" e poco dopo alcuni colleghi hanno iniziato a promuovere attivamente la combinazione "service setaccio") . Il continuo parlare di questa tecnologia ha portato a una situazione in cui le componenti tecniche e di marketing sono troppo strettamente intrecciate. Questo meraviglioso materiale di uno degli autori del termine originale ha lo scopo di portare chiarezza agli ingegneri e non solo.
Comico da
Introduzione
Se sei un ingegnere del software che lavora nel campo dei sistemi backend, probabilmente il termine “service mesh” si è già saldamente radicato nella tua mente negli ultimi due anni. Grazie a una strana coincidenza, questa frase sta prendendo sempre più piede nel settore, e l'hype e le relative offerte promozionali crescono come una palla di neve, volano giù dalla collina e non mostrano segni di rallentamento.
La rete di servizi è nata nelle acque torbide e tendenziose dell'ecosistema nativo del cloud. Sfortunatamente, questo significa che gran parte della controversia che lo circonda spazia dalle “chiacchiere ipocaloriche” a, per usare il termine tecnico, palesi stronzate. Ma se si filtra tutto il rumore, si scopre che la rete di servizi ha una funzione molto reale, definita e importante.
In questo post cercherò di fare proprio questo: fornire una guida onesta, approfondita e orientata agli ingegneri al service mesh. Risponderò più che semplicemente alla domanda: "Cos'è?", - ma anche "Per che cosa?"e "Perché ora?". Infine, proverò a delineare il motivo per cui (secondo me) questa particolare tecnologia ha suscitato un clamore così folle, il che di per sé è una storia interessante.
Chi sono
Ciao a tutti! Mi chiamo . Sono uno dei creatori - il primissimo progetto di service mesh e il progetto responsabile della comparsa del termine rete di servizi in quanto tale (scusate ragazzi!). (Nota trad.: A proposito, all'alba della comparsa di questo termine, più di 2,5 anni fa, abbiamo già tradotto il primo materiale dello stesso autore chiamato "".) Conduco anche io è una startup che crea interessanti servizi mesh come Linkerd e .
Probabilmente puoi immaginare che io abbia un'opinione molto parziale e soggettiva su questo tema. Tuttavia, cercherò di mantenere i pregiudizi al minimo (ad eccezione di una sezione: "Perché si parla così tanto della rete di servizi?", - in cui condividerò comunque le mie idee preconcette). Farò anche del mio meglio per rendere questa guida il più obiettiva possibile. Negli esempi specifici, mi baserò principalmente sull'esperienza di Linkerd, sottolineando le differenze (se presenti) che conosco nell'implementazione di altri tipi di service mesh.
Ok, è ora di passare ai dolcetti.
Cos'è una rete di servizi?
Nonostante tutto il clamore pubblicitario, la rete di servizi è strutturalmente abbastanza semplice. Si tratta semplicemente di un insieme di proxy dello spazio utente posizionati "accanto" ai servizi (parleremo un po' di "vicino" più avanti), oltre a una serie di processi di controllo. I proxy vengono chiamati collettivamente piano dati, e vengono chiamati i processi di controllo piano di controllo. Il piano dati intercetta le chiamate tra servizi e fa "qualcosa di diverso" con loro; il piano di controllo, rispettivamente, coordina il comportamento del proxy e fornisce l'accesso per te, ad es. operatore, all'API, consentendo di manipolare e misurare la rete nel suo insieme.
Cos'è questa procura? Questo è un proxy TCP della categoria "Layer 7-aware". (ovvero "tenendo conto" del 7° livello del modello OSI) come HAProxy e NGINX. Puoi scegliere un proxy di tuo gradimento; Linkerd utilizza un proxy Rust, dal nome semplice . Lo abbiamo compilato appositamente per il service mesh. Altre mesh preferiscono altri proxy (Envoy è una scelta comune). Tuttavia, la scelta di un proxy è solo una questione di implementazione.
Cosa fanno questi server proxy? Ovviamente, delegano le chiamate da e verso i servizi (in senso stretto, agiscono come proxy e proxy inversi, gestendo sia le chiamate in entrata che quelle in uscita). E implementano un set di funzionalità incentrato sulle chiamate между Servizi. Questa attenzione al traffico tra servizi è ciò che distingue un proxy mesh di servizi, ad esempio, dai gateway API o dai proxy di ingresso (questi ultimi focalizzati sulle chiamate che entrano nel cluster dal mondo esterno). (Nota. trad.: Per un confronto tra i controller Kubernetes Ingress esistenti, molti dei quali utilizzano il già citato Envoy, vedere .)
Quindi, abbiamo capito il piano dati. Il piano di controllo è più semplice: è un insieme di componenti che forniscono tutti i meccanismi di cui il piano dati ha bisogno per funzionare in modo coordinato, tra cui l'individuazione dei servizi, l'emissione di certificati TLS, l'aggregazione delle metriche, ecc. Il piano dati informa il piano di controllo riguardo il suo comportamento; a sua volta, il piano di controllo fornisce un'API che consente di modificare e monitorare il comportamento del piano dati nel suo complesso.
Di seguito è riportato un diagramma del piano di controllo e del piano dati in Linkerd. Come puoi vedere, il piano di controllo include diversi componenti diversi, inclusa un'istanza Prometheus che raccoglie parametri dai server proxy, nonché altri componenti come destination (scoperta del servizio), identity (autorità di certificazione, CA) e public-api (endpoint per Web e CLI). Al contrario, il piano dati è un semplice proxy linkerd accanto all'istanza dell'applicazione. Questo è solo un diagramma logico; in una distribuzione nel mondo reale, potresti avere tre repliche di ciascun componente del piano di controllo e centinaia o migliaia di proxy nel piano dati.
(Le caselle blu in questo diagramma rappresentano i confini dei pod Kubernetes. Puoi vedere che i contenitori con il proxy linkerd si trovano nello stesso pod dei contenitori dell'applicazione. Questo schema è noto come contenitore per sidecar.)
L'architettura della rete di servizi ha diverse importanti implicazioni. Innanzitutto, poiché il compito di un proxy è intercettare le chiamate tra servizi, una rete di servizi ha senso solo se l'applicazione è stata creata per un insieme di servizi. maglia si può utilizzare con i monoliti, ma questo è chiaramente ridondante per il bene di un singolo proxy ed è improbabile che la sua funzionalità sia richiesta.
Un'altra conseguenza importante è che la rete di servizi richiede enorme numero di deleghe. In effetti, Linkerd concatena un proxy linkerd a ogni istanza di ogni servizio (altre implementazioni aggiungono un proxy a ogni host/host/VM. È comunque molto). Un utilizzo così attivo di un proxy comporta di per sé una serie di ulteriori complicazioni:
- I proxy nel piano dati dovrebbero esserlo veloce, perché per ogni chiamata ci sono un paio di chiamate al proxy: una lato client, una lato server.
- Inoltre, i proxy devono esserlo piccolo и leggero. Ciascuno consumerà risorse di memoria e CPU e questo consumo aumenterà linearmente con l'applicazione.
- Avrai bisogno di un meccanismo per distribuire e aggiornare un gran numero di proxy. Farlo manualmente non è un'opzione.
In generale, la rete di servizi si presenta così (almeno da una prospettiva a volo d'uccello): distribuisci una serie di proxy dello spazio utente che "fanno qualcosa" con il traffico interno tra servizi e utilizzi il piano di controllo per monitorarli e gestirli.
È il momento della domanda "Perché?"
A cosa serve una rete di servizi?
Per coloro che per primi si sono imbattuti nell'idea di una rete di servizi, è perdonabile essere un po' in soggezione. La progettazione della rete di servizi significa che non solo aumenterà la latenza dell'applicazione, ma lo farà anche consumare risorse e aggiungerà una serie di nuovi meccanismi nell’infrastruttura. Per prima cosa imposti una rete di servizi e poi all'improvviso ti ritrovi a dover servire centinaia (se non migliaia) di proxy. La domanda è: chi si offrirà volontario per questo?
La risposta a questa domanda ha due parti. Innanzitutto, i costi di transazione associati all’implementazione di questi proxy possono essere significativamente ridotti a causa di alcuni cambiamenti che avvengono nell’ecosistema (ne parleremo più avanti).
In secondo luogo, un dispositivo del genere è in realtà un ottimo modo per introdurre logica aggiuntiva nel sistema. E non solo perché utilizzando il service mesh si possono aggiungere molte nuove funzionalità, ma anche perché ciò può essere fatto senza interferire con l’ecosistema. In effetti, l’intero modello di service mesh si basa su questo postulato: in un sistema multiservizio, qualunque cosa accada fare singoli servizi, traffico fra loro è il punto ideale per aggiungere funzionalità.
Ad esempio, in Linkerd (come nella maggior parte dei mesh) la funzionalità si concentra principalmente sulle chiamate HTTP, inclusi HTTP/2 e gRPC*. La funzionalità è piuttosto ricca e può essere divisa in tre classi:
- Funzioni relative a affidabilità. Richieste di nuovo tentativo, timeout, approccio canary (suddivisione/reindirizzamento del traffico), ecc.
- Funzioni relative a monitoraggio. Aggregazione delle percentuali di successo, dei ritardi e dei volumi di richieste per ciascun servizio o singole destinazioni; costruzione di mappe topologiche dei servizi, ecc.
- Funzioni relative a sicurezza. TLS mutuo, controllo degli accessi, ecc.
* Dal punto di vista di Linkerd, gRPC non è praticamente diverso da HTTP/2: utilizza semplicemente protobuf nel payload. Dal punto di vista dello sviluppatore, queste due cose sono, ovviamente, diverse.
Molti di questi meccanismi operano a livello di richiesta (da qui il "proxy L7"). Ad esempio, se il servizio Foo effettua una chiamata HTTP al servizio Bar, il proxy linkerd sul lato di Foo può bilanciare in modo intelligente il carico e instradare le chiamate dalle istanze Foo alle istanze Bar in base alla latenza osservata; può ripetere la richiesta se necessario (e se è idempotente); può registrare il codice di risposta, il timeout e così via. Allo stesso modo, il proxy linkerd dal lato Bar può rifiutare una richiesta se non è consentita o se il limite di richiesta viene superato; può correggere il ritardo da parte sua, ecc.
I proxy possono “fare qualcosa” anche a livello di connessione. Ad esempio, un proxy linkerd sul lato Foo può avviare una connessione TLS e un proxy linkerd sul lato Bar può terminarla ed entrambe le parti possono verificare i reciproci certificati TLS*. Ciò fornisce non solo la crittografia tra i servizi, ma anche un modo crittograficamente sicuro per identificare i servizi: Foo e Bar possono "provare" di essere chi dicono di essere.
* "Amico di un amico" significa che anche il certificato del cliente è verificato (mutuo TLS). Nel TLS "classico", ad esempio, tra un browser e un server, viene solitamente verificato il certificato di un solo lato (il server).
Sia che operino a livello di richiesta o di connessione, è importante sottolineare che tutte le funzionalità di service mesh lo sono operativo carattere. Linkerd non è in grado di trasformare la semantica del payload, come aggiungere campi a un frammento JSON o apportare modifiche a un protobuf. Parleremo di questa importante funzionalità più avanti quando parleremo di ESB e middleware.
Questo è l'insieme di funzionalità offerte dal service mesh. La domanda sorge spontanea: perché non implementarli direttamente nell'applicazione? E perché scherzare con un proxy?
Perché una rete di servizi è una buona idea
Sebbene le funzionalità della rete di servizi siano accattivanti, il suo valore principale non risiede realmente nelle funzionalità. Alla fine noi può implementarli direttamente nell'applicazione (più avanti vedremo che questa è stata l'origine del service mesh). Per dirla in una frase, il valore di una mesh di servizi è: fornisce funzionalità fondamentali per l'esecuzione del moderno software server in modo coerente, a livello di stack e indipendente dal codice dell'applicazione.
Analizziamo questa proposta.
«Funzioni fondamentali per l'esecuzione di software server moderni". Se stai creando un'applicazione server transazionale connessa all'Internet pubblica che accetta richieste dal mondo esterno e risponde ad esse in breve tempo - ad esempio un'applicazione web, un server API e la stragrande maggioranza delle altre applicazioni moderne - e se lo implementi come un insieme di servizi che interagiscono in modo sincrono tra loro e se aggiorni costantemente questo software, aggiungendo nuove funzionalità e se sei costretto a mantenere questo sistema in condizioni di lavoro durante il processo di modifica - in questo caso, congratulazioni, stai creando un moderno software server. E tutte le fantastiche funzionalità elencate sopra si rivelano effettivamente fondamentali per te. L'applicazione deve essere affidabile, sicura e devi essere in grado di vedere cosa sta facendo. Sono queste le domande che la rete di servizi aiuta a risolvere.
(Ok, la mia convinzione che questo approccio sia il modo moderno di costruire software per server si è insinuata nel paragrafo precedente. Altri preferiscono sviluppare monoliti, "microservizi reattivi" e altre cose che non rientrano nella definizione data sopra. Queste persone probabilmente hanno opinione diversa dalla mia e, a mia volta, credo che abbiano "sbagliato" (anche se in ogni caso il service mesh non è molto utile per loro).
«Uniforme per l'intera pila". Le funzionalità fornite dalla rete di servizi non sono solo fondamentali. Si applicano a tutti i servizi in un'applicazione, indipendentemente dal linguaggio in cui sono scritti, dal framework che utilizzano, da chi li ha scritti, da come sono stati distribuiti e da tutte le altre sottigliezze del loro sviluppo e utilizzo.
«Indipendente dal codice dell'applicazione". Infine, la rete di servizi non solo fornisce funzionalità coerenti nell'intero stack, ma lo fa in un modo che non richiede la modifica dell'applicazione. La base fondamentale della funzionalità di una rete di servizi, comprese le attività di configurazione, aggiornamento, funzionamento, manutenzione, ecc., è puramente a livello di piattaforma ed è indipendente dall'applicazione. L'applicazione può cambiare senza influenzare la rete di servizi. A sua volta, la rete di servizi può cambiare senza alcun intervento dell'applicazione.
In breve, la rete di servizi non solo fornisce funzionalità vitali, ma lo fa in modo globale, uniforme e indipendente dall’applicazione. E così, mentre la funzionalità di una mesh di servizi può essere implementata nel codice di un servizio (ad esempio, come una libreria inclusa in ciascun servizio), questo approccio non fornirà l'uniformità e l'indipendenza così preziose nel caso di un servizio mesh. rete di servizi.
E tutto ciò che devi fare è aggiungere un sacco di proxy! Lo prometto, molto presto esamineremo i costi operativi associati all'aggiunta di questi proxy. Ma prima fermiamoci e guardiamo questa idea di indipendenza dal punto di vista di diversi persone.
Chi aiuta la rete di servizi?
Per quanto scomodo possa essere, affinché una tecnologia diventi una parte importante dell’ecosistema, deve essere accettata dalle persone. Allora chi è interessato a una rete di servizi? Chi trae vantaggio dal suo utilizzo?
Se sviluppi un moderno software server, puoi immaginare approssimativamente il tuo team come un gruppo proprietari di serviziche insieme sviluppano e implementano la logica aziendale e proprietari della piattaformacoinvolti nello sviluppo della piattaforma interna su cui vengono eseguiti questi servizi. Nelle piccole organizzazioni, queste possono essere le stesse persone, ma man mano che l'azienda cresce, questi ruoli tendono a diventare più pronunciati e persino divisi in sotto-ruoli... (C'è molto da dire qui sulla natura mutevole dei devops, l'impatto organizzativo dei microservizi, ecc.). n. Ma per ora diamo per scontate queste descrizioni).
Da questo punto di vista, i chiari beneficiari del service mesh sono i proprietari della piattaforma. Dopotutto, l'obiettivo finale del team della piattaforma è creare una piattaforma interna su cui i proprietari del servizio possano implementare la logica aziendale e farlo in un modo che garantisca loro la massima indipendenza dai tristi dettagli del suo funzionamento. La rete di servizi non solo offre le funzionalità fondamentali per raggiungere questo obiettivo, ma lo fa in un modo che, a sua volta, non impone dipendenze dai proprietari dei servizi.
Anche i proprietari dei servizi ne traggono vantaggio, anche se in modo più indiretto. L'obiettivo del proprietario del servizio è quello di essere il più produttivo possibile nell'implementazione della logica del processo aziendale, e meno deve preoccuparsi di questioni operative, meglio è. Invece di applicare, ad esempio, nuove policy o TLS, possono concentrarsi esclusivamente sul business e sperare che la piattaforma si occupi del resto. Per loro questo è un grande vantaggio.
Il valore organizzativo di una simile divisione tra i proprietari di piattaforme e servizi non può essere sopravvalutato. Penso che lei contribuisca primario contributo al valore della rete di servizi.
Abbiamo imparato questa lezione quando uno dei primi fan di Linkerd ci ha spiegato perché hanno scelto il service mesh: perché permetteva loro di "continuare a parlare al minimo". Ecco alcuni dettagli: i ragazzi di una grande azienda hanno migrato la loro piattaforma su Kubernetes. Poiché l'applicazione funzionava con informazioni sensibili, volevano crittografare tutte le comunicazioni nei cluster. Tuttavia, la situazione era complicata dalla presenza di centinaia di servizi e centinaia di team di sviluppo. La prospettiva di contattare tutti e convincerli a includere il supporto a TLS nei loro piani non li ha affatto soddisfatti. Installando Linkerd, hanno migrato responsabilità dagli sviluppatori (dal cui punto di vista si trattava di problemi inutili) ai platform, per i quali questa era una priorità di primo livello. In altre parole, Linkerd risolveva per loro non tanto un problema tecnico quanto organizzativo.
In breve, la rete di servizi non è piuttosto una soluzione tecnica, ma socio-tecnico problemi. (Grazie per aver introdotto questo termine.
Il service mesh risolverà tutti i miei problemi?
SÌ. Voglio dire, no!
Osservando le tre classi di funzionalità sopra descritte (affidabilità, sicurezza e osservabilità) diventa chiaro che il service mesh non rappresenta una soluzione completa a nessuno di questi problemi. Sebbene Linkerd possa inviare richieste ripetute (se sa che sono idempotenti), non è nella posizione di prendere decisioni su cosa restituire all'utente se il servizio alla fine non funziona più: tali decisioni devono essere prese dall'applicazione. Linkerd può conservare statistiche sulle richieste riuscite, ma non è in grado di esaminare il servizio e fornire le sue metriche interne: un'applicazione dovrebbe disporre di un tale toolkit. E sebbene Linkerd sia in grado di ospitare mTLS, le soluzioni di sicurezza complete richiedono molto di più.
Un sottoinsieme delle funzionalità in queste aree offerte dal service mesh sono correlati a funzionalità della piattaforma. Con questo intendo funzioni che:
- Indipendente dalla logica aziendale. Il modo in cui vengono costruiti gli istogrammi delle chiamate tra Foo e Bar è completamente indipendente dal fatto che perché Foo chiama Bar.
- Difficile da implementare correttamente. In Linkerd, i tentativi sono parametrizzati con ogni sorta di cose fantasiose come i budget dei tentativi. (riprovare i budget), poiché un approccio ingenuo all'attuazione di tali cose porterà sicuramente all'emergere della cosiddetta "valanghe di richieste" (riprova tempesta) e altri problemi specifici dei sistemi distribuiti.
- Più efficace se applicato in modo coerente. Il meccanismo TLS ha senso solo se applicato ovunque.
Poiché queste funzionalità sono implementate a livello proxy (e non a livello di applicazione), la rete di servizi le espone a livello piattaforma, non applicazioni. Pertanto, non importa in quale lingua sono scritti i servizi, quale framework utilizzano, chi li ha scritti e perché. I proxy funzionano oltre tutti questi dettagli e la base fondamentale di questa funzionalità, comprese le attività di configurazione, aggiornamento, funzionamento, manutenzione, ecc., si trova esclusivamente a livello di piattaforma.
Esempi di funzionalità di mesh di servizi
In sintesi, una rete di servizi non è una soluzione completa per affidabilità, osservabilità o sicurezza. L'ambito di queste aree implica la partecipazione obbligatoria dei proprietari dei servizi, dei team Ops/SRE e di altre parti interessate dell'azienda. La rete di servizi fornisce solo una "sezione" a livello di piattaforma per ciascuna di queste aree.
Perché il service mesh è diventato popolare in questo momento?
Probabilmente ti starai chiedendo in questo momento: OK, se la rete di servizi è così buona, perché non abbiamo iniziato a distribuire milioni di proxy nello stack dieci anni fa?
C'è una risposta banale a questa domanda: dieci anni fa tutti costruivano monoliti e nessuno aveva bisogno di una rete di servizi. Questo è vero, ma secondo me la risposta non coglie il punto. Già dieci anni fa il concetto di microservizi come metodo promettente per creare sistemi su larga scala veniva ampiamente discusso e applicato in aziende come Twitter, Facebook, Google e Netflix. La percezione generale, almeno nelle parti del settore con cui sono stato in contatto, era che i microservizi fossero il “modo giusto” per costruire sistemi di grandi dimensioni, anche se era dannatamente difficile.
Naturalmente, anche se dieci anni fa esistevano aziende che sfruttavano i microservizi, non attaccavano proxy ovunque potessero per formare una rete di servizi. Tuttavia, se si guarda da vicino, hanno fatto qualcosa di simile: molte di queste aziende hanno imposto l'uso di una speciale libreria interna per il networking (a volte chiamata libreria fat client, libreria fat client).
Netflix aveva Hysterix, Google aveva Stubby, Twitter aveva la libreria Finagle. Finagle, ad esempio, è diventato obbligatorio per ogni nuovo servizio su Twitter. Gestiva sia il lato client che quello server delle connessioni, consentiva richieste ripetute, supportava il routing delle richieste, il bilanciamento del carico e la misurazione. Ha fornito un livello coerente di affidabilità e osservabilità nell'intero stack di Twitter, indipendentemente da ciò che stava facendo il servizio. Naturalmente funzionava solo con i linguaggi JVM e si basava su un modello di programmazione che doveva essere utilizzato per l'intera applicazione. Tuttavia, la sua funzionalità era quasi la stessa del service mesh. (In realtà, la prima versione di Linkerd era semplicemente Finagle racchiusa in un modulo proxy.)
Pertanto, dieci anni fa non esistevano solo i microservizi, ma anche speciali librerie proto-service-mesh che risolvevano gli stessi problemi che la service mesh risolve oggi. Tuttavia, allora la rete stessa dei servizi non esisteva. Doveva esserci un altro cambiamento prima che lei apparisse.
Ed è qui che si trova la risposta più profonda, nascosta in un altro cambiamento avvenuto negli ultimi 10 anni: c’è stato un forte calo dei costi di implementazione dei microservizi. Le aziende sopra menzionate che utilizzavano i microservizi dieci anni fa – Twitter, Netflix, Facebook, Google – erano aziende di vasta scala e con enormi risorse. Non solo avevano la necessità, ma anche la capacità di creare, distribuire e gestire applicazioni di grandi dimensioni basate su microservizi. L’energia e lo sforzo che gli ingegneri di Twitter hanno profuso nel passaggio da un approccio monolitico a uno basato sui microservizi è sorprendente. (Onestamente, così come il fatto che abbia funzionato.) Questo tipo di manovra infrastrutturale era allora impossibile per le aziende più piccole.
Passiamo al presente. Oggi ci sono startup in cui il rapporto tra microservizi e sviluppatori è 5:1 (o addirittura ), e inoltre, li affrontano con successo! Se una startup di 5 persone è in grado di gestire 50 microservizi senza sforzi, allora qualcosa ha chiaramente ridotto i costi della loro implementazione.
1500 microservizi a Monzo; ogni linea è una regola di rete prescritta che consente il traffico
La drastica riduzione dei costi operativi dei microservizi è il risultato di un unico processo: crescente popolarità dei contenitori и orchestratori. Questa è precisamente la risposta profonda alla domanda su cosa abbia contribuito all’emergere della rete di servizi. La stessa tecnologia ha reso attraenti sia il service mesh che i microservizi: Kubernetes e Docker.
Perché? Ebbene, Docker risolve un grosso problema: il problema del packaging. Comprimendo un'applicazione e le sue dipendenze runtime (non di rete) in un contenitore, Docker trasforma l'applicazione in un'unità fungibile che può essere ospitata ed eseguita ovunque. Allo stesso tempo, semplifica notevolmente il funzionamento. multilingue stack: poiché un contenitore è un'unità atomica di esecuzione, non importa cosa c'è all'interno, che si tratti di un'applicazione JVM, Node, Go, Python o Ruby, per scopi operativi e di distribuzione. Lo esegui e basta.
Kubernetes porta tutto al livello successivo. Ora che ci sono un sacco di "cose eseguibili" e molte macchine su cui eseguirle, c'è bisogno di uno strumento che possa confrontarle tra loro. In senso lato, dai a Kubernetes molti contenitori e molte macchine e li abbina tra loro (ovviamente, questo è un processo dinamico e in costante cambiamento: nuovi contenitori si muovono nel sistema, le macchine si avviano e si fermano, ecc. Tuttavia, Kubernetes tiene conto di tutto questo).
Una volta configurato Kubernetes, il tempo necessario per implementare e gestire un servizio non è molto diverso dal costo per implementare e gestire dieci servizi (in effetti, è quasi lo stesso per 100 servizi). Aggiungi i contenitori come meccanismo di confezionamento che incoraggia l'implementazione multilingue e avrai tantissime nuove applicazioni implementate come microservizi scritti in più lingue, proprio il tipo di ambiente a cui la mesh di servizi è così adatta.
Arriviamo quindi alla risposta alla domanda sul perché l’idea di un service mesh sia diventata così popolare in questo momento: l’uniformità che Kubernetes garantisce per i servizi è direttamente applicabile ai compiti operativi che il service mesh deve affrontare. Impacchettate i proxy in contenitori, date a Kubernetes il compito di inserirli laddove possibile, e voilà! Di conseguenza, ottieni una rete di servizi, mentre Kubernetes controlla tutti i meccanismi della sua implementazione. (Almeno da una prospettiva a volo d'uccello. Naturalmente, ci sono molte sfumature in questo processo.)
Riassumendo: il motivo per cui il service mesh è diventato popolare adesso e non dieci anni fa è che Kubernetes e Docker non solo sono aumentati in modo significativo потребность in esso, semplificando l'implementazione delle applicazioni come insiemi di microservizi multilingue, ma anche notevolmente ridotte costi per il suo funzionamento fornendo meccanismi per l'implementazione e il mantenimento dei parchi proxy sidecar.
Perché si parla tanto di service mesh?
Attenzione: In questa sezione ricorro a tutti i tipi di ipotesi, congetture, invenzioni e informazioni privilegiate.
La ricerca di "rete di servizi" farà emergere un mucchio di contenuti riciclati, ipocalorici, progetti strani e un caleidoscopio di distorsioni degno di una camera di risonanza. Qualsiasi nuova tecnologia alla moda prevede questo, ma nel caso del service mesh il problema è particolarmente acuto. Perché?
Beh, in parte è colpa mia. Ho fatto del mio meglio per promuovere Linkerd e il service mesh in ogni occasione, attraverso innumerevoli post di blog e articoli come questo. Ma non sono così potente. Per rispondere davvero a questa domanda, dobbiamo parlare un po’ della situazione generale. Ed è impossibile parlarne senza menzionare un progetto: è una rete di servizi open source sviluppata congiuntamente da Google, IBM e Lyft.
(Queste tre società hanno ruoli molto diversi: il coinvolgimento di Lyft sembra essere limitato al solo nome; sono autori di Envoy ma non utilizzano o sono coinvolti nello sviluppo di Istio. IBM è coinvolta nello sviluppo di Istio e lo utilizza. Google è fortemente coinvolto nello sviluppo di Istio , ma per quanto ne so, in realtà non lo utilizza.)
Il progetto Istio è degno di nota per due cose. Innanzitutto l’enorme sforzo di marketing che Google, in particolare, mette nella sua promozione. Stimo che la maggior parte delle persone attualmente a conoscenza del concetto di service mesh lo abbiano appreso per la prima volta grazie a Istio. La seconda caratteristica è la pessima accoglienza di Istio. In questa vicenda, ovviamente, sono una parte interessata, ma cercando di rimanere il più obiettivo possibile, non posso farne a meno , non molto specifico (anche se non unico: mi viene in mente systemd, ...) per un progetto Open Source.
(In pratica, Istio sembra avere problemi non solo di complessità e UX, ma anche di prestazioni. Ad esempio, durante condotto da una terza parte, gli esperti hanno riscontrato situazioni in cui la latenza della coda di Istio era 100 volte superiore a quella di Linkerd, nonché situazioni con mancanza di risorse, quando Linkerd continuava a funzionare con successo e Istio smetteva completamente di funzionare.)
Tralasciando le mie teorie sul perché ciò sia accaduto, credo che il clamore fuori scala attorno al service mesh sia dovuto al coinvolgimento di Google. Vale a dire, una combinazione dei seguenti tre fattori:
- promozione ossessiva di Istio da parte di Google;
- adeguato atteggiamento critico e di disapprovazione nei confronti del progetto;
- la recente popolarità alle stelle di Kubernetes, il cui ricordo è ancora fresco.
Insieme, questi fattori si fondono in una sorta di ambiente inebriante e anossico in cui la capacità di giudizio razionale è indebolita e rimane solo una meravigliosa varietà. .
Dal punto di vista di Linkerd, questa è... la descriverei come una benedizione mista. Voglio dire, è fantastico che il service mesh sia diventato mainstream, cosa che non era il caso nel 2016, quando Linkerd è apparso per la prima volta ed è stato davvero difficile attirare l'attenzione della gente sul progetto. Ora non c'è più questo problema! Ma la cattiva notizia è che la situazione del service mesh è oggi così confusa che è quasi impossibile capire quali progetti appartengano realmente alla categoria del service mesh (per non parlare di capire quale sia il migliore per un particolare caso d'uso). Questo certamente ostacola tutti (e sicuramente in alcuni casi Istio o un altro progetto è migliore di Linkerd, poiché quest'ultimo non è una soluzione valida per tutti).
Da parte di Linkerd, la nostra strategia è stata quella di ignorare il rumore, continuare a concentrarci sulla risoluzione dei problemi reali della comunità e, essenzialmente, aspettare che l'hype si plachi. Alla fine l’hype si placherà e potremo continuare a lavorare in pace.
Fino ad allora, dovremo tutti essere pazienti.
La rete di servizi sarà utile a me, un modesto ingegnere del software?
Il seguente questionario aiuterà a rispondere a questa domanda:
Ti occupi esclusivamente dell'implementazione della logica aziendale? In questo caso, la rete di servizi non ti sarà utile. Ovviamente potrebbe interessarti, ma idealmente la mesh di servizi non dovrebbe influenzare direttamente nulla nel tuo ambiente. Continua a lavorare su ciò per cui sei pagato.
Mantieni una piattaforma in un'azienda che utilizza Kubernetes? Sì, in questo caso hai bisogno di una rete di servizi (ovviamente, se non utilizzi K8 solo per eseguire un monolite o un'elaborazione batch, ma vorrei chiederti perché hai bisogno di K8). Molto probabilmente ti ritroverai in una situazione con molti microservizi scritti da persone diverse. Interagiscono tutti tra loro e sono legati in un groviglio di dipendenze di runtime ed è necessario trovare un modo per affrontare tutto questo. L'utilizzo di Kubernetes ti consente di scegliere una service mesh "per te". Per fare ciò, familiarizza con le loro capacità e caratteristiche e rispondi alla domanda se qualcuno dei progetti disponibili è adatto a te (ti consiglio di iniziare la tua ricerca con Linkerd).
Gestisci una piattaforma per un'azienda che NON utilizza Kubernetes ma utilizza microservizi? In questo caso, la mesh dei servizi ti sarà utile, ma il suo utilizzo non sarà banale. Certo che puoi imitare service mesh ospitando una serie di proxy, ma un vantaggio importante di Kubernetes è proprio il modello di distribuzione: la manutenzione manuale di questi proxy richiederà molto più tempo, impegno e costi.
Sei responsabile della piattaforma in un'azienda che lavora con i monoliti? In questo caso, probabilmente non è necessaria una rete di servizi. Se lavori con monoliti (o anche set di monoliti) che hanno modelli di interazione ben definiti e che cambiano raramente, la rete di servizi ha poco da offrirti. Quindi puoi semplicemente ignorarlo e sperare che scompaia come un brutto sogno...
conclusione
Probabilmente, la service mesh non dovrebbe ancora essere definita "la tecnologia più pubblicizzata al mondo" - questo dubbio onore appartiene probabilmente a bitcoin o all'intelligenza artificiale. Forse è tra le prime cinque. Ma se si superano gli strati di rumore e frastuono, diventa chiaro che la mesh di servizi apporta vantaggi reali a coloro che creano applicazioni in Kubernetes.
Vorrei che provassi Linkerd, installandolo in un cluster Kubernetes (o anche Minikube su un laptop) e puoi vedere tu stesso di cosa sto parlando.
FAQ
- Se ignoro la mesh dei servizi, scomparirà?
- Devo deluderti: la rete di servizi è con noi da molto tempo.
— Ma NON VOGLIO utilizzare una rete di servizi!
- Beh, non è necessario! Basta leggere il mio questionario qui sopra per vedere se dovresti almeno familiarizzare con le sue basi.
— Non è il buon vecchio ESB/middleware con una nuova salsa?
- La mesh di servizi si occupa della logica operativa, non della semantica. autobus di servizio aziendale (). Mantenere questa separazione aiuta la rete di servizi a evitare lo stesso destino.
- In cosa differisce un service mesh dai gateway API?
Ci sono un milione di articoli su questo argomento. Basta cercare su Google.
Envoy è una rete di servizi?
- No, Envoy non è un service mesh, è un server proxy. Può essere utilizzato per organizzare una rete di servizi (e molto altro: è un proxy per scopi generali). Ma di per sé non è una rete di servizi.
- Network Service Mesh: è una rete di servizi?
- NO. Nonostante il nome, non si tratta di un servizio mesh (ti piacciono le meraviglie del marketing?).
- La rete di servizi sarà utile con il mio sistema asincrono reattivo basato sulla coda di messaggi?
- No, la rete di servizi non ti aiuterà.
- Quale mesh di servizi dovrei utilizzare?
- , una follia.
- L'articolo fa schifo! / L'autore - sulla soap!
— Per favore condividi il link con tutti i tuoi amici in modo che possano convincersene!
Ringraziamenti
Come puoi intuire dal titolo, questo articolo è stato ispirato dal fantastico trattato di Jay Kreps "". Ho incontrato Jay dieci anni fa durante un'intervista su Linked In e da allora è stato per me una fonte di ispirazione.
Anche se mi piace definirmi uno "sviluppatore Linkerd", la realtà è che sono più un manutentore del file README.md in un progetto. Oggi lavoro su Linkerd , , persone, e questo progetto non sarebbe stato possibile senza la straordinaria comunità di contributori e utenti.
E infine, un ringraziamento speciale al creatore di Linkerd, (primo tra i pari), che, insieme a me molti anni fa, si è tuffato a capofitto in tutto questo polverone con la rete dei servizi.
PS da traduttore
Leggi anche sul nostro blog:
- «";
- «";
- «";
- «";
- «'.
Fonte: habr.com