Service Mesh je dobro znan arhitekturni vzorec za integracijo mikrostoritev in prehod na infrastrukturo v oblaku. Danes je v svetu vsebnikov v oblaku precej težko brez tega. Na trgu je že na voljo več implementacij odprtokodnih storitvenih mrež, vendar njihova funkcionalnost, zanesljivost in varnost niso vedno zadostne, zlasti ko gre za zahteve velikih finančnih družb po vsej državi. Zato smo se pri Sbertechu odločili prilagoditi Service Mesh in se želimo pogovarjati o tem, kaj je pri Service Mesh kul, kaj ni tako kul in kaj bomo storili glede tega.
Priljubljenost vzorca Service Mesh narašča s priljubljenostjo tehnologij v oblaku. Gre za namensko infrastrukturno plast, ki poenostavlja interakcijo med različnimi omrežnimi storitvami. Sodobne aplikacije v oblaku so sestavljene iz več sto ali celo tisoč takih storitev, od katerih ima lahko vsaka na tisoče kopij.
Interakcija med temi storitvami in njihovo upravljanje je ključna naloga storitvenega omrežja. Pravzaprav je to omrežni model številnih posrednikov, ki se upravljajo centralno in opravljajo niz zelo uporabnih funkcij.
Na ravni posrednika (podatkovna ravnina):
- Dodeljevanje in distribucija politik usmerjanja in uravnoteženja prometa
- Distribucija ključev, certifikatov, žetonov
- Zbiranje telemetrije, generiranje spremljajočih metrik
- Integracija z varnostno in nadzorno infrastrukturo
Na ravni nadzorne ravnine:
- Uporaba politik usmerjanja in uravnoteženja prometa
- Upravljanje ponovnih poskusov in časovnih omejitev, odkrivanje "mrtvih" vozlišč (prekinitev tokokroga), upravljanje napak pri vstavljanju in zagotavljanje odpornosti storitve prek drugih mehanizmov
- Avtentikacija/avtorizacija klica
- Opuščanje meritev (opazljivost)
Razpon uporabnikov, ki jih zanima razvoj te tehnologije, je zelo širok - od majhnih startupov do velikih internetnih korporacij, na primer PayPal.
Zakaj je Service Mesh potreben v podjetniškem sektorju?
Uporaba storitvenega omrežja ima številne očitne prednosti. Prvič, preprosto je priročno za razvijalce: za pisanje kode pojavi se tehnološka platforma, ki bistveno poenostavi integracijo v oblačno infrastrukturo zaradi dejstva, da je transportni sloj popolnoma izoliran od aplikacijske logike.
poleg tega Service Mesh poenostavi odnos med dobavitelji in potrošniki. Ponudniki API-jev in potrošniki se danes veliko lažje dogovorijo o vmesnikih in pogodbah sami, brez vključevanja posebnega integracijskega posrednika in razsodnika – enterprise service bus. Ta pristop pomembno vpliva na dva kazalnika. Poveča se hitrost uvajanja nove funkcionalnosti na trg (time-to-market), hkrati pa se poveča strošek rešitve, saj je integracijo treba izvesti neodvisno. Uporaba storitvenega omrežja s strani razvojnih skupin za poslovne funkcionalnosti pomaga vzdrževati ravnotežje. Posledično se lahko ponudniki API-jev osredotočijo izključno na aplikacijsko komponento svoje storitve in jo preprosto objavijo v Service Mesh – API bo takoj na voljo vsem strankam, kakovost integracije pa bo pripravljena za proizvodnjo in ne bo zahtevala niti enega vrstica dodatne kode.
Naslednja prednost je ta razvijalec, ki uporablja Service Mesh, se osredotoča izključno na poslovno funkcionalnost — na izdelku in ne na tehnološki komponenti svoje storitve. Na primer, ni vam več treba razmišljati o tem, da lahko v primeru klica storitve prek omrežja nekje pride do izpada povezave. Poleg tega Service Mesh pomaga uravnotežiti promet med kopijami iste storitve: če ena od kopij »umre«, bo sistem ves promet preusmeril na preostale žive kopije.
Storitvena mreža - to je dobra osnova za ustvarjanje porazdeljenih aplikacij, ki pred naročnikom skriva podrobnosti zagotavljanja klicev v svoje storitve tako interno kot eksterno. Vse aplikacije, ki uporabljajo Service Mesh, so na transportni ravni izolirane od omrežja in druga od druge: med njimi ni komunikacije. V tem primeru razvijalec prejme popoln nadzor nad svojimi storitvami.
Opozoriti je treba, da Posodabljanje porazdeljenih aplikacij v storitvenem mrežnem okolju postane lažje. Na primer modro/zelena uvedba, v kateri sta za namestitev na voljo dve aplikacijski okolji, od katerih eno ni posodobljeno in je v stanju pripravljenosti. Vrnitev na prejšnjo različico v primeru neuspešne izdaje izvede poseben usmerjevalnik, katerega vlogo Service Mesh dobro obvlada. Če želite preizkusiti novo različico, lahko uporabite izpust kanarčkov — preklopite na novo različico samo 10% prometa ali zahtev pilotne skupine strank. Glavni promet gre na staro verzijo, nič se ne pokvari.
Tudi Service Mesh nam omogoča nadzor SLA v realnem času. Porazdeljeni proxy sistem ne bo dovolil, da storitev odpove, ko ena od strank preseže kvoto, ki ji je dodeljena. Če je prepustnost API omejena, je nihče ne bo mogel preobremeniti z velikim številom transakcij: Service Mesh stoji pred storitvijo in ne dovoljuje nepotrebnega prometa. Preprosto se bo boril nazaj v integracijski plasti, storitve same pa bodo še naprej delovale, ne da bi to opazile.
Če želi podjetje zmanjšati stroške za razvoj integracijskih rešitev, Service Mesh pomaga tudi: Iz komercialnih izdelkov lahko preklopite na njegovo odprtokodno različico. Naš Enterprise Service Mesh temelji na odprtokodni različici Service Mesh.
Še ena prednost - razpoložljivost enotnega polnega nabora integracijskih storitev. Ker je vsa integracija zgrajena prek te vmesne programske opreme, lahko upravljamo ves integracijski promet in povezave med aplikacijami, ki tvorijo poslovno jedro podjetja. Je zelo udobno.
In končno Service Mesh spodbuja podjetje k prehodu na dinamično infrastrukturo. Zdaj se mnogi ozirajo proti kontejnerizaciji. Rezanje monolita v mikrostoritve, vse to lepo implementirano - tema je v porastu. Toda ko poskušate sistem, ki je bil v proizvodnji že vrsto let, prenesti na novo platformo, takoj naletite na številne težave: vse skupaj stlačiti v zabojnike in namestiti na platformo ni enostavno. In implementacija, sinhronizacija in interakcija teh porazdeljenih komponent je še ena zelo zapletena tema. Kako bodo komunicirali med seboj? Bo prišlo do kaskadnih napak? Service Mesh vam omogoča, da rešite nekatere od teh težav in olajšate migracijo s stare arhitekture na novo zaradi dejstva, da lahko pozabite na logiko omrežne izmenjave.
Zakaj potrebujete prilagoditev Service Mesh?
V našem podjetju soobstaja na stotine sistemov in modulov, izvajalni čas pa je zelo obremenjen. Torej preprost vzorec enega sistema, ki pokliče drugega in prejme odgovor, ni dovolj, saj v proizvodnji želimo več. Kaj še potrebujete od storitvene mreže podjetij?
Storitev obdelave dogodkov
Predstavljajmo si, da moramo izdelati procesiranje dogodkov v realnem času – sistem, ki v realnem času analizira naročnikova dejanja in mu lahko takoj poda ustrezno ponudbo. Za izvedbo podobne funkcije uporabite arhitekturni vzorec, imenovan dogodki usmerjena arhitektura (EDA). Nobena od trenutnih storitvenih mrež izvorno ne podpira takšnih vzorcev, vendar je to zelo pomembno, zlasti za banko!
Precej čudno je, da Remote Procedure Call (RPC) podpirajo vse različice Service Mesh, niso pa prijazne do EDA. Ker je Service Mesh nekakšna sodobna porazdeljena integracija, EDA pa je zelo ustrezen arhitekturni vzorec, ki vam omogoča, da delate edinstvene stvari v smislu uporabniške izkušnje.
Naš Enterprise Service Mesh bi moral rešiti to težavo. Poleg tega želimo v njem videti implementacijo zajamčene dostave, pretakanja in kompleksne obdelave dogodkov z uporabo različnih filtrov in predlog.
Storitev prenosa datotek
Poleg EDA bi bilo lepo imeti možnost prenosa datotek: na ravni podjetja je zelo pogosto možna le integracija datotek. Zlasti se uporablja arhitekturni vzorec ETL (Extract, Transform, Load). V njem si praviloma vsi izmenjujejo izključno datoteke: uporabljajo se veliki podatki, ki jih je nepraktično potiskati ločene zahteve. Možnost izvorne podpore prenosov datotek v Enterprise Service Mesh vam daje prilagodljivost, ki jo potrebuje vaše podjetje.
Storitev orkestracije
Velike organizacije imajo skoraj vedno različne ekipe, ki izdelujejo različne izdelke. Na primer, v banki nekatere ekipe delajo z depoziti, druge pa s posojilnimi produkti in takih primerov je kar veliko. To so različni ljudje, različne ekipe, ki izdelujejo svoje izdelke, razvijajo svoje API-je in jih ponujajo drugim. In zelo pogosto je treba sestaviti te storitve, pa tudi implementirati kompleksno logiko za zaporedno klicanje niza API-jev. Za rešitev te težave potrebujete rešitev v integracijski plasti, ki bo poenostavila vso to sestavljeno logiko (klicanje več API-jev, opisovanje poti zahteve itd.). To je storitev orkestracije v Enterprise Service Mesh.
AI in ML
Ko mikrostoritve komunicirajo prek ene same integracijske plasti, Service Mesh seveda ve vse o klicih vsake storitve. Zbiramo telemetrijo: kdo je koga klical, kdaj, koliko časa, kolikokrat itd. Ko je teh storitev na stotine tisoč in klicev na milijarde, se vse to kopiči in tvori velike podatke. Te podatke je mogoče analizirati z uporabo umetne inteligence, strojnega učenja itd., nato pa je mogoče na podlagi rezultatov analize narediti nekaj koristnih stvari. Nadzor nad vsem tem omrežnim prometom in klici aplikacij, integriranimi v Service Mesh, bi bilo primerno vsaj delno predati umetni inteligenci.
Storitev prehoda API
Običajno ima Service Mesh posrednike in storitve, ki komunicirajo med seboj znotraj zaupanja vrednega območja. Obstajajo pa tudi zunanje nasprotne stranke. Zahteve za API-je, ki so izpostavljeni tej skupini potrošnikov, so veliko strožje. To nalogo razdelimo na dva glavna dela.
- varnost. Težave, povezane z ddos, ranljivostjo protokolov, aplikacij, operacijskih sistemov itd.
- Lestvica. Ko število API-jev, ki jih je treba ponuditi odjemalcem, naraste na tisoče ali celo na stotine tisoč, obstaja potreba po nekem orodju za upravljanje za ta niz API-jev. Nenehno morate spremljati API: ali delujejo ali ne, kakšen je njihov status, kakšen promet teče, kakšne statistike itd. Prehod API bi moral opraviti to nalogo, hkrati pa narediti celoten proces obvladljiv in varen. Zahvaljujoč tej komponenti se Enterprise Service Mesh nauči enostavno objavljati notranje in zunanje API-je.
Storitev podpore za posebne protokole in formate podatkov (prehod AS)
Trenutno lahko večina rešitev Service Mesh izvorno deluje samo s prometom HTTP in HTTP2 ali v zmanjšanem načinu na ravni TCP/IP. Enterprise Service Mesh se pojavlja s številnimi drugimi zelo specifičnimi protokoli za prenos podatkov. Nekateri sistemi lahko uporabljajo posrednike sporočil, drugi so integrirani na ravni baze podatkov. Če ima podjetje SAP, potem lahko uporablja tudi svoj integracijski sistem. Poleg tega vse to deluje in je pomemben del posla.
Ne morete kar reči: "Opustimo zapuščino in naredimo nove sisteme, ki lahko uporabljajo Service Mesh." Za povezavo vseh starih sistemov z novimi (na mikrostoritveni arhitekturi) bodo sistemi, ki lahko uporabljajo Service Mesh, potrebovali nekakšen adapter, posrednika, prehod. Strinjam se, lepo bi bilo, če bi prišel v škatli skupaj s storitvijo. AC prehod lahko podpira katero koli možnost integracije. Predstavljajte si, samo namestite Enterprise Service Mesh in pripravljen je za interakcijo z vsemi protokoli, ki jih potrebujete. Ta pristop je za nas zelo pomemben.
Približno tako si predstavljamo korporativno različico storitvenega omrežja (Enterprise Service Mesh). Opisana prilagoditev rešuje večino težav, ki nastanejo pri poskusu uporabe že pripravljenih odprtokodnih različic integracijske platforme. Arhitektura Service Mesh, ki je bila predstavljena le pred nekaj leti, se še naprej razvija in veseli smo, da lahko prispevamo k njenemu razvoju. Upamo, da vam bodo naše izkušnje koristile.
Vir: www.habr.com