<\/a><\/noindex>
A livello di proxy (data plane):<\/i><\/p>\n\nAssegnazione e distribuzione delle politiche di instradamento e bilanciamento del traffico\n<\/li>\n Distribuzione di chiavi, certificati, token\n<\/li>\n Raccolta di telemetria, creazione di metriche di monitoraggio\n<\/li>\n Integrazione con l'infrastruttura di sicurezza e monitoraggio\n<\/li>\n<\/ul>\n\nA livello del piano di controllo (control plane):<\/i><\/p>\n\nApplicazione delle politiche di instradamento e bilanciamento del traffico\n<\/li>\n 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\n<\/li>\n Autenticazione\/autorizzazione delle chiamate\n<\/li>\n Scartamento delle metriche (observability)\n<\/li>\n<\/ul>\n\nIl pubblico di utenti interessati allo sviluppo di questa tecnologia \u00e8 molto ampio \u2014 da piccole startup a grandi corporazioni internet, come PayPal.<\/p>\n
A cosa serve il Service Mesh nel settore aziendale<\/h2>\n \nL'uso del Service Mesh porta molti vantaggi evidenti. Prima di tutto, \u00e8 molto conveniente per gli sviluppatori: per scrivere codice nasce una piattaforma tecnologica<\/i>, che semplifica notevolmente l'integrazione nell'infrastruttura cloud grazie al fatto che il livello di trasporto \u00e8 completamente isolato dalla logica applicativa.<\/p>\n
Inoltre, Service Mesh semplifica le relazioni tra fornitori e consumatori.<\/i> Oggi \u00e8 molto pi\u00f9 facile per i fornitori e i consumatori di API concordare autonomamente su interfacce e contratti, senza coinvolgere un intermediario di integrazione speciale e arbitro \u2014 la bus di servizio aziendale. Questo approccio influisce significativamente su due indicatori. Aumenta la velocit\u00e0 di immissione di nuove funzionalit\u00e0 sul mercato (time-to-market), ma al contempo aumenta il costo della soluzione, poich\u00e9 l'integrazione deve essere effettuata autonomamente. L'uso di Service Mesh da parte dei team di sviluppo delle funzionalit\u00e0 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 \u2014 l'API sar\u00e0 immediatamente disponibile per tutti i clienti e la qualit\u00e0 dell'integrazione sar\u00e0 pronta per il production e non richieder\u00e0 righe aggiuntive di codice.<\/p>\n
Il prossimo vantaggio \u00e8 che lo sviluppatore, utilizzando Service Mesh, si concentra esclusivamente sulla funzionalit\u00e0 aziendale<\/i> \u2014 sugli aspetti di prodotto e non su quelli tecnologici del proprio servizio. Ad esempio, non \u00e8 pi\u00f9 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\u00e0 di servizio: se una delle copie \"\u00e8 morta\", il sistema diriger\u00e0 tutto il traffico sulle copie rimaste attive. <\/p>\n
Service Mesh <\/i>\u2014 \u00e8 una buona base per la creazione di applicazioni distribuite<\/i>, 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 \u00e8 alcuna connessione tra di esse. In questo modo, lo sviluppatore ottiene un controllo completo sui propri servizi.<\/p>\n
\u00c8 importante notare che l'aggiornamento delle applicazioni distribuite in un ambiente dove viene utilizzato Service Mesh diventa pi\u00f9 semplice.<\/i> 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.. <\/i>Per testare una nuova versione, si pu\u00f2 usare anche il rilascio canary <\/i>\u2014 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.<\/p>\n
Anche Il Service Mesh ci offre il controllo SLA in tempo reale<\/i>. Il sistema di proxy distribuiti non permetter\u00e0 di sovraccaricare il servizio quando qualcuno dei clienti supera la quota assegnata. Se la larghezza di banda dell'API \u00e8 limitata, nessuno potr\u00e0 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\u00e0 semplicemente respinto nel livello di integrazione, mentre i servizi continueranno a funzionare senza accorgersene.<\/p>\n
Se un'azienda desidera ridurre i costi per lo sviluppo di soluzioni di integrazione, il Service Mesh \u00e8 d'aiuto anche in questo caso: si pu\u00f2 passare alla sua versione open-source da prodotti commerciali<\/i>. Il nostro Enterprise Service Mesh \u00e8 basato sulla versione open-source del Service Mesh. <\/p>\n
Un altro vantaggio \u00e8 la presenza di un set completo di servizi di integrazione<\/i>. Poich\u00e9 tutta l'integrazione \u00e8 costruita tramite questo strato intermedio, possiamo gestire tutto il traffico di integrazione e le relazioni tra le applicazioni che formano il nucleo aziendale. \u00c8 molto comodo.<\/p>\n
E infine il Service Mesh stimola l'azienda a passare a un'infrastruttura dinamica.<\/i> Attualmente molti si orientano verso la containerizzazione. Separare il monolite in microservizi e implementare tutto ci\u00f2 in modo elegante \u00e8 un argomento in crescita. Ma quando si cerca di trasferire su nuovi binari un sistema che \u00e8 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 \u00e8 facile. L'implementazione, la sincronizzazione e l'interazione di questi componenti distribuiti \u00e8 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.<\/p>\nPerch\u00e9 \u00e8 necessaria la personalizzazione del Service Mesh<\/h2>\n
\nNella nostra azienda convivono centinaia di sistemi e moduli, e il runtime \u00e8 molto carico. Quindi un semplice schema, in cui un sistema chiama un altro e riceve una risposta, non \u00e8 sufficiente, perch\u00e9 in produzione vogliamo di pi\u00f9. Cosa serve ancora a un Service Mesh aziendale? <\/p>\n
Servizio di elaborazione eventi<\/h3>\n \nImmaginiamo di dover realizzare un'elaborazione eventi in tempo reale: un sistema che analizza le azioni del cliente in tempo reale e pu\u00f2 subito fargli un'offerta pertinente. Per implementare tale funzionalit\u00e0, si utilizza un pattern architettonico chiamato architettura basata su eventi (EDA)<\/i>. Nessun Service Mesh attuale supporta nativamente questi pattern, ed \u00e8 molto importante, soprattutto per una banca!<\/p>\n
\u00c8 piuttosto strano che il 'remote procedure call' (RPC) sia supportato da tutte le versioni del Service Mesh, mentre non ci sia compatibilit\u00e0 con l'EDA. Questo perch\u00e9 il Service Mesh \u00e8 simile a un'integrazione distribuita moderna, mentre l'EDA \u00e8 un pattern architettonico molto attuale che permette di fare cose uniche in termini di esperienza del cliente.<\/p>\n
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.<\/p>\n
Servizio di trasferimento file<\/h3>\n \nOltre a EDA, sarebbe utile avere la possibilit\u00e0 di trasferire file: nelle grandi aziende, spesso l'unica integrazione praticabile \u00e8 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 \u00e8 pratico inviare tramite richieste singole. La possibilit\u00e0 di supportare nativamente il trasferimento di file in un Enterprise Service Mesh fornisce la flessibilit\u00e0 necessaria per il business.<\/p>\n
Servizio di orchestrazione<\/h3>\n \nNelle 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\u00e0 di comporre questi servizi e implementare una logica complessa di chiamata sequenziale a un insieme di API. Per affrontare questa problematica, \u00e8 necessario un intervento nel layer di integrazione che semplifichi tutta questa logica composita (chiamata a pi\u00f9 API, descrizione dei percorsi delle richieste, ecc.). Questo \u00e8 il servizio di orchestrazione nell'Enterprise Service Mesh.<\/p>\n
AI e ML<\/h3>\n \nQuando 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\u00ec via. Quando questi servizi sono centinaia di migliaia e le chiamate sono miliardi, tutto ci\u00f2 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.<\/p>\n
Servizio API Gateway<\/h3>\n \nDi 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\u00f9 severe. Questa attivit\u00e0 viene suddivisa in due parti principali. <\/p>\n
\nSicurezza<\/i>. Questioni relative a ddos, vulnerabilit\u00e0 di protocolli, applicazioni, sistemi operativi, e cos\u00ec via. \n<\/li>\nDimensioni<\/i>. 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. \u00c8 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.\n<\/li>\n<\/ul>\n <\/p>\n
Servizio di supporto per protocolli e formati di dati specifici (gateway AS)<\/h3>\n \nAttualmente, la maggior parte delle soluzioni Service Mesh \u00e8 in grado di lavorare nativamente solo con il traffico HTTP e HTTP2 o in una modalit\u00e0 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 \u00e8 presente SAP, esso pu\u00f2 anche utilizzare un proprio sistema di integrazione. E tutto ci\u00f2 funziona ed \u00e8 una parte importante del business.<\/p>\n
Non si pu\u00f2 semplicemente dire: \u00abRinunciamo al legacy e creiamo nuovi sistemi che possano utilizzare Service Mesh\u00bb. 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\u00f2 supportare qualsiasi opzione di integrazione. Immaginate, installate semplicemente l'Enterprise Service Mesh e gi\u00e0 \u00e8 pronto a interagire con tutti i protocolli di cui avete bisogno. Per noi, questo approccio \u00e8 molto importante.<\/p>\n
Circa cos\u00ec 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.<\/i>habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"Service Mesh \u2014 \u0438\u0437\u0432\u0435\u0441\u0442\u043d\u044b\u0439 \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u0443\u0440\u043d\u044b\u0439 \u043f\u0430\u0442\u0442\u0435\u0440\u043d \u0434\u043b\u044f \u0438\u043d\u0442\u0435\u0433\u0440\u0430\u0446\u0438\u0438 \u043c\u0438\u043a\u0440\u043e\u0441\u0435\u0440\u0432\u0438\u0441\u043e\u0432 \u0438 \u043f\u0435\u0440\u0435\u0445\u043e\u0434\u0430 \u043d\u0430 \u043e\u0431\u043b\u0430\u0447\u043d\u0443\u044e \u0438\u043d\u0444\u0440\u0430\u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u0443. \u0421\u0435\u0433\u043e\u0434\u043d\u044f \u0432 \u043e\u0431\u043b\u0430\u0447\u043d\u043e-\u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440\u043d\u043e\u043c \u043c\u0438\u0440\u0435 \u043e\u0431\u043e\u0439\u0442\u0438\u0441\u044c \u0431\u0435\u0437 \u043d\u0435\u0433\u043e \u0434\u043e\u0432\u043e\u043b\u044c\u043d\u043e \u0441\u043b\u043e\u0436\u043d\u043e. \u041d\u0430 \u0440\u044b\u043d\u043a\u0435 \u0443\u0436\u0435 \u0434\u043e\u0441\u0442\u0443\u043f\u043d\u044b \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u043e open-source \u0440\u0435\u0430\u043b\u0438\u0437\u0430\u0446\u0438\u0439 service mesh, \u043d\u043e \u0438\u0445 \u0444\u0443\u043d\u043a\u0446\u0438\u043e\u043d\u0430\u043b\u044c\u043d\u043e\u0441\u0442\u0438, \u043d\u0430\u0434\u0435\u0436\u043d\u043e\u0441\u0442\u0438 \u0438 \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u0438 \u0434\u0430\u043b\u0435\u043a\u043e \u043d\u0435 \u0432\u0441\u0435\u0433\u0434\u0430 \u0434\u043e\u0441\u0442\u0430\u0442\u043e\u0447\u043d\u043e, \u043e\u0441\u043e\u0431\u0435\u043d\u043d\u043e \u043a\u043e\u0433\u0434\u0430 \u0440\u0435\u0447\u044c \u0438\u0434\u0435\u0442 \u043e \u0442\u0440\u0435\u0431\u043e\u0432\u0430\u043d\u0438\u044f\u0445 \u0431\u043e\u043b\u044c\u0448\u0438\u0445 \u0444\u0438\u043d\u0430\u043d\u0441\u043e\u0432\u044b\u0445 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0439 \u043c\u0430\u0441\u0448\u0442\u0430\u0431\u0430 \u0432\u0441\u0435\u0439 \u0441\u0442\u0440\u0430\u043d\u044b. \u041f\u043e\u044d\u0442\u043e\u043c\u0443 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":26549,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-35388","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t
![\"Perch\u00e9](\"\/wp-content\/uploads\/2019\/06\/90b0df34323399c96548f86b6bd16522.jpg\")