Service Mesh — un noto pattern architetturale per integrare i microservizi e migrare verso un'infrastruttura cloud. Oggi nel mondo del cloud e dei container, è difficile farne a meno. Diverse implementazioni open-source del service mesh sono già disponibili sul mercato, ma la loro funzionalità, affidabilità e sicurezza non sempre sono sufficienti, soprattutto quando si tratta delle esigenze di grandi aziende finanziarie a livello nazionale. Perciò, noi di Sbertech abbiamo deciso di personalizzare il Service Mesh e vogliamo raccontarvi cosa c'è di interessante nel Service Mesh, cosa non va e cosa intendiamo fare al riguardo.
La popolarità del pattern Service Mesh cresce insieme a quella delle tecnologie cloud. Si tratta di uno strato infrastrutturale dedicato che facilita l'interazione tra diversi servizi di rete. Le moderne applicazioni cloud sono composte da centinaia e persino migliaia di questi servizi, ciascuno dei quali può avere migliaia di copie.
L'interazione tra questi servizi e la loro gestione è la chiave del Service Mesh. In effetti, si tratta di un modello di rete composto da numerosi proxy, gestiti centralmente e che eseguono un insieme di funzioni estremamente utili.
A livello proxy (data plane):
- Assegnazione e diffusione di politiche di instradamento e bilanciamento del traffico
- Diffusione di chiavi, certificati, token
- Raccolta di telemetria, creazione di metriche di monitoraggio
- Integrazione con infrastrutture di sicurezza e monitoraggio
A livello di piano di controllo (control plane):
- Applicazione di politiche di instradamento e bilanciamento del traffico
- Gestione delle ripetizioni e dei timeout, identificazione dei nodi "mortos" (circuit breaking), gestione delle situazioni di errore (injecting faults) e garantire la resilienza dei servizi attraverso altri meccanismi
- Autenticazione/autorizzazione delle chiamate
- Scarto delle metriche (observability)
Il gruppo di utenti interessati allo sviluppo di questa tecnologia è molto ampio, da piccole startup a grandi corporation internet, come PayPal.
A cosa serve il Service Mesh nel settore corporate
L'uso del Service Mesh porta numerosi vantaggi evidenti. Prima di tutto, è semplicemente comodo per gli sviluppatori: per scrivere codice nasce una piattaforma tecnologica, che semplifica notevolmente l'integrazione nell'infrastruttura cloud consentendo un completo isolamento del layer di trasporto dalla logica applicativa.
Inoltre, Il Service Mesh semplifica le relazioni tra fornitori e consumatori. Oggi, i fornitori e i consumatori di API possono facilmente concordare su interfacce e contratti autonomamente, senza coinvolgere un mediatore o un arbitro specializzato come una corporate service bus. Questo approccio ha un impatto significativo su due parametri: aumenta la velocità di immissione della nuova funzionalità sul mercato (time-to-market), ma al contempo alza i costi delle soluzioni, poiché l'integrazione deve essere effettuata autonomamente. L'uso del Service Mesh da parte dei team di sviluppo delle funzionalità aziendali consente di mantenere un giusto equilibrio. Alla fine, i fornitori di API possono concentrarsi esclusivamente sulla componente applicativa del loro servizio e semplicemente pubblicarla nel Service Mesh: l'API diventerà immediatamente disponibile a tutti i clienti, mentre la qualità dell'integrazione sarà pronta per la produzione e non richiederà alcuna riga di codice aggiuntivo.
Un ulteriore vantaggio è che lo sviluppatore, utilizzando Service Mesh, si concentra esclusivamente sulla funzionalità aziendale — sulla componente di prodotto, piuttosto che su quella tecnologica del suo servizio. Ad esempio, non è più necessario preoccuparsi del fatto che, in una situazione in cui il servizio viene richiamato attraverso la rete, possa verificarsi un'interruzione della connessione. Inoltre, Service Mesh aiuta a bilanciare il traffico tra le copie dello stesso servizio: se una copia "è morta", il sistema reindirizzerà tutto il traffico sulle copie rimanenti attive.
Service Mesh — questa è una buona base per la creazione di applicazioni distribuite, che nasconde al cliente i dettagli di come vengono effettuate le chiamate ai suoi servizi, sia interna che esternamente. Tutte le applicazioni che utilizzano Service Mesh sono isolate a livello di trasporto sia dalla rete che l'una dall'altra: non c'è alcuna connessione tra di esse. In questo modo, lo sviluppatore ottiene un controllo totale sui propri servizi.
È importante notare che l'aggiornamento delle applicazioni distribuite in un ambiente in cui è utilizzato Service Mesh diventa più semplice. Ad esempio, il deployment blue/green, dove sono disponibili due ambienti per l'applicazione, uno dei quali non viene aggiornato e rimane in standby. Il rollback a una versione precedente in caso di un rilascio non riuscito viene gestito da un router speciale, un compito che viene svolto perfettamente dal Service Mesh.. È possibile utilizzare anche il rilascio canarino per testare una nuova versione, passando al nuovo aggiornamento solo il 10% del traffico o le richieste di un gruppo pilota di clienti. Il traffico principale continua a dirigersi verso la vecchia versione, senza interruzioni.
Inoltre Il Service Mesh ci offre il controllo SLA in tempo reale. Un sistema di proxy distribuiti impedirà che il servizio venga compromesso quando alcuni clienti supereranno la loro quota assegnata. Se la larghezza di banda per l'API è limitata, nessuno potrà sovraccaricarla con un numero elevato di transazioni: il Service Mesh si frappone tra il servizio e il traffico indesiderato. Questo verrà semplicemente filtrato nel livello di integrazione, mentre i servizi stessi continueranno a funzionare senza accorgersene.
Se un'azienda desidera ridurre i costi per lo sviluppo di soluzioni di integrazione, il Service Mesh è una soluzione utile: con la sua versione open-source si può passare dai prodotti commerciali.. Il nostro Enterprise Service Mesh si basa sulla versione open-source di Service Mesh.
Un altro vantaggio è la presenza di un set integrato completo di servizi di integrazione. Poiché tutta l'integrazione avviene tramite questo strato intermedio, possiamo gestire tutto il traffico di integrazione e le relazioni tra le applicazioni che costituiscono il nucleo del business dell'azienda. Questo è molto comodo.
E infine Il Service Mesh stimola l'azienda a passare a un'infrastruttura dinamica. Ora molti si stanno orientando verso la containerizzazione. Suddividere un monolite in microservizi e integrare tutto questo in modo elegante è un tema in ascesa. Ma quando tenti di migrare a una nuova infrastruttura un sistema che è in produzione da molti anni, ti trovi immediatamente di fronte a tutta una serie di problemi: imballare tutto in container e distribuirlo su una piattaforma non è semplice. E l'implementazione, la sincronizzazione e l'interazione di questi componenti distribuiti costituiscono un'altra sfida complessa. Come comunicheranno tra di loro? Ci saranno fallimenti a cascata? Il Service Mesh aiuta a risolvere parte di questi problemi e facilita la migrazione da una vecchia architettura a una nuova, permettendo di dimenticare la logica dello scambio di rete.
Perché è necessaria la personalizzazione di Service Mesh
Nella nostra azienda convivono centinaia di sistemi e moduli, e il runtime è molto carico. Quindi il semplice modello in cui un sistema chiama un altro e riceve una risposta non è sufficiente; 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 e può immediatamente proporre un'offerta pertinente. Per implementare questa funzionalità, si utilizza un pattern architetturale chiamato architettura orientata agli eventi (event-driven architecture, EDA). Nessun Service Mesh attuale supporta nativamente tali pattern, il che è molto importante, soprattutto per le banche!
È piuttosto strano che tutte le versioni di Service Mesh supportino il 'Remote Procedure Call' (RPC), ma non siano compatibili con l'EDA. Perché Service Mesh è simile a una moderna integrazione distribuita, mentre l'EDA è un pattern architetturale molto attuale che consente di creare esperienze uniche per il cliente.
Il nostro Enterprise Service Mesh deve affrontare questo problema. Inoltre, desideriamo vedere l'implementazione della consegna garantita, dell'elaborazione in streaming e dell'elaborazione complessa degli eventi utilizzando una varietà di filtri e modelli.
Servizio di trasferimento file
Oltre all'EDA, sarebbe utile avere la possibilità di trasferire file: a livello aziendale, l'integrazione dei file è spesso l'unica opzione praticabile. In particolare, si utilizza il modello architetturale ETL (Extract, Transform, Load — "estrazione, trasformazione, caricamento"). In questo modello, in genere, si scambiano solo file: si utilizzano grandi dati che non è pratico inviare tramite richieste singole. La possibilità di supporto nativo per il trasferimento dei file nell'Enterprise Service Mesh offre la flessibilità necessaria per il business.
Servizio di orchestrazione
Nelle grandi organizzazioni ci sono quasi sempre diversi team che creano prodotti diversi. Ad esempio, in una banca, alcuni team lavorano con i depositi, mentre altri si concentrano sui prodotti di credito, e ci sono molti casi simili. Sono persone diverse, team diversi, che sviluppano i loro prodotti, progettano le loro API e le rendono доступibili ad altri. Spesso sorge la necessità di comporre questi servizi e implementare logiche complesse di chiamata sequenziale di un insieme di API. Per risolvere questo problema è necessario un approccio nell'ambito dell'integrazione, che semplifichi tutta questa logica composita (chiamate a più API, descrizione dei percorsi delle richieste, ecc.). Questo è ciò che fa il servizio di orchestrazione in un Enterprise Service Mesh.
AI e ML
Quando i microservizi comunicano attraverso un unico strato di integrazione, il Service Mesh è naturalmente al corrente di tutte le chiamate di ogni servizio. Raccogliamo la telemetria: chi chiama 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 genera Big Data. Questi dati possono essere analizzati utilizzando strumenti di intelligenza artificiale, machine learning, ecc., e successivamente si possono realizzare utili applicazioni basate sui risultati dell'analisi. Sarebbe opportuno delegare almeno in parte all'intelligenza artificiale la gestione di tutto questo traffico di rete e delle chiamate delle applicazioni integrate nel Service Mesh.
Servizio API Gateway
In genere, nel Service Mesh ci sono proxy e servizi che interagiscono tra loro all'interno di un perimetro di fiducia. Tuttavia, esistono anche controparti esterne. Le richieste API fornite a questo gruppo di consumatori sono molto più serie. Questa attività è suddivisa in due parti principali.
- Sicurezza. Questioni relative a ddos, vulnerabilità dei protocolli, applicazioni, sistemi operativi e così via.
- Scalabilità. Quando gli account API, che devono essere forniti ai clienti, raggiungono migliaia o addirittura centinaia di migliaia, diventa necessario avere uno strumento per gestire questo insieme di API. È essenziale monitorare continuamente le API: se funzionano o meno, in quale stato si trovano, quale traffico stanno generando, quali statistiche, ecc. Il gateway API deve affrontare questo compito, rendendo l'intero processo gestibile e sicuro. Grazie a questo componente, l'Enterprise Service Mesh impara a pubblicare senza complicazioni sia API interne che esterne.
Servizio di supporto per protocolli e formati dati specifici (gateway AS)
Attualmente, la maggior parte delle soluzioni Service Mesh può operare nativamente solo con traffico HTTP e HTTP2 o in modalità limitata a livello TCP/IP. L'Enterprise Service Mesh introduce molti altri protocolli di trasferimento dati molto specifici. Alcuni sistemi possono utilizzare broker di messaggi, altri sono integrati a livello di database. Se in azienda è presente SAP, questo può utilizzare la propria sistema di integrazione. Inoltre, tutto ciò funziona ed è una parte fondamentale del business.
Non si può semplicemente dire: «Smettiamo di usare il legacy e creiamo nuovi sistemi che possano utilizzare il Service Mesh». Per collegare tutti i vecchi sistemi a quelli nuovi (con architettura a microservizi), i sistemi che possono utilizzare il Service Mesh necessiteranno di un adattatore, intermediario o gateway. Sarebbe fantastico se venisse fornito in bundle con il servizio. Il Gateway AS può supportare qualsiasi tipo di integrazione. Immaginate di installare semplicemente l'Enterprise Service Mesh e di avere già tutto pronto per interagire con i protocolli di cui avete bisogno. Per noi, questo approccio è molto importante.
Circa in questo modo immaginiamo la versione aziendale del Service Mesh (Enterprise Service Mesh). La personalizzazione descritta risolve la maggior parte dei problemi che si presentano nell'utilizzo delle versioni open-source pronte dell'integrazione della piattaforma. Apparso solo un paio di anni fa, l'architettura del Service Mesh continua a evolversi, e siamo felici di poter contribuire al suo sviluppo. Speriamo che la nostra esperienza possa esservi utile.
Fonte: habr.com
