Service Mesh — tuntud arhitektuurimuster mikroteenuste integreerimiseks ja pilveinfrastruktuurile üleminekuks. Täna on pilve-konteinerite maailmas temata üha keerulisem hakkama saada. Turul on juba saadaval mitmeid avatud lähtekoodiga Service Mesh'i teostusi, kuid nende funktsionaalsus, usaldusväärsus ja turvalisus pole alati piisavad, eriti kui jutt käib suurte riikliku mõõtmega rahandusettevõtete vajadustest. Seetõttu otsustasime Sbertechi's kohandada Service Mesh'i ja tahame rääkida, mis on Service Mesh'is äge, mis mitte, ning mida me selle kallal teha plaanime.
Service Mesh'i malli populaarsus kasvab koos pilvetehnoloogiate populaarsusega. See kujutab endast eraldi infrastruktuuri kihti, mis lihtsustab erinevate võrguteenuste vahel suhelda. Kaasaegsed pilve rakendused koosnevad sadadest ja isegi tuhandetest sellistest teenustest, millest igal võib olla tuhandeid koopiaid.
Interaktsioon nende teenuste vahel ja nende haldamine on Service Mesh'i keskne ülesanne. Tegelikult on tegemist mitmest proksist koosneva võrgumudeliga, mida haldatakse keskelt ja mis täidab hulga väga kasulikke funktsioone.
Proksi tasandil (data plane):
- Reeglite marsruutimise ja liikluse tasakaalustamise määramine ja levitamine
- Võtmete, sertifikaatide, tokenite levitamine
- Telemeetria kogumine, seire meetrikate vormimine
- Integreerimine turbe- ja seireinfrastruktuuriga
Kontrollitasandi (control plane) tase:
- Reeglite marsruutimise ja liikluse tasakaalustamise rakendamine
- Korduste ja ajaületuste haldamine, 'surnud' sõlmede määramine (circuit breaking), tõrgete juhtimine (injecting faults) ja teenuste vastupidavuse (resilience) tagamine muude mehhanismide kaudu
- Kutsunge autentimine/autoriseerimine
- Metrikate heitmine (observability)
Kasutajate ring, kes on huvitatud selle tehnoloogia arendamisest, on väga lai — alates väikestest alustavatest ettevõtetest kuni suurte interneti korporatsioonideni, näiteks PayPal.
Milleks on Service Mesh ettevõtlussektoris vajalik
Service Meshi kasutamine toob kaasa palju ilmseid eeliseid. Esiteks, see on arendajatele lihtsalt mugav: koodi kirjutamiseks tekib tehnoloogiline platvorm, mis lihtsustab pilveinfrastruktuuri integreerimist, kuna transpordikiht on täielikult eraldatud rakendusloogikast.
Lisaks toetab Service Mesh lihtsustab tarnijate ja tarbijate suhete loomist. Täna on API tarnijatel ja tarbijatel palju lihtsam omavahel kokku leppida liidestes ja lepingutes, kaasamata selleks eraldi integreerimise vahendajat ja vahemeest – ettevõtte teenuste vahetust. Selline lähenemine mõjutab oluliselt kaht näitajat. Uute funktsioonide turule toomise kiirus (time-to-market) suureneb, kuid samas tõuseb lahenduse hind, kuna integreerimine tuleb teha iseseisvalt. Service Meshi kasutamine ärifunktsioone arendavate meeskondade poolt aitab säilitada tasakaalu. Lõppkokkuvõttes saavad API tarnijad keskenduda oma teenuse rakenduskomponendile ning lihtsalt avaldada selle Service Mesh'is – API on kohe kõigile klientidele kergesti kättesaadav ning integreerimise kvaliteet on tootmisvalmis ega nõua ühtegi täiendavat koodirida.
Järgmine eelis on see, et arendaja, kasutades Service Mesh'i, keskendub ainulaadselt äritegevuse funktsionaalsusele — toote, mitte tehnoloogia aspektidele oma teenuses. Näiteks ei pea enam muretsema selle pärast, et olukorras, kus teenust kutsub välja võrku, võib kuskil juhtuda ühenduse katkemine. Lisaks aitab Service Mesh tasakaalustada liiklust samade teenuse koopia vahel: kui üks koopia on „surnud”, suunab süsteem kogu liikluse allesjäänud aktiveeritud koopiatele.
Teenuste Mesh — see on hea alus jaotatud rakenduste loomiseks, mis varjab kliendi eest teenuse kutsete tagamise üksikasju nii seest kui väljast. Kõik rakendused, mis kasutavad Service Mesh'i, on transporditasandil isoleeritud nii võrgust kui üksteisest: nende vahel ei ole mingit ühendust. Sellega samas saab arendaja oma teenuste üle täieliku kontrolli.
Oluline on märkida, et jaotatud rakenduste värskendamine keskkonnas, kus kasutatakse Service Mesh'i, muutub lihtsamaks. Näiteks blue/green-deployments, kus rakenduse jaoks on saadaval kaks keskkonda, millest üks ei uuene ja on ootel. Ebaõnnestumise korral tagasipöördumine varasema versiooni juurde toimub spetsiaalse marsruutija abil, millega Service Mesh suurepäraselt toime tuleb.. Uue versiooni katsetamiseks saab kasutada ka kanarrelease — suunata uus versioon ainult 10% liiklusest või päringud pilootklientide rühmalt. Peamine liiklus läheb vanale versioonile, mis ei katke.
Samuti Service Mesh annab meile SLA reaalajas kontrolli. Jaotatud proksisüsteem ei lase teenust kokku kukkuda, kui mõni klient ületab talle antud kvooti. Kui API-l on piiratud läbilaskevõime, ei saa keegi seda massiliste tehingute arvuga üle koormata: Service Mesh seisab teenuse ees ja ei lase liigselt liiklust läbi. See lihtsalt tõrjub integreerimiskihtides tagasi, samas kui teenused jätkavad tööd, seda märkamatult.
Kui ettevõte soovib integreerimislahenduste arenduselt kulusid kokku hoida, aitab Service Mesh ka: selle avatud lähtekoodiga versioonile saab üle minna kommertstooteid kasutades.. Meie Enterprise Service Mesh põhineb open-source versioonil Service Mesh.
Veel üks eelis — ühtse täislahenduse integreerimisteenuste komplekti olemasolu. Kuna kogu integreerimine toimub selle vahekihina, saame hallata kogu integreerimistrafikut ja rakenduste vahelisi suhteid, mis moodustavad ettevõtte äri tuuma. See on väga mugav.
Ja lõpuks Service Mesh stimuleerib ettevõtte üleminekut dünaamilisele infrastruktuurile. Praegu vaatavad paljud konteineriseerimise poole. Monoliidi jagamine mikroteenusteks ja nende kauni rakendamise teema on tõusuteel. Kuid kui püüad viia uutele rööbastele süsteemi, mis on juba aastaid tootmises, seisad kohe silmitsi hulga probleemidega: kõike seda konteineritesse suruda ja platvormile juurutada ei ole lihtne. Ja nende hajutatud komponentide juurutamine, sünkroniseerimine ja omavaheline koostöö on veel üks äärmiselt keeruline teema. Kuidas nad üksteisega suhtlevad? Kas kaskaadlõhkemise oht on olemas? Service Mesh võimaldab lahendada osa neist probleemidest ja lihtsustada üleminekut vanalt arhitektuurilt uuele, unustades võrguvahetuse loogika.
Miks on Service Meshi kohandamine vajalik?
Meie ettevõttes elavad koos sajad süsteemid ja moodulid ning runtime on väga koormatud. Seega ei piisa lihtsast mustrist, kus üks süsteem kutsub üles teist ja saab vastuse, sest tootmises tahame me rohkem. Mida veel on vaja ettevõtte Service Meshilt?
Sündmuste töötlemise teenus
Kujutame ette, et meil on vaja töötada välja reaalajas sündmuste töötlemine — süsteem, mis analüüsib kliendi toiminguid reaalajas ja suudab kohe pakkuda asjakohast ettepanekut. Sellise funktsionaalsuse rakendamiseks kasutatakse arhiitektuurimustrit, mida nimetatakse sündmustel põhinevaks arhitektuuriks (EDA). Ükski olemasolev Service Mesh ei toeta selliseid mustreid kohandatult, ja see on väga oluline, eriti panganduse jaoks!
On üsna kummaline, et kõik Service Meshi versioonid toetavad „eemaldatud kutsumise” Remote Procedure Call (RPC), kuid nad ei suhtle EDA-ga. Sest Service Mesh on midagi modernaalselt jaotatud integreerimist, samas kui EDA on väga aktuaalne arhitektuurimuster, mis võimaldab luua ainulaadseid asju kliendikogemuse osas.
Meie Enterprise Service Mesh peab lahendama antud probleemi. Lisaks soovime näha selles tagatud kohaletoimetamise, voogedastuse ja kompleksete sündmuste töötlemise rakendust, kasutades mitmesuguseid filtreid ja malle.
Failide edastamise teenus
Peale EDA oleks samuti hea, kui oleks võimalus faile edastada: ettevõtte tasemel on sageli võimalik ainult failide integreerimine. Konkreetsemalt kasutatakse arhitektuurimustrit ETL (Extract, Transform, Load — "väljavõtmine, täiustamine, laadimine"). Sellisel juhul vahetatakse reeglina ainult faile: kasutatakse suurandmeid, mida ei ole otstarbekas eraldi päringutega edastada. Failide edastamise natiivne tugi Enterprise Service Meshis pakub vajalikku paindlikkust ettevõtte jaoks.
Orkestreerimise teenus
Suurtes organisatsioonides on peaaegu alati erinevad meeskonnad, kes töötavad erinevate toodetega. Näiteks pangas töötavad ühed meeskonnad hoiuste, samas kui teised töötavad laenutoodete kallal, ja selliseid näiteid on piisavalt palju. Need on erinevad inimesed, erinevad meeskonnad, kes loovad oma tooteid, arendavad oma API-sid ja pakuvad neid teistele. Tihti tekib vajadus nende teenuste kombineerimise ning keerulise järjestikuste API kõnede loogika rakendamise järele. Selle probleemi lahendamiseks on vaja lahendust integreerimistasandil, mis lihtsustab kogu selle komposiitloogika (mitme API kõne, päringute marsruudi kirjeldamine jne). Just see on teenus, mis orkestreerib Enterprise Service Meshis.
AI ja ML
Kui mikroteenused suhtlevad ühise integratsiooni kihi, Service Mesh, kaudu, teab see loomulikult kõike iga teenuse väljakutsetest. Kogume telemeetria andmed: kes kellele helistas, millal, kui kaua, mitu korda jne. Kui neid teenuseid on sadu tuhandeid ja väljakutseid miljardeid, siis kõik see koguneb ja moodustab Big Data. Neid andmeid saab analüüsida tehisintellekti ja masinõppe abil ning seejärel luua analüüsi tulemustel põhinevaid kasulikke lahendusi. Oleks asjakohane vähemalt osaliselt usaldada tehisintellektile kogu see võrgu liiklus ja rakenduste väljakutsed, mis on integreeritud Service Mesh.
API Gateway (API värav)
Reeglina on Service Mesh-is olemas proxy ja teenused, mis suhtlevad omavahel usaldusväärse piiri sees. Kuid on ka välised partnerid. API nõudmised, mida antud tarbijate rühmale pakutakse, on palju tõsisemad. Jagame selle ülesande kaheks peamiseks osaks.
- Ohutus. Küsimused, mis on seotud DDoS-i, protokollide, rakenduste, operatsioonisüsteemide ja muude haavatavustega.
- Mõõtmed. Kui API arveid, mis tuleb klientidele esitada, on tuhandetes või isegi sadades tuhandetes, tekib vajadus kasutada mingit vahendit selle API komplekti haldamiseks. Tuleb pidevalt jälgida API-sid: kas need toimivad või mitte, mis on nende staatus, milline liiklus toimub, millised on statistika jne. API värav peab selle ülesande täitma, tehes kogu protsessi hallatavaks ja turvaliseks. Tänu sellele komponendile suudab Enterprise Service Mesh õppida, kuidas ilmseid raskusi ületades avaldada nii sisemist kui ka välist API-d.
Spetsiifiliste protokollide ja andmeformatide toetus (AS värav)
Praeguseks oskab enamus Service Mesh lahendusi natiivsetelt töötada vaid HTTP ja HTTP2 liiklusega või piiratud režiimis TCP/IP tasemel. Enterprise Service Meshil on palju teisi üsna spetsiifilisi andmeedastusprotokolle. Üks süsteem võib kasutada sõnumite vahendajaid, teine on integreeritud andmebaasi tasemel. Kui ettevõttes on SAP, võib see samuti kasutada oma integratsioonisüsteemi. Kõik see töötab ja on oluline osa ettevõtte tegevusest.
Ei saa lihtsalt öelda: „Loodame loobuda pärandlahendustest ja luua uusi süsteeme, mis suudaksid kasutada Service Meshi“. Kuidas küll viia kõik vanad süsteemid kokku uute (mikroteenuste arhitektuuriga) süsteemidega? Need, mis saavad kasutada Service Meshi, vajavad mingit adapterit, vahendajat, väravat. Oleks suurepärane, kui see kaasatakse teenusepaketti. AS-i värav toetab igasuguseid integreerimise variante. Kujutage vaid ette, et installite Enterprise Service Meshi ja see on juba valmis suhtlema kõigi vajalike protokollidega. Meie jaoks on selline lähenemine äärmiselt oluline.
Umbes nii kujutame ette ettevõtte versiooni Service Meshist (Enterprise Service Mesh). Kirjeldatud kohandamine lahendab enamik probleeme, mis tekivad, kui püüda kasutada olemasolevaid avatud lähtekoodiga integreerimisplatvorme. Ilmudes vaid paar aastat tagasi, jätkab Service Meshi arhitektuur arengut ning meil on hea meel, et saame panustada selle arengusse. Loodame, et meie kogemus on teile kasulik.
Allikas: habr.com
