Service Mesh — un noto pattern architetturale per l'integrazione di microservizi e la migrazione verso infrastrutture cloud. Oggi nel mondo dei container cloud è piuttosto difficile fare a meno di esso. Diverse implementazioni open-source del service mesh sono già disponibili sul mercato, ma la loro funzionalità, affidabilità e sicurezza non sono sempre sufficienti, soprattutto quando si tratta delle esigenze di grandi compagnie finanziarie a livello nazionale. Pertanto, noi di SberTech abbiamo deciso di personalizzare il Service Mesh e vogliamo parlare di ciò che è interessante nel Service Mesh, cosa non lo è e cosa intendiamo fare al riguardo.
La popolarità del pattern Service Mesh cresce insieme alla diffusione delle tecnologie cloud. Esso rappresenta uno strato infrastrutturale dedicato che semplifica l'interazione tra i vari servizi di rete. Le moderne applicazioni cloud sono costituite da centinaia e persino migliaia di questi servizi, ognuno dei quali può avere migliaia di copie.
L'interazione tra questi servizi e la loro gestione è la chiave del Service Mesh. Di fatto, si tratta di un modello di rete composto da numerosi proxy, gestiti centralmente e che svolgono un insieme di funzioni molto utili.
A livello di proxy (data plane):
- Assegnazione e distribuzione delle politiche di instradamento e bilanciamento del traffico
- Distribuzione di chiavi, certificati, token
- Raccolta di telemetria, creazione di metriche di monitoraggio
- Integrazione con l'infrastruttura di sicurezza e monitoraggio
A livello del piano di controllo (control plane):
- Applicazione delle politiche di instradamento e bilanciamento del traffico
- Gestione dei retry e dei timeout, individuazione dei nodi "mortali" (circuit breaking), gestione delle situazioni di errore (injecting faults) e garanzia di resilienza (resilience) dei servizi tramite altri meccanismi
- Autenticazione/autorizzazione delle chiamate
- Scartamento delle metriche (observability)
Il pubblico di utenti interessati allo sviluppo di questa tecnologia è molto ampio — da piccole startup a grandi corporazioni internet, come PayPal.
A cosa serve il Service Mesh nel settore aziendale
L'uso del Service Mesh porta molti vantaggi evidenti. Prima di tutto, è molto conveniente per gli sviluppatori: per scrivere codice nasce una piattaforma tecnologica, che semplifica notevolmente l'integrazione nell'infrastruttura cloud grazie al fatto che il livello di trasporto è completamente isolato dalla logica applicativa.
Inoltre, Service Mesh semplifica le relazioni tra fornitori e consumatori. Oggi è molto più facile per i fornitori e i consumatori di API concordare autonomamente su interfacce e contratti, senza coinvolgere un intermediario di integrazione speciale e arbitro — la bus di servizio aziendale. Questo approccio influisce significativamente su due indicatori. Aumenta la velocità di immissione di nuove funzionalità sul mercato (time-to-market), ma al contempo aumenta il costo della soluzione, poiché l'integrazione deve essere effettuata autonomamente. L'uso di Service Mesh da parte dei team di sviluppo delle funzionalità aziendali consente di mantenere un equilibrio in questo. Alla fine, i fornitori di API possono concentrarsi esclusivamente sugli aspetti applicativi del loro servizio e semplicemente pubblicarlo nel Service Mesh — l'API sarà immediatamente disponibile per tutti i clienti e la qualità dell'integrazione sarà pronta per il production e non richiederà righe aggiuntive di codice.
Il prossimo vantaggio è che lo sviluppatore, utilizzando Service Mesh, si concentra esclusivamente sulla funzionalità aziendale — sugli aspetti di prodotto e non su quelli tecnologici del proprio servizio. Ad esempio, non è più necessario preoccuparsi del fatto che, in situazioni in cui il servizio viene chiamato tramite rete, si possa verificare un'interruzione della connessione. Inoltre, Service Mesh aiuta a bilanciare il traffico tra le copie della stessa identità di servizio: se una delle copie "è morta", il sistema dirigerà tutto il traffico sulle copie rimaste attive.
Service Mesh — è una buona base per la creazione di applicazioni distribuite, che nasconde al cliente i dettagli dell'invocazione dei suoi servizi sia internamente che esternamente. Tutte le applicazioni che utilizzano Service Mesh sono isolate a livello di trasporto sia dalla rete sia tra di loro: non vi è alcuna connessione tra di esse. In questo modo, lo sviluppatore ottiene un controllo completo sui propri servizi.
È importante notare che l'aggiornamento delle applicazioni distribuite in un ambiente dove viene utilizzato Service Mesh diventa più semplice. Ad esempio, il blue/green deployment, in cui sono disponibili due ambienti per l'installazione dell'applicazione, uno dei quali non viene aggiornato e rimane in attesa. Il rollback a una versione precedente in caso di rilascio fallito avviene tramite un router speciale, un compito che il Service Mesh gestisce perfettamente.. Per testare una nuova versione, si può usare anche il rilascio canary — reindirizzare il 10% del traffico o le richieste di un gruppo pilota di clienti alla nuova versione. La maggior parte del traffico va alla vecchia versione, niente si rompe.
Anche Il Service Mesh ci offre il controllo SLA in tempo reale. Il sistema di proxy distribuiti non permetterà di sovraccaricare il servizio quando qualcuno dei clienti supera la quota assegnata. Se la larghezza di banda dell'API è limitata, nessuno potrà effettuare un attacco DDoS con un numero eccessivo di transazioni: il Service Mesh si posiziona davanti al servizio e non consente il traffico eccessivo. Sarà semplicemente respinto nel livello di integrazione, mentre i servizi continueranno a funzionare senza accorgersene.
Se un'azienda desidera ridurre i costi per lo sviluppo di soluzioni di integrazione, il Service Mesh è d'aiuto anche in questo caso: si può passare alla sua versione open-source da prodotti commerciali. Il nostro Enterprise Service Mesh è basato sulla versione open-source del Service Mesh.
Un altro vantaggio è la presenza di un set completo di servizi di integrazione. Poiché tutta l'integrazione è costruita tramite questo strato intermedio, possiamo gestire tutto il traffico di integrazione e le relazioni tra le applicazioni che formano il nucleo aziendale. È molto comodo.
E infine il Service Mesh stimola l'azienda a passare a un'infrastruttura dinamica. Attualmente molti si orientano verso la containerizzazione. Separare il monolite in microservizi e implementare tutto ciò in modo elegante è un argomento in crescita. Ma quando si cerca di trasferire su nuovi binari un sistema che è in produzione da molti anni, ci si trova subito di fronte a una serie di problemi: imballare tutto in contenitori e distribuirlo sulla piattaforma non è facile. L'implementazione, la sincronizzazione e l'interazione di questi componenti distribuiti è un tema particolarmente complesso. Come comunicheranno tra di loro? Ci saranno fallimenti a catena? Il Service Mesh permette di risolvere parte di questi problemi e facilita la migrazione da una vecchia architettura a una nuova, consentendo di dimenticare la logica dello scambio di rete.
Perché è necessaria la personalizzazione del Service Mesh
Nella nostra azienda convivono centinaia di sistemi e moduli, e il runtime è molto carico. Quindi un semplice schema, in cui un sistema chiama un altro e riceve una risposta, non è sufficiente, perché in produzione vogliamo di più. Cosa serve ancora a un Service Mesh aziendale?
Servizio di elaborazione eventi
Immaginiamo di dover realizzare un'elaborazione eventi in tempo reale: un sistema che analizza le azioni del cliente in tempo reale e può subito fargli un'offerta pertinente. Per implementare tale funzionalità, si utilizza un pattern architettonico chiamato architettura basata su eventi (EDA). Nessun Service Mesh attuale supporta nativamente questi pattern, ed è molto importante, soprattutto per una banca!
È piuttosto strano che il 'remote procedure call' (RPC) sia supportato da tutte le versioni del Service Mesh, mentre non ci sia compatibilità con l'EDA. Questo perché il Service Mesh è simile a un'integrazione distribuita moderna, mentre l'EDA è un pattern architettonico molto attuale che permette di fare cose uniche in termini di esperienza del cliente.
Il nostro Enterprise Service Mesh deve risolvere questo problema. Inoltre, vogliamo che implementi la consegna garantita, l'elaborazione degli eventi in streaming e complessa, utilizzando vari filtri e template.
Servizio di trasferimento file
Oltre a EDA, sarebbe utile avere la possibilità di trasferire file: nelle grandi aziende, spesso l'unica integrazione praticabile è quella basata su file. In particolare, viene utilizzato lo schema architetturale ETL (Extract, Transform, Load - 'estrazione, trasformazione, caricamento'). Di solito, tutti scambiano esclusivamente file: si utilizzano big data che non è pratico inviare tramite richieste singole. La possibilità di supportare nativamente il trasferimento di file in un Enterprise Service Mesh fornisce la flessibilità necessaria per il business.
Servizio di orchestrazione
Nelle grandi organizzazioni ci sono quasi sempre team diversi che realizzano prodotti differenti. Ad esempio, in una banca alcuni team si occupano dei depositi, mentre altri dei prodotti creditizi, e ci sono molti di questi casi. Sono persone diverse, team diversi, che creano i loro prodotti, sviluppano le loro API e le forniscono agli altri. Spesso sorge la necessità di comporre questi servizi e implementare una logica complessa di chiamata sequenziale a un insieme di API. Per affrontare questa problematica, è necessario un intervento nel layer di integrazione che semplifichi tutta questa logica composita (chiamata a più API, descrizione dei percorsi delle richieste, ecc.). Questo è il servizio di orchestrazione nell'Enterprise Service Mesh.
AI e ML
Quando i microservizi comunicano attraverso un layer di integrazione unico, il Service Mesh naturalmente conosce tutto sulle chiamate di ogni servizio. Raccogliamo telemetria: chi ha chiamato chi, quando, quanto a lungo, quante volte e così via. Quando questi servizi sono centinaia di migliaia e le chiamate sono miliardi, tutto ciò si accumula e forma Big Data. Questi dati possono essere analizzati tramite strumenti di IA, machine learning, ecc., e successivamente si possono realizzare delle cose utili basate sui risultati dell'analisi. Sarebbe opportuno affidare almeno parzialmente all'intelligenza artificiale la gestione di tutto questo traffico di rete e delle chiamate alle applicazioni integrate nel Service Mesh.
Servizio API Gateway
Di solito, nel Service Mesh ci sono proxy e servizi che interagiscono tra loro all'interno di un perimetro fidato. Ma ci sono anche controparti esterne. Le richieste per le API fornite a questo gruppo di consumatori sono molto più severe. Questa attività viene suddivisa in due parti principali.
- Sicurezza. Questioni relative a ddos, vulnerabilità di protocolli, applicazioni, sistemi operativi, e così via.
- Dimensioni. Quando il numero di API da fornire ai clienti raggiunge migliaia o addirittura centinaia di migliaia, si rende necessaria una qualche forma di gestione di questo insieme di API. È fondamentale monitorare continuamente le API: se funzionano o meno, quale sia il loro stato, quale traffico riceve, quali siano le statistiche, ecc. Il gateway API deve affrontare questo compito, rendendo l'intero processo gestibile e sicuro. Grazie a questo componente, l'Enterprise Service Mesh apprende a pubblicare senza complicazioni sia le API interne che quelle esterne.
Servizio di supporto per protocolli e formati di dati specifici (gateway AS)
Attualmente, la maggior parte delle soluzioni Service Mesh è in grado di lavorare nativamente solo con il traffico HTTP e HTTP2 o in una modalità ridotta a livello TCP/IP. L'Enterprise Service Mesh introduce molti altri protocolli di trasmissione dati piuttosto specifici. Alcuni sistemi possono utilizzare broker di messaggi, mentre altri sono integrati a livello di database. Se in azienda è presente SAP, esso può anche utilizzare un proprio sistema di integrazione. E tutto ciò funziona ed è una parte importante del business.
Non si può semplicemente dire: «Rinunciamo al legacy e creiamo nuovi sistemi che possano utilizzare Service Mesh». Per far cooperare tutti i vecchi sistemi con i nuovi (su architettura a microservizi), i sistemi in grado di utilizzare Service Mesh avranno bisogno di un adattatore, un intermediario, un gateway. D'accordo, sarebbe fantastico se fosse fornito nella confezione insieme al servizio. Il gateway AS può supportare qualsiasi opzione di integrazione. Immaginate, installate semplicemente l'Enterprise Service Mesh e già è pronto a interagire con tutti i protocolli di cui avete bisogno. Per noi, questo approccio è molto importante.
Circa così immaginiamo la versione aziendale di Service Mesh (Enterprise Service Mesh). La personalizzazione descritta risolve la maggior parte dei problemi che sorgono quando si tenta di utilizzare le versioni open-source pronte di una piattaforma di integrazione. Apparso solo un paio di anni fa, l'architettura Service Mesh continua a svilupparsi e siamo felici di poter partecipare al suo sviluppo. Speriamo che la nostra esperienza possa esservi utile.
Fonte: habr.com
