Service Mesh on tuntud arhitektuurne muster mikroteenuste integreerimiseks ja pilveinfrastruktuurile üleminekuks. Tänapäeval on pilvekonteinerite maailmas üsna raske ilma selleta hakkama saada. Turul on juba saadaval mitmed avatud lähtekoodiga teenuste võrgurakendused, kuid nende funktsionaalsus, töökindlus ja turvalisus ei ole alati piisavad, eriti kui rääkida suurte finantsettevõtete nõudmistest üle kogu riigi. Seetõttu otsustasime Sbertechis kohandada Service Meshi ja tahame rääkida sellest, mis on Service Meshis lahe, mis mitte nii lahe ja mida me sellega ette võtame.
Service Meshi mustri populaarsus kasvab koos pilvetehnoloogiate populaarsusega. See on spetsiaalne infrastruktuurikiht, mis lihtsustab erinevate võrguteenuste vahelist suhtlust. Kaasaegsed pilverakendused koosnevad sadadest või isegi tuhandetest sellistest teenustest, millest igaühel võib olla tuhandeid koopiaid.
Nende teenuste vaheline suhtlus ja haldamine on Service Meshi põhiülesanne. Tegelikult on see paljude puhverserverite võrgumudel, mida hallatakse tsentraalselt ja mis täidab väga kasulikke funktsioone.
Puhverserveri tasemel (andmetasandil):
- Marsruutimise ja liikluse tasakaalustamise poliitikate määramine ja levitamine
- Võtmete, sertifikaatide, žetoonide jagamine
- Telemeetria kogumine, seiremõõdikute genereerimine
- Integratsioon turva- ja seireinfrastruktuuriga
Juhttasandi tasandil:
- Marsruutimise ja liikluse tasakaalustamise poliitika rakendamine
- Korduskatsete ja ajalõppude haldamine, "surnud" sõlmede tuvastamine (vooluahela katkemine), vigade sisestamine ja teenuse vastupidavuse tagamine muude mehhanismide kaudu
- Kõne autentimine/volitamine
- Mõõdikute langetamine (jälgitavus)
Selle tehnoloogia arendamisest huvitatud kasutajate ring on väga lai – alates väikestest idufirmadest kuni suurte Interneti-korporatsioonideni, näiteks PayPal.
Miks on Service Meshi ärisektoris vaja?
Service Meshi kasutamisel on palju selgeid eeliseid. Esiteks on see arendajatele lihtsalt mugav: koodi kirjutamiseks ilmub tehnoloogiaplatvorm, mis lihtsustab oluliselt pilve infrastruktuuri integreerimist tänu sellele, et transpordikiht on rakendusloogikast täielikult isoleeritud.
Lisaks Service Mesh lihtsustab suhteid tarnijate ja tarbijate vahel. Tänapäeval on API pakkujatel ja tarbijatel palju lihtsam ise liidestes ja lepingutes kokku leppida, ilma spetsiaalset integratsioonivahendajat ja vahekohtunikku – ettevõtte teenindusbussi – kaasamata. See lähenemine mõjutab oluliselt kahte näitajat. Suureneb uute funktsionaalsuste turule toomise kiirus (time-to-market), kuid samal ajal tõuseb lahenduse maksumus, kuna integreerimine tuleb teha iseseisvalt. Tasakaalu aitab siin hoida Service Meshi kasutamine ärifunktsioonide arendusmeeskondade poolt. Selle tulemusel saavad API pakkujad keskenduda ainult oma teenuse rakenduskomponendile ja lihtsalt avaldada selle teenuses Service Mesh – API muutub kohe kättesaadavaks kõikidele klientidele ja integratsiooni kvaliteet on tootmiseks valmis ega vaja ühtegi lisakoodi rida.
Järgmine eelis on see arendaja, kasutades Service Meshi, keskendub ainult ärifunktsioonidele — pigem toote kui selle teenuse tehnoloogilise komponendi kohta. Näiteks ei pea enam mõtlema sellele, et olukorras, kus teenust helistatakse üle võrgu, võib kusagil tekkida ühenduse tõrge. Lisaks aitab Service Mesh tasakaalustada liiklust sama teenuse koopiate vahel: kui üks koopiatest "sureb", lülitab süsteem kogu liikluse ülejäänud reaalajas koopiatele.
Teenindusvõrk - see on hea alus hajutatud rakenduste loomiseks, mis varjab kliendi eest oma teenustele nii sise- kui ka väliskõnede tegemise üksikasju. Kõik Service Meshi kasutavad rakendused on transporditasemel isoleeritud nii võrgust kui ka üksteisest: nende vahel puudub side. Sel juhul saab arendaja oma teenuste üle täieliku kontrolli.
Tuleb märkida, et Jaotatud rakenduste värskendamine teenindusvõrgu keskkonnas muutub lihtsamaks. Näiteks sinine/roheline juurutus, mille puhul on installimiseks saadaval kaks rakenduskeskkonda, millest ühte ei värskendata ja see on ooterežiimis. Ebaõnnestunud väljalaske korral eelmisele versioonile naasmise teostab spetsiaalne ruuter, mille rolliga Service Mesh saab hästi hakkama. Uue versiooni testimiseks võite kasutada kanaari vabastamine — lülituge uuele versioonile ainult 10% liiklusest või pilootklientide rühma päringutest. Põhiline liiklus läheb vanale versioonile, midagi ei purune.
Ka Service Mesh annab meile reaalajas SLA juhtimise. Hajutatud puhverserveri süsteem ei lase teenusel ebaõnnestuda, kui üks klientidest ületab talle määratud kvoodi. Kui API läbilaskevõime on piiratud, ei saa keegi seda suure tehingute arvuga üle koormata: Service Mesh seisab teenuse ees ega luba tarbetut liiklust. See lihtsalt võitleb integratsioonikihis tagasi ja teenused ise jätkavad tööd ilma seda märkamata.
Kui ettevõte soovib integratsioonilahenduste arendamiseks kulusid vähendada, aitab Service Mesh ka: Saate lülituda selle avatud lähtekoodiga versioonile kommertstoodetest. Meie Enterprise Service Mesh põhineb Service Meshi avatud lähtekoodiga versioonil.
Teine eelis - ühe tervikliku integratsiooniteenuste komplekti kättesaadavus. Kuna kogu integratsioon on üles ehitatud selle vahevara kaudu, saame hallata kogu integratsiooniliiklust ja ühendusi rakenduste vahel, mis moodustavad ettevõtte ärituumiku. See on väga mugav.
Ja lõpuks Service Mesh julgustab ettevõtet liikuma dünaamilisele infrastruktuurile. Nüüd otsivad paljud konteineriseerimist. Monoliidi mikroteenusteks lõikamine, kõik selle ilusti elluviimine - teema on tõusuteel. Kuid kui proovite mitu aastat tootmises olnud süsteemi üle viia uuele platvormile, tekib kohe mitmeid probleeme: selle kõige konteineritesse surumine ja platvormile juurutamine pole lihtne. Ja nende hajutatud komponentide rakendamine, sünkroonimine ja koostoime on veel üks väga keeruline teema. Kuidas nad omavahel suhtlema hakkavad? Kas esineb kaskaadtõrkeid? Service Mesh võimaldab teil lahendada mõned neist probleemidest ja hõlbustada üleminekut vanalt arhitektuurilt uuele, kuna võite unustada võrguvahetuse loogika.
Miks vajate Service Meshi kohandamist?
Meie ettevõttes eksisteerib koos sadu süsteeme ja mooduleid ning käitusaeg on väga koormatud. Nii et lihtsast mustrist, kus üks süsteem helistab teisele ja saab vastuse, ei piisa, sest tootmises tahame rohkem. Mida veel vajate ettevõtte teenindusvõrgust?
Ürituste töötlemise teenus
Kujutagem ette, et tuleb teha reaalajas sündmuste töötlemine – süsteem, mis analüüsib kliendi tegevust reaalajas ja suudab talle koheselt vastava pakkumise teha. Sarnaste funktsioonide rakendamiseks kasutage arhitektuuriline muster, mida nimetatakse sündmustepõhiseks arhitektuuriks (EDA). Ükski praegune teenindusvõrk ei toeta selliseid mustreid, kuid see on väga oluline, eriti panga jaoks!
On üsna kummaline, et Remote Procedure Call (RPC) toetavad kõik Service Meshi versioonid, kuid need pole EDA-ga sõbralikud. Sest Service Mesh on omamoodi kaasaegne hajutatud integratsioon ja EDA on väga asjakohane arhitektuurimuster, mis võimaldab teha kliendikogemuse mõttes ainulaadseid asju.
Meie Enterprise Service Mesh peaks selle probleemi lahendama. Lisaks soovime selles näha garanteeritud edastamise, voogedastuse ja keeruka sündmuste töötlemise rakendamist, kasutades erinevaid filtreid ja malle.
Failiedastusteenus
Lisaks EDA-le oleks tore, kui saaks faile üle kanda: Enterprise mastaabis on väga sageli võimalik ainult failide integreerimine. Eelkõige kasutatakse ETL (Extract, Transform, Load) arhitektuurimustrit. Selles vahetavad kõik reeglina faile eranditult: kasutatakse suurandmeid, mida pole otstarbekas eraldi päringuid sisse suruda. Võimalus toetada Enterprise Service Meshis failide edastamist, annab teile paindlikkuse, mida teie ettevõte vajab.
Orkestreerimisteenus
Suurtes organisatsioonides on peaaegu alati erinevad meeskonnad, kes valmistavad erinevaid tooteid. Näiteks pangas töötavad ühed meeskonnad hoiustega, teised aga laenutoodetega ja selliseid juhtumeid on päris palju. Need on erinevad inimesed, erinevad meeskonnad, kes toodavad oma tooteid, arendavad oma API-sid ja pakuvad neid teistele. Ja väga sageli on vaja neid teenuseid koostada ja rakendada keerulist loogikat API-de komplekti järjestikuseks kutsumiseks. Selle probleemi lahendamiseks vajate integratsioonikihis lahendust, mis lihtsustab kogu seda liitloogikat (mitu API kutsumine, päringu marsruudi kirjeldamine jne). See on Enterprise Service Meshi orkestreerimisteenus.
AI ja ML
Kui mikroteenused suhtlevad ühe integratsioonikihi kaudu, teab Service Mesh loomulikult iga teenuse kõnede kohta kõike. Kogume telemeetriat: kes kellele helistas, millal, kui kaua, mitu korda jne. Kui neid teenuseid on sadu tuhandeid ja kõnesid miljardeid, siis kõik see koguneb ja moodustab suurandmed. Neid andmeid saab analüüsida tehisintellekti, masinõppe jms abil ning seejärel saab analüüsitulemuste põhjal mõndagi kasulikku teha. Kogu selle Service Meshi integreeritud võrguliikluse ja rakenduste kõnede juhtimine oleks vähemalt osaliselt kohane anda tehisintellektile.
API lüüsi teenus
Tavaliselt on Service Meshil puhverserverid ja teenused, mis suhtlevad üksteisega usaldusväärsel perimeetril. Kuid on ka väliseid vastaspooli. Selle tarbijarühmaga kokkupuutuvate API-de nõuded on palju rangemad. Jagame selle ülesande kaheks põhiosaks.
- turvalisus. Probleemid, mis on seotud ddos-ga, protokollide, rakenduste, operatsioonisüsteemide ja muu haavatavusega.
- Kaal. Kui klientidele teenindatavate API-de arv ulatub tuhandetesse või isegi sadadesse tuhandetesse, on selle API-komplekti jaoks vaja mingit haldustööriista. Peate API-d pidevalt jälgima: kas need töötavad või mitte, milline on nende olek, milline liiklus liigub, milline statistika jne. API lüüs peaks selle ülesandega hakkama saama, muutes kogu protsessi hallatavaks ja turvaliseks. Tänu sellele komponendile õpib Enterprise Service Mesh hõlpsalt avaldama nii sisemisi kui ka väliseid API-sid.
Spetsiaalsete protokollide ja andmevormingute tugiteenus (AS lüüs)
Praegu saab enamik Service Meshi lahendusi natiivselt töötada ainult HTTP ja HTTP2 liiklusega või vähendatud režiimis TCP/IP tasemel. Enterprise Service Mesh on esile kerkimas koos paljude teiste väga spetsiifiliste andmeedastusprotokollidega. Mõned süsteemid võivad kasutada sõnumivahendajaid, teised on integreeritud andmebaasi tasemel. Kui ettevõttel on SAP, siis saab kasutada ka oma integratsioonisüsteemi. Pealegi kõik see toimib ja on äri oluline osa.
Te ei saa lihtsalt öelda: "Hülgame pärandi ja loome uued süsteemid, mis saaksid kasutada Service Meshi." Kõigi vanade süsteemide ühendamiseks uutega (mikroteenuse arhitektuuril) vajavad Service Meshi kasutavad süsteemid mingit adapterit, vahendajat, lüüsi. Nõus, oleks tore, kui see tuleks koos teenindusega karbis. Vahelduvvoolu lüüs võib toetada mis tahes integreerimisvalikut. Kujutage vaid ette, installite lihtsalt Enterprise Service Meshi ja see on valmis suhtlema kõigi vajalike protokollidega. See lähenemine on meie jaoks väga oluline.
Umbes nii kujutame ette Service Meshi (Enterprise Service Mesh) ettevõtte versiooni. Kirjeldatud kohandamine lahendab enamiku probleemidest, mis tekivad, kui proovite kasutada integratsiooniplatvormi avatud lähtekoodiga valmisversioone. Vaid paar aastat tagasi tutvustatud Service Meshi arhitektuur areneb edasi ja meil on hea meel, et saame selle arendamisse panustada. Loodame, et meie kogemus on teile kasulik.
Allikas: www.habr.com