Service Mesh je dobro poznati arhitektonski obrazac za integraciju mikroservisa i migraciju na infrastrukturu oblaka. Danas je u svijetu spremnika u oblaku prilično teško bez njega. Na tržištu je već dostupno nekoliko open-source service mesh implementacija, ali njihova funkcionalnost, pouzdanost i sigurnost nisu uvijek dovoljne, posebice kada su u pitanju zahtjevi velikih financijskih kompanija diljem zemlje. Zato smo mi u Sbertechu odlučili prilagoditi Service Mesh i želimo razgovarati o tome što je cool kod Service Mesh-a, što nije tako cool i što ćemo učiniti u vezi s tim.
Popularnost Service Mesh uzorka raste s popularnošću cloud tehnologija. To je namjenski sloj infrastrukture koji pojednostavljuje interakciju između različitih mrežnih usluga. Moderne aplikacije u oblaku sastoje se od stotina ili čak tisuća takvih usluga, od kojih svaka može imati tisuće kopija.
Interakcija između ovih usluga i upravljanje njima ključna je zadaća Service Mesha. Zapravo, ovo je mrežni model mnogih proxyja, kojima se upravlja centralno i koji obavlja niz vrlo korisnih funkcija.
Na proxy razini (podatkovna razina):
- Dodjeljivanje i distribucija politika usmjeravanja i balansiranja prometa
- Podjela ključeva, certifikata, tokena
- Prikupljanje telemetrije, generiranje metrike praćenja
- Integracija sa sigurnosnom i nadzornom infrastrukturom
Na razini kontrolne ravnine:
- Primjena pravila usmjeravanja i balansiranja prometa
- Upravljanje ponovnim pokušajima i vremenskim ograničenjima, otkrivanje "mrtvih" čvorova (prekid strujnog kruga), upravljanje greškama ubrizgavanja i osiguravanje otpornosti usluge putem drugih mehanizama
- Autentifikacija/autorizacija poziva
- Ispuštanje metrike (vidljivost)
Raspon korisnika zainteresiranih za razvoj ove tehnologije vrlo je širok - od malih startupa do velikih internetskih korporacija, na primjer, PayPal.
Zašto je Service Mesh potreban u korporativnom sektoru?
Mnogo je jasnih prednosti korištenja servisne mreže. Prije svega, jednostavno je pogodan za programere: za pisanje koda pojavljuje se tehnološka platforma, što značajno pojednostavljuje integraciju u cloud infrastrukturu zbog činjenice da je transportni sloj potpuno izoliran od aplikacijske logike.
Osim toga, Service Mesh pojednostavljuje odnos između dobavljača i potrošača. Danas je pružateljima API-ja i potrošačima puno lakše sami dogovoriti sučelja i ugovore, bez uključivanja posebnog integracijskog posrednika i arbitra – enterprise service busa. Ovaj pristup značajno utječe na dva pokazatelja. Povećava se brzina iznošenja nove funkcionalnosti na tržište (time-to-market), ali se istovremeno povećava i cijena rješenja, budući da se integracija mora obaviti samostalno. Korištenje Service Mesh-a od strane timova za razvoj poslovnih funkcionalnosti pomaže u održavanju ravnoteže ovdje. Kao rezultat toga, pružatelji API-ja mogu se usredotočiti isključivo na aplikacijsku komponentu svoje usluge i jednostavno je objaviti u Service Mesh - API će odmah postati dostupan svim klijentima, a kvaliteta integracije bit će spremna za proizvodnju i neće zahtijevati ni jedan linija dodatnog koda.
Sljedeća prednost je ta programer se, koristeći Service Mesh, fokusira isključivo na poslovnu funkcionalnost — na proizvod, a ne na tehnološku komponentu svoje usluge. Na primjer, više ne morate razmišljati o tome da u situaciji kada se neka usluga pozove preko mreže, negdje može doći do kvara na vezi. Osim toga, Service Mesh pomaže u ravnoteži prometa između kopija iste usluge: ako jedna od kopija "umre", sustav će sav promet prebaciti na preostale žive kopije.
Servisna mreža - ovo je dobra osnova za stvaranje distribuiranih aplikacija, koji skriva od klijenta detalje pružanja poziva svojim uslugama kako interno tako i eksterno. Sve aplikacije koje koriste Service Mesh izolirane su na transportnoj razini i od mreže i jedna od druge: nema komunikacije između njih. U tom slučaju programer dobiva potpunu kontrolu nad svojim uslugama.
Treba napomenuti da Ažuriranje distribuiranih aplikacija u mrežnom okruženju usluge postaje lakše. Na primjer, plavo/zelena implementacija, u kojoj su dva aplikacijska okruženja 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 izdanja provodi poseban usmjerivač, s čijom ulogom se Service Mesh dobro nosi. Za testiranje nove verzije možete koristiti puštanje kanarinca — prebacite na novu verziju samo 10% prometa ili zahtjeva od pilot grupe klijenata. Glavni promet ide na staru verziju, ništa se ne kvari.
Također Service Mesh daje nam SLA kontrolu u stvarnom vremenu. Distribuirani proxy sustav neće dopustiti da usluga zakaže kada jedan od klijenata premaši kvotu koja mu je dodijeljena. Ako je propusnost API-ja ograničena, nitko je neće moći zatrpati velikim brojem transakcija: Service Mesh stoji ispred usluge i ne dopušta nepotreban promet. Jednostavno će uzvratiti udarac u integracijskom sloju, a same će usluge nastaviti raditi, a da to ne primijetite.
Ako tvrtka želi smanjiti troškove za razvoj integracijskih rješenja, Service Mesh također pomaže: Možete se prebaciti na njegovu verziju otvorenog koda s komercijalnih proizvoda. Naš Enterprise Service Mesh temelji se na open-source verziji Service Mesh-a.
Još jedna prednost - dostupnost jednog potpunog skupa integracijskih usluga. Budući da je sva integracija izgrađena putem ovog međuslojnog softvera, možemo upravljati svim integracijskim prometom i vezama između aplikacija koje čine poslovnu jezgru tvrtke. Vrlo je udoban.
I konačno Service Mesh potiče tvrtku da prijeđe na dinamičnu infrastrukturu. Sada mnogi gledaju prema kontejnerizaciji. Rezanje monolita na mikroservise, sve to lijepo implementirano - tema je u porastu. Ali kada pokušate prebaciti sustav koji je bio u proizvodnji dugi niz godina na novu platformu, odmah se susrećete s brojnim problemima: sve to gurnuti u spremnike i implementirati na platformu nije lako. A implementacija, sinkronizacija i interakcija ovih distribuiranih komponenti još je jedna vrlo složena tema. Kako će međusobno komunicirati? Hoće li biti kaskadnih kvarova? Service Mesh vam omogućuje 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 Service Mesh-a?
U našoj tvrtki koegzistiraju stotine sustava i modula, a vrijeme izvođenja je vrlo opterećeno. Dakle, jednostavan uzorak jednog sustava koji poziva drugi i prima odgovor nije dovoljan, jer u proizvodnji želimo više. Što vam još treba od mesha poslovnih usluga?
Usluga obrade događaja
Zamislimo da trebamo napraviti real-time event processing – sustav koji u realnom vremenu analizira radnje klijenta i može mu odmah dati relevantnu ponudu. Da biste implementirali sličnu funkcionalnost, upotrijebite arhitektonski obrazac koji se naziva arhitektura vođena događajima (EDA). Niti jedan od trenutnih servisnih mreža izvorno ne podržava takve obrasce, ali ovo je vrlo 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. Budući da je Service Mesh vrsta moderne distribuirane integracije, a EDA je vrlo relevantan arhitektonski obrazac koji vam omogućuje da radite jedinstvene stvari u smislu korisničkog iskustva.
Naš Enterprise Service Mesh trebao bi riješiti ovaj problem. Osim toga, u njemu želimo vidjeti implementaciju zajamčene isporuke, streaminga i složene obrade događaja pomoću raznih filtara i predložaka.
Usluga prijenosa datoteka
Uz EDA, bilo bi lijepo imati mogućnost prijenosa datoteka: na razini poduzeća vrlo često je moguća samo integracija datoteka. Posebno se koristi ETL (Extract, Transform, Load) arhitektonski obrazac. U njemu u pravilu svi razmjenjuju isključivo datoteke: koriste se veliki podaci, što je nepraktično gurati zasebne zahtjeve. Sposobnost 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 proizvode različite proizvode. Primjerice, u banci neki timovi rade s depozitima, a drugi s kreditnim proizvodima, a takvih je slučajeva dosta. To su različiti ljudi, različiti timovi koji prave svoje proizvode, razvijaju svoje API-je i daju ih drugima. I vrlo često postoji potreba za sastavljanjem ovih usluga, 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 kompozitnu logiku (pozivanje nekoliko API-ja, opisivanje rute zahtjeva itd.). Ovo je usluga orkestracije u mreži Enterprise Service Mesh.
AI i ML
Kada mikroservisi komuniciraju kroz jedan integracijski sloj, Service Mesh prirodno zna sve o pozivima svake usluge. Prikupljamo telemetriju: tko je koga zvao, kada, koliko dugo, koliko puta i tako dalje. Kada su stotine tisuća tih usluga, a milijarde poziva, onda se sve to akumulira i formira Big Data. Ti se podaci mogu analizirati pomoću AI-ja, strojnog učenja itd., a onda se na temelju rezultata analize mogu napraviti neke korisne stvari. Bilo bi primjereno barem djelomično prepustiti kontrolu nad svim ovim mrežnim prometom i pozivima aplikacija integriranih u Service Mesh umjetnoj inteligenciji.
API Gateway usluga
Tipično, Service Mesh ima proxyje i servise koji komuniciraju jedni s drugima unutar pouzdanog perimetra. Ali postoje i vanjske ugovorne strane. Zahtjevi za API-je koji su izloženi ovoj skupini potrošača mnogo su stroži. Ovaj zadatak dijelimo na dva glavna dijela.
- sigurnosti. Problemi vezani uz ddos, ranjivost protokola, aplikacija, operativnih sustava i tako dalje.
- Skala. Kada se broj API-ja koji se trebaju poslužiti klijentima kreće u tisućama ili čak stotinama tisuća, postoji potreba za nekom vrstom alata za upravljanje ovim skupom API-ja. Morate stalno pratiti API: rade li ili ne, kakav im je status, kakav promet teče, kakva je statistika itd. API pristupnik trebao bi se nositi s ovim zadatkom, a cijeli proces učiniti upravljivim i sigurnim. Zahvaljujući ovoj komponenti, Enterprise Service Mesh uči lako objavljivati unutarnje i vanjske API-je.
Usluga podrške za specifične protokole i formate podataka (AS gateway)
Trenutačno većina Service Mesh rješenja može raditi nativno samo s HTTP i HTTP2 prometom ili u smanjenom načinu rada na TCP/IP razini. Enterprise Service Mesh pojavljuje se s mnogim drugim vrlo specifičnim protokolima za prijenos podataka. Neki sustavi mogu koristiti brokere poruka, drugi su integrirani na razini baze podataka. Ako tvrtka ima SAP, tada može koristiti i vlastiti integracijski sustav. Štoviše, sve to funkcionira i važan je dio poslovanja.
Ne možete samo reći: "Napustimo nasljeđe i napravimo nove sustave koji mogu koristiti Service Mesh." Za povezivanje svih starih sustava s novima (na mikroservisnoj arhitekturi), sustavi koji mogu koristiti Service Mesh trebat će neku vrstu adaptera, posrednika, pristupnika. Slažem se, bilo bi lijepo da dođe u kutiji zajedno s uslugom. AC pristupnik može podržati bilo koju opciju integracije. Zamislite samo, samo instalirate Enterprise Service Mesh i on je spreman za interakciju sa svim protokolima koji su vam potrebni. Ovaj pristup nam je vrlo važan.
Otprilike ovako zamišljamo korporativnu verziju Service Mesha (Enterprise Service Mesh). Opisana prilagodba rješava većinu problema koji se javljaju pri pokušaju korištenja gotovih open-source inačica integracijske platforme. Predstavljena prije samo nekoliko godina, Service Mesh arhitektura nastavlja se razvijati, a mi smo uzbuđeni što možemo doprinijeti njezinom razvoju. Nadamo se da će vam naše iskustvo biti od koristi.
Izvor: www.habr.com