Service Mesh je dobro poznati arhitektonski obrazac za integraciju mikroservisa i migraciju na infrastrukturu oblaka. Danas je u svijetu cloud-kontejnera prilično teško bez njega. Nekoliko open-source servisnih mreža već je dostupno na tržištu, ali njihova funkcionalnost, pouzdanost i sigurnost nisu uvijek dovoljni, posebno kada su u pitanju zahtjevi velikih finansijskih kompanija širom zemlje. Zato smo mi u Sbertech-u odlučili da prilagodimo Service Mesh i želimo da razgovaramo o tome šta je cool u vezi Service Mesh-a, šta nije tako dobro i šta ćemo učiniti po tom pitanju.
Popularnost obrasca servisne mreže raste sa popularnošću cloud tehnologija. To je namjenski infrastrukturni sloj koji pojednostavljuje interakciju između različitih mrežnih usluga. Moderne aplikacije u oblaku sastoje se od stotina ili čak hiljada takvih usluga, od kojih svaka može imati hiljade kopija.
Interakcija između ovih usluga i upravljanje njima je ključni zadatak Service Mesh-a. Zapravo, ovo je mrežni model mnogih proxy servera, kojima se upravlja centralno i koji obavljaju skup vrlo korisnih funkcija.
Na proxy nivou (ravan podataka):
- Dodjela i distribucija politika rutiranja i balansiranja prometa
- Distribucija ključeva, certifikata, tokena
- Prikupljanje telemetrije, generisanje metrike praćenja
- Integracija sa sigurnosnom i nadzornom infrastrukturom
Na nivou kontrolne ravni:
- Primjena politika usmjeravanja i balansiranja prometa
- Upravljanje ponovnim pokušajima i istekom vremena, otkrivanje "mrtvih" čvorova (prekid strujnog kola), upravljanje ubacivanjem kvarova i osiguravanje otpornosti usluge putem drugih mehanizama
- Provjera autentičnosti/autorizacija poziva
- Ispuštanje metrike (uočljivost)
Raspon korisnika zainteresiranih za razvoj ove tehnologije je vrlo širok - od malih startupa do velikih internet korporacija, na primjer PayPal.
Zašto je Service Mesh potreban u korporativnom sektoru?
Postoje mnoge jasne prednosti korištenja servisne mreže. Prije svega, jednostavno je zgodno za programere: za pisanje koda pojavljuje se tehnološka platforma, što značajno pojednostavljuje integraciju u infrastrukturu oblaka zbog činjenice da je transportni sloj potpuno izolovan od logike aplikacije.
Osim toga, Service Mesh pojednostavljuje odnos između dobavljača i potrošača. Danas je API provajderima i potrošačima mnogo lakše da se sami dogovore oko interfejsa i ugovora, bez uključivanja posebnog posrednika za integraciju i arbitra - sabirnicu usluga preduzeća. Ovaj pristup značajno utiče na dva indikatora. Brzina iznošenja nove funkcionalnosti na tržište (time-to-market) se povećava, ali u isto vrijeme raste i cijena rješenja, budući da se integracija mora obaviti nezavisno. Korištenje Service Mesh od strane timova za razvoj poslovne funkcionalnosti pomaže u održavanju ravnoteže. Kao rezultat toga, API provajderi mogu se fokusirati isključivo na komponentu aplikacije svoje usluge i jednostavno je objaviti u Service Mesh - API će odmah postati dostupan svim klijentima, a kvalitet integracije će biti spreman za proizvodnju i neće zahtijevati niti jednu red dodatnog koda.
Sljedeća prednost je to programer se, koristeći Service Mesh, fokusira isključivo na poslovnu funkcionalnost — na proizvod, a ne na tehnološku komponentu njegove usluge. Na primjer, više ne morate razmišljati o tome da u situaciji kada se usluga poziva preko mreže, negdje može doći do kvara veze. Osim toga, Service Mesh pomaže u balansiranju prometa između kopija iste usluge: ako jedna od kopija "umre", sistem će prebaciti sav promet na preostale žive kopije.
Service Mesh - ovo je dobra osnova za kreiranje distribuiranih aplikacija, koji od klijenta skriva detalje o pružanju poziva svojim uslugama kako interno tako i eksterno. Sve aplikacije koje koriste Service Mesh su izolovane na nivou transporta i od mreže i jedna od druge: nema komunikacije između njih. U ovom slučaju, programer dobija potpunu kontrolu nad svojim uslugama.
Treba napomenuti da Ažuriranje distribuiranih aplikacija u okruženju servisne mreže postaje lakše. Na primjer, plava/zelena implementacija, u kojoj su dva okruženja aplikacija dostupna za instalaciju, od kojih jedno nije ažurirano i nalazi se u stanju pripravnosti. Vraćanje na prethodnu verziju u slučaju neuspješnog puštanja vrši se posebnim usmjerivačem, s čijom se ulogom Service Mesh dobro nosi. Za testiranje nove verzije možete koristiti kanarinac — prebacite na novu verziju samo 10% prometa ili zahtjeva pilot grupe klijenata. Glavni promet ide na staru verziju, ništa se ne kvari.
Takođe Service Mesh nam daje SLA kontrolu u realnom vremenu. Distribuirani proxy sistem neće dozvoliti da usluga ne uspije kada jedan od klijenata premaši kvotu koja mu je dodijeljena. Ako je propusnost API-ja ograničena, niko ga neće moći zatrpati velikim brojem transakcija: Service Mesh stoji ispred servisa i ne dozvoljava nepotreban promet. Jednostavno će uzvratiti u integracijskom sloju, a same usluge će nastaviti da rade a da to ne primećuju.
Ako kompanija želi smanjiti troškove za razvoj integracijskih rješenja, Service Mesh također pomaže: Možete se prebaciti na njegovu verziju otvorenog koda sa komercijalnih proizvoda. Naš Enterprise Service Mesh baziran je na verziji Service Mesh otvorenog koda.
Još jedna prednost - dostupnost jednog punopravnog skupa integracijskih usluga. Budući da je sva integracija izgrađena preko ovog međuvera, možemo upravljati svim integracijskim prometom i vezama između aplikacija koje čine poslovnu jezgru kompanije. Veoma je udoban.
I na kraju Service Mesh podstiče kompaniju da pređe na dinamičku infrastrukturu. Sada mnogi gledaju ka kontejnerizaciji. Rezanje monolita na mikroservise, lijepa implementacija svega ovoga - tema je u usponu. Ali kada pokušate da prebacite sistem koji je bio u proizvodnji dugi niz godina na novu platformu, odmah nailazite na niz problema: gurnuti sve u kontejnere i implementirati na platformu nije lako. A implementacija, sinhronizacija i interakcija ovih distribuiranih komponenti je još jedna vrlo složena tema. Kako će međusobno komunicirati? Hoće li biti kaskadnih kvarova? Service Mesh vam omogućava da riješite neke od ovih problema i olakšate migraciju sa stare arhitekture na novu zbog činjenice da možete zaboraviti na logiku mrežne razmjene.
Zašto vam je potrebna prilagodba servisne mreže?
U našoj kompaniji koegzistiraju stotine sistema i modula, a vrijeme rada je jako opterećeno. Dakle, jednostavan obrazac da jedan sistem zove drugi i dobije odgovor nije dovoljan, jer u proizvodnji želimo više. Šta vam još treba od mreže za usluge preduzeća?
Usluga obrade događaja
Zamislimo da trebamo napraviti obradu događaja u realnom vremenu – sistem koji analizira klijentove akcije u realnom vremenu i može mu odmah dati relevantnu ponudu. Za implementaciju slične funkcionalnosti koristite arhitektonski obrazac nazvan arhitektura vođena događajima (EDA). Nijedna od trenutnih servisnih mreža ne podržava takve obrasce, ali ovo je veoma važno, posebno za banku!
Prilično je čudno da Remote Procedure Call (RPC) podržavaju sve verzije Service Mesh-a, ali one nisu prijateljske s EDA-om. Jer Service Mesh je vrsta moderne distribuirane integracije, a EDA je vrlo relevantan arhitektonski obrazac koji vam omogućava da radite jedinstvene stvari u smislu korisničkog iskustva.
Naš Enterprise Service Mesh bi trebao riješiti ovaj problem. Osim toga, želimo u njemu vidjeti implementaciju zagarantovane isporuke, striminga i složene obrade događaja korištenjem raznih filtera i šablona.
Usluga prijenosa fajlova
Pored EDA-e, bilo bi lijepo imati mogućnost prijenosa datoteka: na razini poduzeća, vrlo često je moguća samo integracija datoteka. Konkretno, koristi se ETL (Extract, Transform, Load) arhitektonski obrazac. U njemu, po pravilu, svi isključivo razmjenjuju datoteke: koriste se veliki podaci, što je nepraktično ubacivati u zasebne zahtjeve. Mogućnost izvorne podrške za prijenos datoteka u Enterprise Service Mesh daje vam fleksibilnost koja je potrebna vašem poslovanju.
Usluga orkestracije
Velike organizacije gotovo uvijek imaju različite timove koji prave različite proizvode. Na primjer, u banci neki timovi rade s depozitima, dok drugi rade s kreditnim proizvodima, a takvih slučajeva ima dosta. To su različiti ljudi, različiti timovi koji prave svoje proizvode, razvijaju svoje API-je i pružaju ih drugima. I vrlo često postoji potreba za sastavljanjem ovih servisa, kao i implementacijom složene logike za sekvencijalno pozivanje skupa API-ja. Da biste riješili ovaj problem, potrebno vam je rješenje u integracijskom sloju koje će pojednostaviti svu ovu složenu logiku (pozivanje nekoliko API-ja, opisivanje rute zahtjeva, itd.). Ovo je usluga orkestracije u mreži Enterprise Service Mesh.
AI i ML
Kada mikroservise komuniciraju kroz jedan integracioni sloj, Service Mesh prirodno zna sve o pozivima svake usluge. Prikupljamo telemetriju: ko je koga zvao, kada, koliko dugo, koliko puta i tako dalje. Kada postoje stotine hiljada ovih usluga, i milijarde poziva, onda se sve to akumulira i formira Big Data. Ovi podaci se mogu analizirati korištenjem AI, mašinskog učenja itd., a zatim se mogu učiniti neke korisne stvari na osnovu rezultata analize. Bilo bi prikladno da se kontrola nad svim ovim mrežnim prometom i pozivima aplikacija integriranim u Service Mesh barem djelimično preda umjetnoj inteligenciji.
API Gateway Service
Tipično, Service Mesh ima proxy servere i usluge koje međusobno razgovaraju unutar pouzdanog perimetra. Ali postoje i spoljne strane. Zahtjevi za API-je koji su izloženi ovoj grupi potrošača su mnogo stroži. Ovaj zadatak dijelimo na dva glavna dijela.
- Sigurnost. Problemi vezani za ddos, ranjivost protokola, aplikacija, operativnih sistema i tako dalje.
- Vage. Kada broj API-ja koji treba da se opslužuju klijentima pređe na hiljade ili čak stotine hiljada, postoji potreba za nekom vrstom alata za upravljanje ovim skupom API-ja. Morate stalno pratiti API: da li rade ili ne, kakav je njihov status, kakav promet teče, koja statistika itd. API pristupnik trebao bi se nositi s ovim zadatkom dok cijeli proces čini upravljivim i sigurnim. Zahvaljujući ovoj komponenti, Enterprise Service Mesh uči da lako objavi interne i eksterne API-je.
Usluga podrške za određene protokole i formate podataka (AS gateway)
Trenutno, većina Service Mesh rešenja može da radi nativno samo sa HTTP i HTTP2 saobraćajem ili u smanjenom režimu na TCP/IP nivou. Enterprise Service Mesh se pojavljuje s mnogim drugim vrlo specifičnim protokolima za prijenos podataka. Neki sistemi mogu koristiti posrednike poruka, drugi su integrisani na nivou baze podataka. Ako kompanija ima SAP, onda može koristiti i vlastiti sistem integracije. Štaviše, sve ovo funkcionira i važan je dio poslovanja.
Ne možete samo reći: "Hajde da napustimo naslijeđe i napravimo nove sisteme koji mogu koristiti Service Mesh." Za povezivanje svih starih sistema sa novim (na mikroservisnoj arhitekturi), sistemima koji mogu koristiti Service Mesh će biti potrebna neka vrsta adaptera, posrednika, gateway-a. Slažem se, bilo bi lijepo da dođe u kutiji zajedno sa servisom. AC gateway može podržati bilo koju opciju integracije. Samo zamislite, samo instalirate Enterprise Service Mesh i on je spreman za interakciju sa svim protokolima koji su vam potrebni. Ovaj pristup nam je veoma važan.
Ovako otprilike zamišljamo korporativnu verziju Service Mesh (Enterprise Service Mesh). Opisano prilagođavanje rješava većinu problema koji se javljaju prilikom pokušaja korištenja gotovih open-source verzija integracijske platforme. Uvedena prije samo nekoliko godina, Service Mesh arhitektura nastavlja da se razvija i mi smo uzbuđeni što možemo doprinijeti njenom razvoju. Nadamo se da će vam naše iskustvo biti od koristi.
izvor: www.habr.com