Service Mesh è un modello architettonico noto per l'integrazione di microservizi e la migrazione all'infrastruttura cloud. Oggi nel mondo dei contenitori cloud è abbastanza difficile farne a meno. Sul mercato sono già disponibili diverse implementazioni di service mesh open source, ma la loro funzionalità, affidabilità e sicurezza non sono sempre sufficienti, soprattutto quando si tratta delle esigenze delle grandi società finanziarie in tutto il paese. Ecco perché noi di Sbertech abbiamo deciso di personalizzare Service Mesh e vogliamo parlare di cosa è interessante in Service Mesh, cosa non è così interessante e cosa faremo al riguardo.
La popolarità del modello Service Mesh sta crescendo con la popolarità delle tecnologie cloud. È un livello infrastrutturale dedicato che semplifica l'interazione tra diversi servizi di rete. Le moderne applicazioni cloud sono costituite da centinaia o addirittura migliaia di tali servizi, ciascuno dei quali può avere migliaia di copie.
L'interazione e la gestione di questi servizi è un compito chiave del Service Mesh. Si tratta infatti di un modello di rete composto da molti proxy, gestiti centralmente e che svolgono una serie di funzioni molto utili.
A livello proxy (piano dati):
- Assegnazione e distribuzione delle politiche di routing e bilanciamento del traffico
- Distribuzione di chiavi, certificati, token
- Raccolta di telemetria, generazione di metriche di monitoraggio
- Integrazione con infrastrutture di sicurezza e monitoraggio
A livello del piano di controllo:
- Applicazione di politiche di routing e bilanciamento del traffico
- Gestire tentativi e timeout, rilevare nodi "morti" (interruzione del circuito), gestire l'immissione di guasti e garantire la resilienza del servizio attraverso altri meccanismi
- Autenticazione/autorizzazione della chiamata
- Eliminazione delle metriche (osservabilità)
La gamma di utenti interessati allo sviluppo di questa tecnologia è molto ampia: dalle piccole startup alle grandi società Internet, ad esempio PayPal.
Perché è necessario Service Mesh nel settore aziendale?
I vantaggi derivanti dall'utilizzo di un Service Mesh sono numerosi ed evidenti. Prima di tutto, è semplicemente conveniente per gli sviluppatori: per scrivere codice appare 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 il rapporto tra fornitori e consumatori. Oggi è molto più semplice per i fornitori di API e i consumatori concordare autonomamente interfacce e contratti, senza coinvolgere uno speciale intermediario e arbitro di integrazione: l'enterprise service bus. Questo approccio influisce in modo significativo su due indicatori. La velocità con cui vengono immesse nuove funzionalità sul mercato (time-to-market) aumenta, ma allo stesso tempo aumenta il costo della soluzione, poiché l'integrazione deve essere effettuata in modo indipendente. L'uso di Service Mesh da parte dei team di sviluppo delle funzionalità aziendali aiuta a mantenere un equilibrio in questo caso. Di conseguenza, i fornitori di API possono concentrarsi esclusivamente sulla componente applicativa del proprio servizio e pubblicarla semplicemente nel Service Mesh: l'API diventerà immediatamente disponibile per tutti i clienti e la qualità dell'integrazione sarà pronta per la produzione e non richiederà un singolo riga di codice aggiuntivo.
Il prossimo vantaggio è quello lo sviluppatore, utilizzando Service Mesh, si concentra esclusivamente sulle funzionalità aziendali — sul prodotto piuttosto che sulla componente tecnologica del suo servizio. Ad esempio, non è più necessario pensare al fatto che in una situazione in cui un servizio viene richiamato sulla rete, da qualche parte potrebbe verificarsi un errore di connessione. Inoltre, Service Mesh aiuta a bilanciare il traffico tra copie dello stesso servizio: se una delle copie “muore”, il sistema trasferirà tutto il traffico alle restanti copie attive.
Rete di servizio - questa è una buona base per creare applicazioni distribuite, che nasconde al cliente i dettagli della fornitura di chiamate ai suoi servizi sia internamente che esternamente. Tutte le applicazioni che utilizzano Service Mesh sono isolate a livello di trasporto sia dalla rete che tra loro: non c'è comunicazione tra loro. In questo caso, lo sviluppatore riceve il pieno controllo sui suoi servizi.
Si dovrebbe notare che L'aggiornamento delle applicazioni distribuite in un ambiente mesh di servizi diventa più semplice. Ad esempio, una distribuzione blu/verde, in cui sono disponibili per l'installazione due ambienti applicativi, uno dei quali non è aggiornato ed è in modalità standby. Il rollback alla versione precedente in caso di rilascio non riuscito viene eseguito da un router speciale, il ruolo del quale Service Mesh si adatta bene. Per testare la nuova versione, è possibile utilizzare rilascio del canarino — passa alla nuova versione solo il 10% del traffico o delle richieste provenienti da un gruppo pilota di clienti. Il traffico principale va alla vecchia versione, non si rompe nulla.
anche Service Mesh ci offre il controllo degli SLA in tempo reale. Il sistema proxy distribuito non consentirà il fallimento del servizio quando uno dei client supera la quota assegnatagli. Se il throughput dell’API è limitato, nessuno potrà sovraccaricarla con un gran numero di transazioni: il Service Mesh sta di fronte al servizio e non permette traffico non necessario. Reagirà semplicemente nel livello di integrazione e i servizi stessi continueranno a funzionare senza accorgersene.
Se un'azienda vuole ridurre i costi per lo sviluppo di soluzioni di integrazione, Service Mesh aiuta anche: Puoi passare alla sua versione open source da prodotti commerciali. Il nostro Enterprise Service Mesh si basa sulla versione open source di Service Mesh.
Un altro vantaggio - disponibilità di un unico insieme completo di servizi di integrazione. Poiché tutta l'integrazione viene realizzata tramite questo middleware, possiamo gestire tutto il traffico di integrazione e le connessioni tra le applicazioni che costituiscono il nucleo aziendale dell'azienda. È molto comodo
E infine Service Mesh incoraggia un'azienda a passare a un'infrastruttura dinamica. Ora molti guardano alla containerizzazione. Tagliare un monolite in microservizi, implementare tutto questo magnificamente: l'argomento è in aumento. Ma quando si prova a trasferire un sistema in produzione da molti anni su una nuova piattaforma, si incontrano subito una serie di problemi: spingere il tutto nei container e distribuirlo sulla piattaforma non è facile. E l’implementazione, la sincronizzazione e l’interazione di questi componenti distribuiti è un altro argomento molto complesso. Come comunicheranno tra loro? Ci saranno guasti a cascata? Service Mesh permette di risolvere alcuni di questi problemi e facilitare la migrazione dalla vecchia architettura a quella nuova grazie al fatto che è possibile dimenticare la logica di scambio di rete.
Perché è necessaria la personalizzazione di Service Mesh?
Nella nostra azienda coesistono centinaia di sistemi e moduli e il runtime è molto carico. Quindi il semplice schema in cui un sistema ne chiama un altro e riceve una risposta non è sufficiente, perché in produzione vogliamo di più. Cos'altro ti serve da un service mesh aziendale?
Servizio di elaborazione eventi
Immaginiamo di dover realizzare l'elaborazione degli eventi in tempo reale, un sistema che analizzi le azioni del cliente in tempo reale e possa presentargli immediatamente un'offerta pertinente. Per implementare funzionalità simili, utilizzare modello architettonico chiamato architettura guidata dagli eventi (EDA). Nessuna delle attuali Service Meshes supporta nativamente tali modelli, ma questo è molto importante, soprattutto per una banca!
È abbastanza strano che RPC (Remote Procedure Call) sia supportato da tutte le versioni di Service Mesh, ma non sono compatibili con EDA. Perché Service Mesh è una sorta di moderna integrazione distribuita e EDA è un modello architettonico molto rilevante che ti consente di fare cose uniche in termini di esperienza del cliente.
La nostra Enterprise Service Mesh dovrebbe risolvere questo problema. Inoltre, vogliamo vedere in esso l'implementazione della consegna garantita, dello streaming e dell'elaborazione di eventi complessi utilizzando una varietà di filtri e modelli.
Servizio di trasferimento file
Oltre all'EDA sarebbe bello poter trasferire file: su scala aziendale molto spesso è possibile solo l'integrazione dei file. In particolare viene utilizzato il pattern architetturale ETL (Extract, Transform, Load). In esso, di regola, tutti si scambiano file esclusivamente: vengono utilizzati i big data, che non è pratico inserire richieste separate. La capacità di supportare in modo nativo i trasferimenti di file in Enterprise Service Mesh ti offre la flessibilità di cui la tua azienda ha bisogno.
Servizio di orchestrazione
Le grandi organizzazioni hanno quasi sempre team diversi che realizzano prodotti diversi. Ad esempio, in una banca, alcuni team lavorano con i depositi, mentre altri lavorano con prodotti di prestito, e ci sono molti casi simili. Si tratta di persone diverse, team diversi che realizzano i loro prodotti, sviluppano le loro API e li forniscono ad altri. E molto spesso è necessario comporre questi servizi, nonché implementare una logica complessa per chiamare in sequenza un insieme di API. Per risolvere questo problema, è necessaria una soluzione nel livello di integrazione che semplifichi tutta questa logica composita (chiamata di diverse API, descrizione del percorso della richiesta, ecc.). Questo è il servizio di orchestrazione in Enterprise Service Mesh.
IA e ML
Quando i microservizi comunicano attraverso un singolo livello di integrazione, Service Mesh sa naturalmente tutto sulle chiamate di ciascun servizio. Raccogliamo i dati di telemetria: chi ha chiamato chi, quando, per quanto tempo, quante volte e così via. Quando ci sono centinaia di migliaia di questi servizi e miliardi di chiamate, tutto ciò si accumula e forma i Big Data. Questi dati possono essere analizzati utilizzando l'intelligenza artificiale, l'apprendimento automatico, ecc., quindi è possibile fare alcune cose utili in base ai risultati dell'analisi. Sarebbe opportuno cedere almeno parzialmente all’intelligenza artificiale il controllo di tutto questo traffico di rete e delle chiamate applicative integrate nel Service Mesh.
Servizio gateway API
In genere, un Service Mesh dispone di proxy e servizi che comunicano tra loro all'interno di un perimetro attendibile. Ma ci sono anche controparti esterne. I requisiti per le API esposte a questo gruppo di consumatori sono molto più severi. Dividiamo questo compito in due parti principali.
- sicurezza. Problemi relativi a DDOS, vulnerabilità di protocolli, applicazioni, sistemi operativi e così via.
- la scala. Quando il numero di API che devono essere fornite ai clienti raggiunge le migliaia o addirittura le centinaia di migliaia, è necessario un qualche tipo di strumento di gestione per questo set di API. È necessario monitorare costantemente le API: se funzionano o meno, qual è il loro stato, quale traffico scorre, quali statistiche, ecc. Un gateway API dovrebbe gestire questa attività rendendo l'intero processo gestibile e sicuro. Grazie a questo componente, Enterprise Service Mesh impara a pubblicare facilmente API sia interne che esterne.
Servizio di supporto per protocolli e formati dati specifici (gateway AS)
Attualmente la maggior parte delle soluzioni Service Mesh può funzionare in modo nativo solo con traffico HTTP e HTTP2 oppure in modalità ridotta a livello TCP/IP. L'Enterprise Service Mesh sta emergendo con molti altri protocolli di trasferimento dati molto specifici. Alcuni sistemi possono utilizzare broker di messaggi, altri sono integrati a livello di database. Se l'azienda dispone di SAP, può anche utilizzare il proprio sistema di integrazione. Inoltre, tutto questo funziona ed è una parte importante del business.
Non si può semplicemente dire: “Abbandoniamo l’eredità e creiamo nuovi sistemi che possano utilizzare Service Mesh”. Per connettere tutti i vecchi sistemi con quelli nuovi (su un'architettura a microservizi), i sistemi che possono utilizzare Service Mesh avranno bisogno di una sorta di adattatore, intermediario, gateway. D'accordo, sarebbe carino se arrivasse in una scatola insieme al servizio. Il gateway AC può supportare qualsiasi opzione di integrazione. Immagina, basta installare Enterprise Service Mesh ed è pronto per interagire con tutti i protocolli di cui hai bisogno. Questo approccio è molto importante per noi.
Questo è più o meno il modo in cui 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 versioni open source già pronte della piattaforma di integrazione. Introdotta solo un paio di anni fa, l'architettura Service Mesh continua a evolversi e siamo entusiasti di poter contribuire al suo sviluppo. Ci auguriamo che la nostra esperienza vi sia utile.
Fonte: habr.com