„Service Mesh“ yra gerai žinomas architektūrinis modelis, skirtas mikro paslaugų integravimui ir perėjimui į debesų infrastruktūrą. Šiandien debesų konteinerių pasaulyje be jo gana sunku išsiversti. Rinkoje jau yra keletas atvirojo kodo paslaugų tinklelio diegimų, tačiau jų funkcionalumo, patikimumo ir saugumo ne visada pakanka, ypač kai kalbama apie didelių finansinių kompanijų visoje šalyje reikalavimus. Štai kodėl mes, Sbertech, nusprendėme pritaikyti „Service Mesh“ ir norime pakalbėti apie tai, kas „Service Mesh“ yra puiku, kas ne taip šaunu ir ką ketiname su tuo daryti.
„Service Mesh“ modelio populiarumas auga populiarėjant debesų technologijoms. Tai yra tam skirtas infrastruktūros sluoksnis, kuris supaprastina skirtingų tinklo paslaugų sąveiką. Šiuolaikinės debesų programos susideda iš šimtų ar net tūkstančių tokių paslaugų, kurių kiekviena gali turėti tūkstančius kopijų.
Šių paslaugų sąveika ir valdymas yra pagrindinė Service Mesh užduotis. Tiesą sakant, tai yra daugelio tarpinių serverių tinklo modelis, valdomas centralizuotai ir atliekantis labai naudingų funkcijų rinkinį.
Tarpinio serverio lygiu (duomenų plokštuma):
- Maršruto parinkimo ir srauto balansavimo politikos priskyrimas ir platinimas
- Raktų, sertifikatų, žetonų platinimas
- Telemetrijos rinkimas, stebėjimo metrikų generavimas
- Integracija su saugumo ir stebėjimo infrastruktūra
Valdymo plokštumos lygyje:
- Maršruto parinkimo ir srauto balansavimo politikos taikymas
- Pakartotinių bandymų ir skirtojo laiko tvarkymas, „negyvų“ mazgų aptikimas (grandinės trūkimas), įterpimo gedimų valdymas ir paslaugos atsparumo užtikrinimas kitais mechanizmais
- Skambučių autentifikavimas / autorizacija
- Metrikos mažinimas (stebimumas)
Šios technologijos plėtra besidominčių vartotojų spektras labai platus – nuo mažų startuolių iki didelių interneto korporacijų, pavyzdžiui, PayPal.
Kodėl „Service Mesh“ reikalingas verslo sektoriuje?
„Service Mesh“ naudojimas turi daug aiškių pranašumų. Visų pirma, tai tiesiog patogu kūrėjams: kodo rašymui atsiranda technologijų platforma, kuris žymiai supaprastina integraciją į debesų infrastruktūrą dėl to, kad transporto sluoksnis yra visiškai izoliuotas nuo programų logikos.
be to, „Service Mesh“ supaprastina tiekėjų ir vartotojų santykius. Šiandien API tiekėjams ir vartotojams daug lengviau susitarti dėl sąsajų ir sutarčių patiems, neįtraukiant specialaus integracijos tarpininko ir arbitro – įmonės paslaugų magistralės. Šis metodas labai paveikia du rodiklius. Padidėja naujų funkcijų pateikimo rinkai greitis (laikas iki rinkos), tačiau tuo pačiu didėja sprendimo kaina, nes integracija turi būti atliekama savarankiškai. „Service Mesh“ naudojimas verslo funkcionalumo kūrimo komandoms padeda išlaikyti pusiausvyrą. Dėl to API teikėjai gali sutelkti dėmesį tik į savo paslaugos taikomąjį komponentą ir tiesiog paskelbti jį „Service Mesh“ - API iš karto taps prieinama visiems klientams, o integracijos kokybė bus paruošta gamybai ir nereikės nė vieno. papildomo kodo eilutė.
Kitas privalumas yra tas kūrėjas, naudodamas „Service Mesh“, orientuojasi tik į verslo funkcionalumą — gaminiui, o ne jo paslaugos technologiniam komponentui. Pavyzdžiui, nebereikia galvoti apie tai, kad situacijoje, kai paslauga iškviečiama per tinklą, kažkur gali nutrūkti ryšys. Be to, „Service Mesh“ padeda subalansuoti srautą tarp tos pačios paslaugos kopijų: jei viena iš kopijų „miršta“, sistema visą srautą perjungs į likusias tiesiogines kopijas.
Serviso tinklelis - tai yra geras pagrindas kuriant paskirstytas programas, kuri nuo kliento slepia skambučių į savo paslaugas tiek viduje, tiek išorėje detales. Visos programos, naudojančios „Service Mesh“, yra atskirtos transporto lygiu tiek nuo tinklo, tiek viena nuo kitos: tarp jų nėra ryšio. Tokiu atveju kūrėjas gauna visišką savo paslaugų kontrolę.
Reikėtų pažymėti, kad Paskirstytas programas paslaugų tinklelio aplinkoje atnaujinti tampa lengviau. Pavyzdžiui, mėlynos/žalios spalvos diegimas, kuriame galima įdiegti dvi taikomųjų programų aplinkas, iš kurių viena nėra atnaujinta ir veikia budėjimo režimu. Nesėkmingo išleidimo atveju grįžtama prie ankstesnės versijos, kurią atlieka specialus maršrutizatorius, su kurio vaidmenį „Service Mesh“ puikiai susidoroja.. Norėdami išbandyti naują versiją, galite naudoti kanarėlių išleidimas — pereiti prie naujos versijos tik 10 % srauto arba bandomosios klientų grupės užklausų. Pagrindinis srautas eina į seną versiją, niekas nesugenda.
Taip pat „Service Mesh“ suteikia mums realiojo laiko SLA valdymą. Paskirstytoji tarpinio serverio sistema neleis paslaugai sugesti, kai vienas iš klientų viršys jam priskirtą kvotą. Jei API pralaidumas yra ribotas, niekas negalės jo priblokšti daugybe operacijų: Service Mesh stovi priešais paslaugą ir neleidžia nereikalingo srauto. Integracijos lygmenyje ji paprasčiausiai atsimuš, o pačios paslaugos toliau dirbs to nepastebėdamos.
Jei įmonė nori sumažinti integracinių sprendimų kūrimo kaštus, Service Mesh taip pat padeda: Galite pereiti prie atvirojo kodo versijos iš komercinių produktų. Mūsų Enterprise Service Mesh yra pagrįsta atvirojo kodo Service Mesh versija.
Kitas privalumas - galimybė naudotis vienu visaverčiu integravimo paslaugų rinkiniu. Kadangi visa integracija yra sukurta naudojant šią tarpinę programinę įrangą, galime valdyti visą integracijos srautą ir ryšius tarp programų, kurios sudaro įmonės verslo branduolį. Tai labai patogu.
Ir pagaliau „Service Mesh“ skatina įmonę pereiti prie dinamiškos infrastruktūros. Dabar daugelis ieško konteinerizacijos. Iškirpti monolitą į mikropaslaugas, gražiai visa tai įgyvendinti – tema kyla į viršų. Tačiau bandant daugelį metų gaminamą sistemą perkelti į naują platformą, iškart susiduriama su daugybe problemų: sugrūsti visa tai į konteinerius ir diegti platformoje nėra lengva. Ir šių paskirstytų komponentų įgyvendinimas, sinchronizavimas ir sąveika yra dar viena labai sudėtinga tema. Kaip jie bendraus tarpusavyje? Ar bus kaskadinių gedimų? „Service Mesh“ leidžia išspręsti kai kurias iš šių problemų ir palengvinti perėjimą iš senosios architektūros į naują, nes galite pamiršti tinklo mainų logiką.
Kodėl jums reikia „Service Mesh“ tinkinimo?
Mūsų įmonėje egzistuoja šimtai sistemų ir modulių, o veikimo laikas yra labai apkrautas. Taigi paprasto modelio, kai viena sistema iškviečia kitą ir gauna atsakymą, neužtenka, nes gamyboje norime daugiau. Ko dar reikia iš įmonės paslaugų tinklo?
Renginių apdorojimo paslauga
Įsivaizduokime, kad reikia padaryti realiu laiku įvykių apdorojimą – sistemą, kuri realiu laiku analizuoja kliento veiksmus ir gali iš karto pateikti jam aktualų pasiūlymą. Norėdami įdiegti panašias funkcijas, naudokite architektūrinis modelis, vadinamas įvykių pagrindu architektūra (EDA). Nė vienas iš dabartinių paslaugų tinklelio iš esmės nepalaiko tokių modelių, tačiau tai labai svarbu, ypač bankui!
Gana keista, kad nuotolinį procedūrų skambutį (RPC) palaiko visos „Service Mesh“ versijos, tačiau jos nėra draugiškos EDA. Kadangi „Service Mesh“ yra tam tikra moderni paskirstyta integracija, o EDA yra labai aktualus architektūrinis modelis, leidžiantis padaryti unikalius dalykus klientų patirties požiūriu.
Mūsų „Enterprise Service Mesh“ turėtų išspręsti šią problemą. Be to, norime, kad jame būtų įgyvendintas garantuotas pristatymas, srautinis perdavimas ir sudėtingas įvykių apdorojimas, naudojant įvairius filtrus ir šablonus.
Failų perkėlimo paslauga
Be EDA, būtų malonu turėti galimybę perkelti failus: Enterprise mastu labai dažnai galima tik failų integracija. Visų pirma, naudojamas ETL (Extract, Transform, Load) architektūrinis modelis. Jame, kaip taisyklė, visi keičiasi tik failais: naudojami dideli duomenys, o tai nepraktiška stumti atskiras užklausas. Galimybė iš esmės palaikyti failų perkėlimą „Enterprise Service Mesh“ suteikia jūsų verslui reikalingo lankstumo.
Orkestravimo paslauga
Didelės organizacijos beveik visada turi skirtingas komandas, gaminančias skirtingus produktus. Pavyzdžiui, banke vienos komandos dirba su indėliais, kitos – su paskolų produktais, o tokių atvejų yra gana daug. Tai skirtingi žmonės, skirtingos komandos, kurios kuria savo produktus, kuria API ir teikia jas kitiems. Ir labai dažnai reikia sudaryti šias paslaugas, taip pat įdiegti sudėtingą logiką, kad būtų galima nuosekliai iškviesti API rinkinį. Kad išspręstumėte šią problemą, jums reikia sprendimo integravimo sluoksnyje, kuris supaprastins visą šią sudėtinę logiką (kviestų kelias API, apibūdintų užklausos maršrutą ir pan.). Tai orkestravimo paslauga „Enterprise Service Mesh“.
AI ir ML
Kai mikropaslaugos bendrauja per vieną integracijos lygmenį, „Service Mesh“ natūraliai žino viską apie kiekvienos paslaugos skambučius. Renkame telemetriją: kas kam skambino, kada, kiek laiko, kiek kartų ir pan. Kai yra šimtai tūkstančių šių paslaugų ir milijardai skambučių, visa tai kaupiasi ir formuoja Big Data. Šiuos duomenis galima analizuoti naudojant AI, mašininį mokymąsi ir pan., o tada, remiantis analizės rezultatais, galima atlikti keletą naudingų dalykų. Viso šio tinklo srauto ir programų iškvietimų, integruotų į Service Mesh, valdymą būtų tikslinga bent iš dalies perduoti dirbtiniam intelektui.
API šliuzo paslauga
Paprastai „Service Mesh“ turi tarpinius serverius ir paslaugas, kurios tarpusavyje bendrauja patikimu perimetru. Tačiau yra ir išorinių sandorio šalių. Šiai vartotojų grupei taikomi API reikalavimai yra daug griežtesni. Šią užduotį padalijame į dvi pagrindines dalis.
- saugumas. Problemos, susijusios su ddos, protokolų, programų, operacinių sistemų pažeidžiamumu ir pan.
- Skalė. Kai API, kurias reikia aptarnauti klientams, skaičius siekia tūkstančius ar net šimtus tūkstančių, reikia šio API rinkinio valdymo įrankio. Reikia nuolat stebėti API: ar jos veikia, ar ne, kokia jų būsena, koks srautas teka, kokia statistika ir t.t. API šliuzas turėtų atlikti šią užduotį ir užtikrinti, kad visas procesas būtų valdomas ir saugus. Dėl šio komponento „Enterprise Service Mesh“ išmoksta lengvai skelbti vidines ir išorines API.
Konkrečių protokolų ir duomenų formatų palaikymo paslauga (AS šliuzas)
Šiuo metu dauguma „Service Mesh“ sprendimų gali veikti tik su HTTP ir HTTP2 srautu arba sumažintu režimu tokiu lygiu TCP/IP„Enterprise Service Mesh“ diegia daug kitų labai specifinių duomenų perdavimo protokolų. Kai kurios sistemos gali naudoti pranešimų tarpininkus, o kitos yra integruotos duomenų bazės lygmeniu. Jei įmonė turi SAP, ji taip pat gali naudoti savo integracijos sistemą. Visa tai veikia ir yra svarbi verslo dalis.
Negalite tiesiog pasakyti: „Palikime seną ir sukurkime naujas sistemas, kurios galėtų naudoti „Service Mesh“. Norint sujungti visas senas sistemas su naujomis (mikro paslaugų architektūroje), sistemoms, kurios gali naudoti Service Mesh, reikės tam tikro adapterio, tarpininko, šliuzo. Sutikite, būtų malonu, jei jis būtų dėžutėje kartu su paslauga. Kintamosios srovės šliuzas gali palaikyti bet kokią integravimo parinktį. Įsivaizduokite, tiesiog įdiegiate „Enterprise Service Mesh“ ir jis yra pasirengęs sąveikauti su visais jums reikalingais protokolais. Šis požiūris mums labai svarbus.
Maždaug taip įsivaizduojame korporacinę Service Mesh (Enterprise Service Mesh) versiją. Aprašytas pritaikymas išsprendžia daugumą problemų, kylančių bandant naudoti paruoštas atvirojo kodo integravimo platformos versijas. Vos prieš porą metų pristatyta „Service Mesh“ architektūra toliau tobulėja, ir mes džiaugiamės galėdami prisidėti prie jos kūrimo. Tikimės, kad mūsų patirtis bus jums naudinga.
Šaltinis: www.habr.com
