Service Mesh este un model arhitectural binecunoscut pentru integrarea microserviciilor și trecerea la infrastructura cloud. Astăzi, în lumea cloud-containere, este destul de greu să ne descurcăm fără el. Pe piață sunt deja disponibile mai multe implementări open-source ale service mesh, dar funcționalitățile, fiabilitatea și securitatea lor nu sunt întotdeauna suficiente, mai ales când vine vorba de cerințele big tech-urilor financiare de talie națională. De aceea, noi, la Sbertech, am decis să personalizăm Service Mesh și dorim să împărtășim ce este grozav în Service Mesh, ce nu este și ce intenționăm să facem cu aceasta.
Popularitatea modelului Service Mesh crește odată cu popularitatea tehnologiilor cloud. Acesta reprezintă un strat de infrastructură dedicat, care simplifică interacțiunea între diferitele servicii de rețea. Aplicațiile cloud moderne sunt formate din sute și chiar mii de astfel de servicii, fiecare putând avea mii de copii.
Interacțiunea și gestionarea acestor servicii sunt sarcini esențiale pentru Service Mesh. De fapt, aceasta este un model de rețea format din numeroase proxy-uri, gestionate centralizat, care îndeplinesc un set de funcții foarte utile.
La nivelul proxy-ului (data plane):
- Alocarea și distribuirea politicilor de rutare și echilibrare a traficului
- Distribuirea cheilor, certificatelor, token-urilor
- Colectarea telemetriei, generarea metricilor de monitorizare
- Integrarea cu infrastructura de securitate și monitorizare
La nivelul planului de control (control plane):
- Aplicarea politicilor de rutare și echilibrare a traficului
- Gestionarea reluărilor și timeout-urilor, identificarea nodurilor 'moarte' (circuit breaking), gestionarea situațiilor de avarie (injecting faults) și asigurarea rezilienței serviciilor prin alte mecanisme
- Autentificarea/autorizarea apelurilor
- Eliminarea metricilor (observability)
Publicul interesat de dezvoltarea acestei tehnologii este foarte larg — de la startup-uri mici la mari corporații de internet, cum ar fi PayPal.
De ce este necesar Service Mesh în sectorul corporativ
Utilizarea Service Mesh aduce numeroase avantaje evidente. În primul rând, este pur și simplu convenabil pentru dezvoltatori: pentru scrierea codului apare o platformă tehnologică, care facilitează semnificativ integrarea în infrastructura cloud prin faptul că stratul de transport este complet izolat de logica aplicației.
În plus, Service Mesh simplifică relațiile dintre furnizori și consumatori. Astăzi, furnizorii și consumatorii de API-uri pot negocia mult mai ușor interfețele și contractele în mod autonom, fără a implica un mediator de integrare specializat și un arbitru – o architetură de servicii corporative. Această abordare influențează semnificativ două indicatori. Crește viteza de lansare a noilor funcționalități pe piață (time-to-market), dar în același timp crește costul soluției, deoarece integrarea trebuie realizată de către aceștia. Utilizarea Service Mesh de către echipele de dezvoltare a funcționalităților de business permite menținerea unui echilibru în acest sens. În cele din urmă, furnizorii de API-uri se pot concentra exclusiv pe aspectul aplicației serviciului lor și pot publica pur și simplu în Service Mesh – API-ul va deveni disponibil imediat pentru toți clienții, iar calitatea integrării va fi productie ready și nu va necesita nicio linie de cod suplimentar.
Următorul avantaj este că developer-ul, folosind Service Mesh, se concentrează exclusiv pe funcționalitățile de business — pe aspectul de produs, nu pe cel tehnologic al serviciului său. De exemplu, nu mai trebuie să se gândească la faptul că, în cazul în care serviciul este apelat prin rețea, ar putea exista o întrerupere a conexiunii undeva. În plus, Service Mesh ajută la echilibrarea traficului între instanțele aceluiași serviciu: dacă una dintre instanțe "încetează", sistemul va redirecționa tot traficul către instanțele rămase funcționale.
Service Mesh — este o bază solidă pentru crearea aplicațiilor distribuite, care ascunde de client detaliile procesului de apelare a serviciilor sale atât din interior, cât și din exterior. Toate aplicațiile care utilizează Service Mesh sunt izolate la nivel de transport de rețea și una de cealaltă: nu există nicio legătură între ele. În acest timp, developer-ul obține control total asupra serviciilor sale.
Nu se poate ignora că actualizarea aplicațiilor distribuite într-un mediu care utilizează Service Mesh devine mai simplă. De exemplu, desfășurarea blue/green, în care sunt disponibile două medii pentru instalare, una dintre ele nefiind actualizată și aflându-se în modul de așteptare. Revenirea la o versiune anterioară în cazul unei lansări nereușite se efectuează prin intermediul unui router special, rolul căruia este îndeplinit excelent de Service Mesh.. Pentru testarea unei noi versiuni se poate folosi și lansarea canarului — comutarea pe noua versiune doar pentru 10% din trafic sau cereri dintr-un grup de clienți pilot. Traficul principal se îndreaptă către vechea versiune, nimic nu se rupe.
De asemenea, Service Mesh ne oferă control SLA în timp real.. Sistemul de proxy distribuite nu va permite ca serviciul să cedeze, atunci când vreun client depășește cota atribuită. Dacă capacitatea API-ului este limitată, nimeni nu va putea să-l supună unui atac printr-un număr mare de tranzacții: Service Mesh stă în fața serviciului și nu permite traficului suplimentar. Acesta va fi oprit la nivelul de integrare, iar serviciile în sine vor continua să funcționeze, fără a observa acest lucru.
Dacă o companie dorește să reducă costurile de dezvoltare a soluțiilor de integrare, Service Mesh, de asemenea, ajută: pe versiunea sa open-source se poate trece de la produsele comerciale.. Enterprise Service Mesh-ul nostru se bazează pe versiunea open-source a Service Mesh.
Un alt avantaj este existența unui set complet unic de servicii de integrare.. Deoarece toată integrarea se desfășoară prin acest strat intermediar, putem gestiona tot traficul de integrare și relațiile dintre aplicațiile care formează nucleul de afaceri al companiei. Acest lucru este foarte comod.
Și, în final, Service Mesh stimulează compania să treacă la o infrastructură dinamică. În prezent, multe organizații se îndreaptă către containerizare. Descompunerea monolitului în microservicii și implementarea acestora într-un mod elegant este un subiect în expansiune. Totuși, când încerci să transpui un sistem care a fost în producție de mulți ani pe noi „șine”, imediat te confrunți cu o serie de probleme: să împingi totul în containere și să îl desfășori pe o platformă nu este simplu. Implementarea, sincronizarea și interacțiunea acestor componente distribuite este o altă temă complexă. Cum vor comunica între ele? Vor exista zădărniciri în cascadă? Service Mesh permite să rezolvi o parte din aceste probleme și să facilitezi migrarea de la o arhitectură veche la una nouă, deoarece poți scăpa de logica schimbului de date.
De ce este necesară personalizarea Service Mesh
În compania noastră coexistă sute de sisteme și module, iar runtime-ul este foarte solicitat. Astfel, un simplu model în care un sistem apelează altul și primește un răspuns nu este suficient, pentru că în producție dorim mai mult. Ce alte cerințe avem de la un Service Mesh corporativ?
Serviciul de procesare a evenimentelor
Să presupunem că trebuie să realizăm procesarea evenimentelor în timp real - un sistem care analizează în timp real acțiunile clienților și poate face instantaneu o ofertă relevantă. Pentru a implementa o astfel de funcționalitate, se folosește un model arhitectural denumit arhitectura bazată pe evenimente (EDA). Niciunul dintre actualele Service Mesh nu suportă nativ aceste modele, iar acest lucru este foarte important, mai ales pentru bănci!
Este destul de ciudat că apelurile la distanță Remote Procedure Call (RPC) sunt susținute de toate versiunile Service Mesh, în timp ce nu au compatibilitate cu EDA. Pentru că Service Mesh este o formă de integrare distribuită modernă, iar EDA este un model arhitectural foarte relevant, care permite realizarea de lucruri unice în ceea ce privește experiența clientului.
Enterprise Service Mesh al nostru ar trebui să rezolve această problemă. În plus, dorim să vedem în el implementarea livrării garantate, a procesării evenimentelor în timp real și integrate, utilizând diverse filtre și șabloane.
Serviciul de transfer de fișiere
Pe lângă EDA, ar fi bine să existe și posibilitatea de a transfera fișiere: în domeniul Enterprise, integrarea prin fișiere este de multe ori singura opțiune. În special, se utilizează modelul arhitectural ETL (Extract, Transform, Load — „extracție, transformare, încărcare”). În acest model, de obicei, toate schimburile se fac exclusiv prin fișiere: se folosesc date mari care nu ar fi rațional să fie transferate prin cereri individuale. Posibilitatea de suport nativ pentru transferul de fișiere în Enterprise Service Mesh oferă flexibilitatea necesară pentru afaceri.
Serviciul de orchestrare
În organizațiile mari, există aproape întotdeauna echipe diferite care dezvoltă produse diferite. De exemplu, într-o bancă, unele echipe lucrează cu depozite, iar altele — cu produse de credit. Există multe astfel de cazuri. Acestea sunt persoane diferite, echipe diferite, care își creează produsele, își dezvoltă API-urile și le oferă altora. Și foarte des apare necesitatea de a compune aceste servicii, precum și de a implementa logica complexă a apelurilor secvențiale la un set de API-uri. Pentru a rezolva această problemă, este necesară o soluție la nivelul integrării, care să simplifice toată această logică de compunere (apelarea la mai multe API-uri, descrierea traseului cererilor etc.). Aceasta este ceea ce face serviciul de orchestrare în Enterprise Service Mesh.
AI și ML
Când microserviciile comunică printr-un singur strat de integrare, Service Mesh cunoaște, desigur, toate apelurile fiecărui serviciu. Colectăm telemetrie: cine pe cine a apelat, când, cât de mult timp a durat, de câte ori și așa mai departe. Când aceste servicii ajung la sute de mii, iar apelurile la miliarde, toate acestea se acumulează și formează Big Data. Aceste date pot fi analizate cu ajutorul AI, machine learning și altele, iar apoi, pe baza rezultatelor analizei, se pot face lucruri utile. Ar fi recomandat să transferăm, măcar parțial, controlul asupra întregului trafic de rețea și apelurile aplicațiilor integrate în Service Mesh către inteligența artificială.
Serviciul API Gateway (Gateway API)
În general, în Service Mesh există proxy-uri și servicii care comunică între ele în cadrul unui perimetru de încredere. Dar există și contraparti externe. Cerințele pentru API-urile oferite acestui grup de consumatori sunt mult mai stricte. Această sarcină o împărțim în două părți principale.
- Securitate. Întrebări legate de ddos, vulnerabilitatea protocoalelor, aplicațiilor, sistemelor de operare și așa mai departe.
- Scalabilitate. Când API-urile care trebuie livrate clienților ajung la mii sau chiar sute de mii, apare necesitatea unui instrument de gestionare a acestui set de API-uri. Este esențial să monitorizăm constant API-urile: dacă funcționează sau nu, în ce stare se află, ce trafic se înregistrează, ce statistică există etc. Gateway-ul API trebuie să se ocupe de această sarcină, făcând întregul proces gestionabil și sigur. Datorită acestui component, Enterprise Service Mesh învață fără dificultăți suplimentare să publice atât API-uri interne, cât și externe.
Serviciul de suport pentru protocoale și formate de date specifice (gateway AS)
În acest moment, majoritatea soluțiilor Service Mesh pot lucra nativ doar cu traficul HTTP și HTTP2 sau în modul restricționat la nivel TCP/IP. Enterprise Service Mesh beneficiază de multe alte protocoale specifice de transmitere a datelor. Unele sisteme pot folosi intermediari de mesaje, altele sunt integrate la nivel de baze de date. Dacă în companie există SAP, acesta poate folosi și propriul sistem de integrare. Toate acestea funcționează și reprezintă o parte importantă a afacerii.
Nu putem pur și simplu să spunem: „Să renunțăm la sistemele legacy și să creăm noi sisteme care vor putea utiliza Service Mesh”. Pentru a integra toate sistemele vechi cu cele noi (pe arhitectura microserviciilor), sistemele care pot folosi Service Mesh au nevoie de un anumit adaptor, intermediar, gateway. Admit că ar fi minunat dacă acesta ar veni într-un pachet împreună cu serviciul. Gateway-ul AS poate susține orice variantă de integrare. Imaginează-ți că instalezi pur și simplu Enterprise Service Mesh și este deja pregătit să interacționeze cu toate protocoalele de care ai nevoie. Acest abordare este foarte importantă pentru noi.
Cam așa vedem versiunea corporate a Service Mesh (Enterprise Service Mesh). Personalizarea descrisă rezolvă cele mai multe probleme care apar atunci când încercăm să folosim versiunile open-source gata făcute ale unei platforme de integrare. Apărută acum câțiva ani, arhitectura Service Mesh continuă să evolueze și suntem încântați că putem contribui la dezvoltarea acesteia. Sperăm că experiența noastră va fi utilă pentru voi.
Sursa: habr.com
