Miks me loome Enterprise Service Meshi

Service Mesh on tuntud arhitektuurimuster mikroteenuste integreerimiseks ja üleminekuks pilveinfrastruktuurile. Tänapäeval on pilve-konteinerite maailmas sellest üsna keeruline loobuda. Turul on juba saadaval mitu open-source'i service mesh'i teostust, kuid nende funktsionaalsus, usaldusväärsus ja ohutus ei ole kaugeltki alati piisavad, eriti kui rääkida suurte riikliku mastaabiga finantsasutuste nõuetest. Seetõttu otsustasime me Sbertehes Service Mesh'i kohandada ja soovime rääkida sellest, mis on Service Mesh'is äge, mis mitte nii väga ja mida me sellega ette kavatseme võtta.

Service Mesh'i mustri populaarsus kasvab koos pilvetehnoloogiate populaarsusega. See on eraldi infrastruktuuri kiht, mis lihtsustab erinevate võrguteenuste vahelist suhtlust. Kaasaegsed pilve rakendused koosnevad sadadest, isegi tuhandetest sellistest teenustest, millest igaühel võib olla tuhandeid koopiaid.

Nende teenuste vahel suhtlemine ja nende haldamine on Service Mesh'i peamine ülesanne. Tegelikult on see võrgumudel, mis koosneb paljusid pöördeid sisaldavatest proksidest, mida hallatakse tsentraliseeritult ja mis täidab mitmeid väga kasulikke funktsioone.

Proksi tasemel (andmeplaan):

• Marsruutimis- ja liikluse tasakaalupoliitikate määramine ja levitamine
• Võtmete, sertifikaatide ja tokenite levitamine
• Telemeetria kogumine, jälgimise metrikate loomine
• Integreerimine turbe- ja jälgimis-infrastruktuuriga

Kontrollplaani tasemel:

• Marsruutimis- ja liikluse tasakaalupoliitikate rakendamine
• Korduste ja timeout'ide haldamine, 'surnud' sõlmede määramine (circuit breaking), rike-situatsioonide haldamine (injecting faults) ja teenuste vastupidavuse tagamine läbi teiste mehhanismide
• Kutsumiste autentimine/autoriseerimine
• Metrika tagasilükkamine (observability)

Kasutajate ring, keda see tehnoloogia arendamine huvitab, on väga lai — alates väikestest idufirmadest kuni suurte internetikorporatsioonideni, nagu PayPal.

Milleks on ettevõtlussektoris vajalik Service Mesh

Service Mesh'i kasutamine toob kaasa palju ilmseid eeliseid. Esiteks on see lihtsalt mugav arendajatele: koodi kirjutamiseks ilmub tehnoloogiline platvorm, mis see oluliselt lihtsustab integreerimist pilveinfrastruktuuri, kuna transportkiht on täielikult isoleeritud rakendusloogikast.

Lisaks, Service Mesh lihtsustab teenusepakkujate ja -kasutajate suhteid. Tänapäeval on API teenusepakkujate ja -kasutajate jaoks palju lihtsam omavahel kokkuleppeid sõlmida liideste ja lepingute osas ilma spetsiaalse integratsioonipooliku või vahemeheta — ettevõtte teenusebussita. Selline lähenemine mõjutab kahte näitajat. Uue funktsionaalsuse turule toomise kiirus (time-to-market) suureneb, kuid samas tõuseb lahenduse maksumus, kuna integreerimine tuleb teha iseseisvalt. Service Mesh'i kasutamine ettevõtte funktsionaalsuse arendusmeeskondade vahel aitab säilitada siin tasakaalu. Lõpptulemusena saavad API teenusepakkujad keskenduda täielikult oma teenuse rakenduskomponendile ja lihtsalt avaldada selle Service Mesh'is — API on kohe kõigile klientidele kergesti kättesaadav ning integreerimise kvaliteet on tootmisvalmis ega nõua lisakoodi.

Järgmine eelis on see, et arendaja, kasutades Service Mesh'i, keskendub täielikult ärifunktsionaalsusele — toote, mitte tehnilise aspekti peale oma teenuses. Näiteks ei pea enam muretsema selle pärast, et juhul, kui teenust kutsutakse üle võrgu, võib kusagil ühendus katkeda. Lisaks aitab Service Mesh tasakaalustada liiklust ühe ja sama teenuse koopiate vahel: kui üks koopiatest on ‘surnud’, suunab süsteem kogu liikluse jäädvustatud koopiate peale.

Service Mesh — on hea alus hajutatud rakenduste loomiseks, mis varjab kliendi eest tema teenuste kutsumise tagamaid nii seest kui väljast. Kõik rakendused, mis kasutavad Service Mesh'i, on transporttasemel isoleeritud nii võrgust kui teineteisest: nende vahel pole mingit ühendust. Sellegipoolest saavad arendajad oma teenuste üle täieliku kontrolli.

Tasub mainida, et hajutatud rakenduste uuendamine keskkonnas, kus kasutatakse Service Mesh'i, muutub lihtsamaks. Näiteks on sinine/rohelise juurutamine, kus rakenduse paigaldamiseks on saadaval kaks keskkonda, millest üks ei uuendata ja on ooterežiimil. Ebaõnnestumise korral on võimalik tagasi rullida eelmine versioon spetsiaalse ruuteri abil, millega tegeleb suurepäraselt Service Mesh.. Uue versiooni katsetamiseks saab kasutada kanariversiooni — suunata uuele versioonile ainult 10% liiklusest või päringutest pilootklientide grupilt. Peamine liiklus läheb vana versiooni juurde ning midagi ei riku.

Samuti Service Mesh annab meile reaalajas SLA kontrolli.Jaotatud proksisüsteem ei luba teenust üle koormata, kui mõni klient ületab talle määratud kvooti. Kui API kaudu on läbilaskevõime piiratud, ei saa keegi teenust DDoS-rünnaku kaudu üle koormata: Service Mesh seisab teenuse ees ja ei lase liigset liiklust läbi. See tõrjub lihtsalt integreerimistasandil ja teenused jätkavad töötamist, märkamatta sellest.

Kui ettevõte soovib vähendada kulusid integreerimislahenduste arendamisel, aitab ka Service Mesh: avatud lähtekoodiga versioonile saab üle minna kommertsproduktidelt.Meie Enterprise Service Mesh põhineb avatud lähtekoodiga versioonil Service Mesh.

Veel üks eelis on täieliku integreerimisteenuste komplekti olemasolu.Kuna kogu integreerimine toimub läbi selle vahekihti, saame hallata kogu integreerimist liiklust ja rakenduste vahelisi seoseid, mis kujundavad ettevõtte äri tuuma. See on väga mugav.

Ja lõpuks Service Mesh stimuleerib ettevõtet üleminekule dünaamilisele infrastruktuurile. Praegu vaatavad paljud konteineriseerimise suunas. Monoloodi jagamine mikroteenusteks ja nende ilus rakendamine on kasvav suund. Kuid kui püüate viia paljusid aastaid tootmises olnud süsteeme uutele rööbastele, siis seisate kohe silmitsi paljude probleemidega: kõik see suruda konteineritesse ja juurutada platvormile pole lihtne. Ja nende jaotatud komponentide rakendamine, sünkroniseerimine ja koostöö — see on veel üks äärmiselt keeruline teema. Kuidas nad omavahel suhtlevad? Kas cascading ebaõnnestumisi ei toimu? Service Mesh aitab lahendada osa neid probleeme ja lihtsustab üleminekut vanalt arhitektuurilt uuele, sest võite unustada võrguvahetuse loogika.

Miks on vajalik Service Mesh'i kohandamine

Meie ettevõttes kooseksisteerib sadu süsteeme ja mooduleid ning runtime on väga koormatud. Seetõttu ei piisa lihtsast mustrist, kus üks süsteem kutsub üles teist ja saab vastuse, sest tootmises soovime rohkem. Mida veel vajame ettevõtte Service Mesh'ilt?

Sündmuste töötlemise teenus

Kujutage ette, et meil on vaja luua reaalajas sündmuste töötlemise süsteem — süsteem, mis analüüsib kliendi tegevust reaalajas ja suudab kohe teha asjakohase pakkumise. Sellise funktsionaalsuse rakendamiseks kasutatakse arhitektuurimustrit, mida nimetatakse sündmuspõhiseks arhitektuuriks (EDA). Ükski kaasaegne Service Mesh ei toeta selliseid mustreid natiivsetena, kuigi see on väga oluline, eriti panganduses!

On üsna kummaline, et "kaugkõne" Remote Procedure Call (RPC) toetavad kõik Service Mesh'i versioonid, kuid EDA-ga nad ei klapi. Sest Service Mesh on tänapäeva hajutatud integratsiooni sarnane ja EDA on väga aktuaalne arhitektuurimuster, mis võimaldab teha ainulaadseid asju kliendikogemuse osas.

Meie Enterprise Service Mesh peab selle probleemi lahendama. Samuti soovime näha selles garanteeritud kohaletoimetamise, voogedastuse ja keeruka sündmuste töötlemise rakendust, kasutades mitmesuguseid filtreid ja mustreid.

Failide edastamise teenus

Lisaks EDA-le oleks hea omada ka failide edastamise võimalust: suurtes ettevõtetes on sageli võimalik vaid failide integreerimine. Konkreetsemalt kasutatakse arhitektuurimustrit ETL (Extract, Transform, Load — "andmete väljavõtmine, muutmine, laadimine"). Sel juhul vahetatakse tavaliselt andmeid ainult failide kaupa: kasutatakse suuri andmeid, mida pole mõtet saata eraldi päringutega. Failide edastamise natiivne toetus Enterprise Service Mesh'is annab ettevõttele vajaliku paindlikkuse.

Orkestreerimise teenus

Suurtes organisatsioonides on peaaegu alati erinevad meeskonnad, kes teevad erinevaid tooteid. Näiteks pangas töötavad ühe meeskonna liikmed hoiuste kallal, samas kui teised tegelevad krediitproduktidega, ja selliseid juhtumeid on piisavalt palju. Need on erinevad inimesed, erinevad meeskonnad, kes loovad oma tooteid, arendavad oma API-sid ja pakuvad neid teistele. Ja väga tihti tekib vajadus nende teenuste kompositsiooni ning keerulise loogika rakendamise järele, kus toimub järjestikune API-de kõne. Selle probleemi lahendamiseks on vaja integratsioonikihti, mis võimaldab kogu seda komposiitloogikat lihtsustada (mitme API kõne, päringute marsruudi määratlemine jne). Just see on orkestreerimisteenus Enterprise Service Meshis.

AI ja ML

Kui mikroteenused suhtlevad ühtse integratsioonikihi kaudu, teab Service Mesh loomulikult kõike igast teenuse kõnest. Kogume telemeetriaandmeid: kes kedagi kutsus, millal, kui kaua, kui tihti jne. Kui neid teenuseid on sadu tuhandeid ja kõnesid miljardeid, siis see kõik koguneb ja moodustab Big Data. Neid andmeid saab analüüsida tehisintellekti, masinõppe ja muu abil ning seejärel luua analüüsi tulemuste põhjal mõned kasulikud asjad. Oleks otstarbekas vähemalt osaliselt usaldada tehisintellektile juhtimine selle kogu võrgu liikluse ja rakenduste kõnede üle, mis on integreeritud Service Meshisse.

API Gateway (API Lood)

Tavaliselt sisaldab Service Mesh vaheproksi ja teenuseid, mis suhtlevad omavahel usaldusväärse piiri sees. Kuid on ka väliseid sidusrühmi. API-de nõuded, mida sellele tarbijate rühmale pakutakse, on palju tõsisemad. Jagame selle ülesande kaheks peamiseks osaks.

• Turvalisus. Küsimused, mis on seotud ddos'i, protokollide, rakenduste, operatsioonisüsteemide jne haavatavustega.
• Mõõtkavad. Kui API-de arv, mida tuleb klientidele anda, ulatub tuhandetesse või isegi sadadesse tuhandetesse, siis tekib vajadus mingisuguse vahendi järele nende API-de kogumi haldamiseks. On vajalik pidevalt jälgida API-de toimimist: kas nad töötavad või mitte, mis on nende staatus, milline on liiklus jne. API-lood peavad selle ülesandega hakkama saama, muutes kogu protsessi hallatavaks ja turvaliseks. Tänu sellele komponendile õpib Enterprise Service Mesh, et ilma tarbetute keerukusteta avaldada nii sisemisi API-sid kui ka väliseid.

Spetsiaalsete protokollide ja andmevormingute toetamise teenus (AS-i lüüs)

Praegu oskab enamik Service Mesh lahendusi natiivsetena töötada ainult HTTP ja HTTP2 liikluses või piiratud režiimis TCP/IP tasemel. Enterprise Service Mesh-is tuleb esile palju teisi spetsiifilisi andmeedastusprotokolle. Mõned süsteemid võivad kasutada sõnumi vahendajaid, teised on integreeritud andmebaasi tasemel. Kui ettevõttes on SAP, võib see samuti kasutada oma integreerimissüsteemi. Kõik see töötab ja on äri oluline osa.

Ei saa lihtsalt öelda: "Lähme legacy-st lahti ja teeme uusi süsteeme, mis suudavad kasutada Service Mesh-i". Kõikide vanade süsteemide sobitamiseks uute (mikroteenuste arhitektuuriga) süsteemide vahel, mis võivad kasutada Service Mesh-i, on vaja mingit adapterit, vahendajat, lüüsit. Olge nõus, oleks tore, kui see tuleks koos teenusega pakendis. AS-i lüüs suudab toetada igasuguseid integratsiooni variante. Kujutage ette, et paigaldate lihtsalt Enterprise Service Mesh-i ja see on juba valmis töötama kõigi vajalike protokollidega. Meie jaoks on see lähenemine väga oluline.

Nii me kujutame ette Enterprise Service Mesh-i. Kirjeldatud kohandamine lahendab enamiku probleeme, mis tekivad, kui proovida kasutada valmis open-source integreerimislahendusi. Vaid paar aastat tagasi tekkis Service Mesh arhitektuur jätkab arenemist ja me oleme rõõmsad, et saame oma panuse anda. Loodame, et meie kogemus on teile kasulik.

Allikas: habr.com