ProHoster > Blogs > Administrācija > Kāpēc mēs veidojam Enterprise Service Mesh?

Kāpēc mēs veidojam Enterprise Service Mesh?

Service Mesh ir labi zināms arhitektÅ«ras modelis mikropakalpojumu integrÄ“Å”anai un migrācijai uz mākoņa infrastruktÅ«ru. MÅ«sdienās mākoņkonteineru pasaulē bez tā ir diezgan grÅ«ti iztikt. TirgÅ« jau ir pieejamas vairākas atvērtā pirmkoda pakalpojumu tÄ«kla ievieÅ”anas, taču to funkcionalitāte, uzticamÄ«ba un droŔība ne vienmēr ir pietiekama, it Ä«paÅ”i, ja runa ir par lielu finanÅ”u uzņēmumu prasÄ«bām visā valstÄ«. Tāpēc mēs Sbertech nolēmām pielāgot Service Mesh un vēlamies runāt par to, kas ir forÅ”s pakalpojumā Service Mesh, kas nav tik forÅ”s un ko mēs ar to darÄ«sim.

Kāpēc mēs veidojam Enterprise Service Mesh?

Service Mesh modeļa popularitāte pieaug lÄ«dz ar mākoņtehnoloÄ£iju popularitāti. Tas ir speciāls infrastruktÅ«ras slānis, kas vienkārÅ”o mijiedarbÄ«bu starp dažādiem tÄ«kla pakalpojumiem. MÅ«sdienu mākoņa lietojumprogrammas sastāv no simtiem vai pat tÅ«kstoÅ”iem Ŕādu pakalpojumu, no kuriem katram var bÅ«t tÅ«kstoÅ”iem kopiju.

Kāpēc mēs veidojam Enterprise Service Mesh?

Å o pakalpojumu mijiedarbÄ«ba un pārvaldÄ«ba ir Service Mesh galvenais uzdevums. Faktiski Å”is ir daudzu starpniekserveru tÄ«kla modelis, kas tiek pārvaldÄ«ts centralizēti un veic ļoti noderÄ«gu funkciju kopumu.

Starpniekservera līmenī (datu plakne):

  • MarÅ”rutÄ“Å”anas un trafika lÄ«dzsvaroÅ”anas politiku pieŔķirÅ”ana un izplatÄ«Å”ana
  • Atslēgu, sertifikātu, žetonu izplatÄ«Å”ana
  • Telemetrijas vākÅ”ana, monitoringa metrikas Ä£enerÄ“Å”ana
  • Integrācija ar droŔības un uzraudzÄ«bas infrastruktÅ«ru

Vadības plaknes līmenī:

  • MarÅ”rutÄ“Å”anas un trafika lÄ«dzsvaroÅ”anas politiku piemēroÅ”ana
  • Atkārtotu mēģinājumu un taimautu pārvaldÄ«ba, ā€œmiruÅ”oā€ mezglu noteikÅ”ana (ķēdes pārtraukums), kļūdu ievadÄ«Å”anas pārvaldÄ«ba un pakalpojumu noturÄ«bas nodroÅ”ināŔana, izmantojot citus mehānismus.
  • Zvana autentifikācija/autorizācija
  • Metrikas nomeÅ”ana (novērojamÄ«ba)

Å Ä«s tehnoloÄ£ijas izstrādē ieinteresēto lietotāju loks ir ļoti plaÅ”s ā€“ no maziem startup uzņēmumiem lÄ«dz lielām interneta korporācijām, piemēram, PayPal.

Kāpēc korporatÄ«vajā sektorā ir nepiecieÅ”ams Service Mesh?

Service Mesh izmantoÅ”anai ir daudz skaidru priekÅ”rocÄ«bu. Pirmkārt, tas ir vienkārÅ”i ērti izstrādātājiem: koda rakstÄ«Å”anai parādās tehnoloÄ£iju platforma, kas ievērojami vienkārÅ”o integrāciju mākoņa infrastruktÅ«rā, jo transporta slānis ir pilnÄ«bā izolēts no lietojumprogrammu loÄ£ikas.

Bez tam, Service Mesh vienkārÅ”o attiecÄ«bas starp piegādātājiem un patērētājiem. MÅ«sdienās API nodroÅ”inātājiem un patērētājiem ir daudz vienkārŔāk vienoties par saskarnēm un lÄ«gumiem paÅ”iem, neiesaistot Ä«paÅ”u integrācijas starpnieku un arbitru - uzņēmuma pakalpojumu kopni. Å Ä« pieeja bÅ«tiski ietekmē divus rādÄ«tājus. Jaunas funkcionalitātes ievieÅ”anas tirgÅ« ātrums (laiks lÄ«dz tirgum) palielinās, bet tajā paŔā laikā palielinās risinājuma izmaksas, jo integrācija ir jāveic neatkarÄ«gi. UzņēmējdarbÄ«bas funkcionalitātes izstrādes komandu izmantotā Service Mesh palÄ«dz saglabāt lÄ«dzsvaru. Rezultātā API nodroÅ”inātāji var koncentrēties tikai uz sava pakalpojuma lietojumprogrammas komponentu un vienkārÅ”i publicēt to Service Mesh ā€” API nekavējoties kļūs pieejama visiem klientiem, un integrācijas kvalitāte bÅ«s gatava ražoÅ”anai un neprasÄ«s nevienu papildu koda rinda.

Nākamā priekÅ”rocÄ«ba ir tā izstrādātājs, izmantojot Service Mesh, koncentrējas tikai uz biznesa funkcionalitāti ā€” uz produktu, nevis uz tā pakalpojuma tehnoloÄ£isko komponentu. Piemēram, vairs nav jādomā par to, ka situācijā, kad pa tÄ«klu tiek izsaukts serviss, kaut kur var rasties savienojuma kļūme. Turklāt Service Mesh palÄ«dz lÄ«dzsvarot trafiku starp viena un tā paÅ”a pakalpojuma kopijām: ja viena no kopijām ā€œnomirstā€, sistēma pārslēgs visu trafiku uz atlikuÅ”ajām dzÄ«vajām kopijām.

Servisa tÄ«kls Sākot no tas ir labs pamats izplatÄ«to lietojumprogrammu izveidei, kas slēpj no klienta informāciju par zvanu nodroÅ”ināŔanu saviem pakalpojumiem gan iekŔēji, gan ārēji. Visas lietojumprogrammas, kas izmanto Service Mesh, transporta lÄ«menÄ« ir izolētas gan no tÄ«kla, gan viena no otras: starp tām nav saziņas. Å ajā gadÄ«jumā izstrādātājs saņem pilnÄ«gu kontroli pār saviem pakalpojumiem.

Jāpiebilst, ka IzplatÄ«to lietojumprogrammu atjaunināŔana pakalpojumu tÄ«kla vidē kļūst vienkārŔāka. Piemēram, zilā/zaļā izvietoÅ”ana, kurā instalÄ“Å”anai ir pieejamas divas lietojumprogrammu vides, no kurām viena nav atjaunināta un atrodas gaidstāves režīmā. AtgrieÅ”anos pie iepriekŔējās versijas neveiksmÄ«gas izlaiÅ”anas gadÄ«jumā veic Ä«paÅ”s marÅ”rutētājs, ar kura lomu Service Mesh lieliski tiek galā. Lai pārbaudÄ«tu jauno versiju, varat izmantot kanārijputniņŔ ā€” pāriet uz jauno versiju tikai 10% trafika vai pieprasÄ«jumu no izmēģinājuma klientu grupas. Galvenā satiksme iet uz veco versiju, nekas neplÄ«st.

arÄ« Service Mesh sniedz mums reāllaika SLA kontroli. Izkliedētā starpniekservera sistēma neļaus pakalpojumam nedarboties, ja kāds no klientiem pārsniedz tam pieŔķirto kvotu. Ja API caurlaidspēja ir ierobežota, neviens to nevarēs pārslogot ar lielu darÄ«jumu skaitu: Service Mesh stāv servisa priekŔā un nepieļauj nevajadzÄ«gu trafiku. Tas vienkārÅ”i cÄ«nÄ«sies integrācijas slānÄ«, un paÅ”i pakalpojumi turpinās strādāt, to nemanot.

Ja uzņēmums vēlas samazināt izmaksas integrācijas risinājumu izstrādei, Service Mesh palīdz arī: Varat pārslēgties uz tā atvērtā pirmkoda versiju no komerciāliem produktiem. Mūsu Enterprise Service Mesh pamatā ir Service Mesh atvērtā pirmkoda versija.

Vēl viena priekÅ”rocÄ«ba - vienota pilnvērtÄ«ga integrācijas pakalpojumu komplekta pieejamÄ«ba. Tā kā visa integrācija tiek veidota, izmantojot Å”o starpprogrammatÅ«ru, mēs varam pārvaldÄ«t visu integrācijas trafiku un savienojumus starp lietojumprogrammām, kas veido uzņēmuma biznesa kodolu. Tas ir ļoti ērti.

Un visbeidzot Service Mesh mudina uzņēmumu pāriet uz dinamisku infrastruktÅ«ru. Tagad daudzi skatās uz konteinerizāciju. MonolÄ«ta izcirÅ”ana mikropakalpojumos, to visu skaisti realizēt - tēma kāpj. Taču, mēģinot daudzus gadus ražotu sistēmu pārnest uz jaunu platformu, uzreiz rodas vairākas problēmas: to visu iegrÅ«st konteineros un izvietot platformā nav viegli. Un Å”o izplatÄ«to komponentu ievieÅ”ana, sinhronizācija un mijiedarbÄ«ba ir vēl viena ļoti sarežģīta tēma. Kā viņi sazināsies savā starpā? Vai bÅ«s kaskādes neveiksmes? Service Mesh ļauj atrisināt dažas no Ŕīm problēmām un atvieglot migrāciju no vecās arhitektÅ«ras uz jauno, jo varat aizmirst par tÄ«kla apmaiņas loÄ£iku.

Kāpēc jums ir nepiecieÅ”ama Service Mesh pielāgoÅ”ana?

MÅ«su uzņēmumā lÄ«dzās pastāv simtiem sistēmu un moduļu, un izpildlaiks ir ļoti noslogots. Tātad ar vienkārÅ”u modeli, kad viena sistēma izsauc otru un saņem atbildi, nepietiek, jo ražoÅ”anā mēs vēlamies vairāk. Kas vēl jums nepiecieÅ”ams no uzņēmuma pakalpojumu tÄ«kla?

Kāpēc mēs veidojam Enterprise Service Mesh?

Pasākumu apstrādes pakalpojums

Iedomāsimies, ka mums ir jāizveido reāllaika notikumu apstrāde ā€“ sistēma, kas reāllaikā analizē klienta darbÄ«bas un var uzreiz izteikt viņam atbilstoÅ”u piedāvājumu. Lai ieviestu lÄ«dzÄ«gu funkcionalitāti, izmantojiet arhitektÅ«ras modelis, ko sauc par notikumu virzÄ«tu arhitektÅ«ru (EDA). Neviens no paÅ”reizējiem pakalpojumu tÄ«kliem neatbalsta Ŕādus modeļus, taču tas ir ļoti svarÄ«gi, jo Ä«paÅ”i bankai!

Diezgan dÄ«vaini, ka Remote Procedure Call (RPC) atbalsta visas Service Mesh versijas, taču tās nav draudzÄ«gas ar EDA. Tā kā Service Mesh ir sava veida moderna izplatÄ«ta integrācija, un EDA ir ļoti atbilstoÅ”s arhitektÅ«ras modelis, kas ļauj veikt unikālas lietas klientu pieredzes ziņā.

MÅ«su Enterprise Service Mesh vajadzētu atrisināt Å”o problēmu. Turklāt mēs vēlamies tajā redzēt garantētas piegādes, straumÄ“Å”anas un sarežģītas notikumu apstrādes ievieÅ”anu, izmantojot dažādus filtrus un veidnes.

Failu pārsūtīŔanas pakalpojums

Papildus EDA bÅ«tu jauki, ja bÅ«tu iespēja pārsÅ«tÄ«t failus: uzņēmuma mērogā ļoti bieži ir iespējama tikai failu integrācija. Jo Ä«paÅ”i tiek izmantots ETL (Extract, Transform, Load) arhitektÅ«ras modelis. Tajā, kā likums, visi apmainās tikai ar failiem: tiek izmantoti lielie dati, kurus nav praktiski iespējams ievietot atseviŔķus pieprasÄ«jumus. Iespēja sākotnēji atbalstÄ«t failu pārsÅ«tÄ«Å”anu Enterprise Service Mesh nodroÅ”ina jÅ«su uzņēmumam nepiecieÅ”amo elastÄ«bu.

OrÄ·estra pakalpojumi

Lielās organizācijās gandrÄ«z vienmēr ir dažādas komandas, kas ražo dažādus produktus. Piemēram, bankā dažas komandas strādā ar noguldÄ«jumiem, bet citas ar kredÄ«tu produktiem, un Ŕādu gadÄ«jumu ir diezgan daudz. Tie ir dažādi cilvēki, dažādas komandas, kas ražo savus produktus, izstrādā API un nodroÅ”ina tos citiem. Un ļoti bieži ir nepiecieÅ”ams izveidot Å”os pakalpojumus, kā arÄ« ieviest sarežģītu loÄ£iku, lai secÄ«gi izsauktu API kopu. Lai atrisinātu Å”o problēmu, ir nepiecieÅ”ams risinājums integrācijas slānÄ«, kas vienkārÅ”os visu Å”o salikto loÄ£iku (vairāku API izsaukÅ”ana, pieprasÄ«juma marÅ”ruta aprakstÄ«Å”ana utt.). Å is ir orÄ·estrÄ“Å”anas pakalpojums Enterprise Service Mesh.

AI un ML

Kad mikropakalpojumi sazinās, izmantojot vienu integrācijas slāni, Service Mesh, protams, zina visu par katra pakalpojuma zvaniem. Mēs apkopojam telemetriju: kurÅ” kuram zvanÄ«jis, kad, cik ilgi, cik reizes utt. Kad ir simtiem tÅ«kstoÅ”u Å”o pakalpojumu un miljardu zvanu, tad tas viss uzkrājas un veido lielos datus. Å os datus var analizēt, izmantojot AI, maŔīnmācÄ«Å”anos utt., un pēc tam, pamatojoties uz analÄ«zes rezultātiem, var veikt dažas noderÄ«gas lietas. Derētu vismaz daļēji visu Å”o Service Mesh integrēto tÄ«kla trafiku un aplikāciju izsaukumu kontroli nodot mākslÄ«gajam intelektam.

API vārtejas pakalpojums

Parasti pakalpojuma tÄ«klam ir starpniekserveri un pakalpojumi, kas savstarpēji sazinās uzticamā perimetrā. Taču ir arÄ« ārēji darÄ«juma partneri. PrasÄ«bas API, kas ir pakļautas Å”ai patērētāju grupai, ir daudz stingrākas. Mēs sadalām Å”o uzdevumu divās galvenajās daļās.

  • DroŔība. Problēmas, kas saistÄ«tas ar ddos, protokolu, lietojumprogrammu, operētājsistēmu un tā tālāk ievainojamÄ«bu.
  • Mērogs. Kad API skaits, kas ir jāapkalpo klientiem, sasniedz tÅ«kstoÅ”iem vai pat simtiem tÅ«kstoÅ”u, Å”ai API kopai ir nepiecieÅ”ams kāds pārvaldÄ«bas rÄ«ks. Jums pastāvÄ«gi jāuzrauga API: vai tie darbojas vai ne, kāds ir to statuss, kāda trafika plÅ«st, kāda statistika utt. API vārtejai vajadzētu veikt Å”o uzdevumu, vienlaikus padarot visu procesu pārvaldāmu un droÅ”u. Pateicoties Å”im komponentam, Enterprise Service Mesh iemācās viegli publicēt gan iekŔējos, gan ārējos API.

Atbalsta pakalpojums konkrētiem protokoliem un datu formātiem (AS vārteja)

PaÅ”laik lielākā daļa Service Mesh risinājumu var darboties tikai ar HTTP un HTTP2 trafiku vai samazinātā režīmā TCP/IP lÄ«menÄ«. Enterprise Service Mesh parādās kopā ar daudziem citiem ļoti specifiskiem datu pārsÅ«tÄ«Å”anas protokoliem. Dažas sistēmas var izmantot ziņojumu brokerus, citas ir integrētas datu bāzes lÄ«menÄ«. Ja uzņēmumam ir SAP, tad tas var izmantot arÄ« savu integrācijas sistēmu. Turklāt tas viss darbojas un ir svarÄ«ga biznesa sastāvdaļa.

JÅ«s nevarat vienkārÅ”i teikt: "Atteiksim no mantojuma un izveidosim jaunas sistēmas, kas var izmantot Service Mesh." Lai savienotu visas vecās sistēmas ar jaunajām (uz mikropakalpojumu arhitektÅ«ras), sistēmām, kas var izmantot Service Mesh, bÅ«s nepiecieÅ”ams kāds adapteris, starpnieks, vārteja. PiekrÄ«tu, bÅ«tu jauki, ja tas bÅ«tu kastÄ«tē kopā ar servisu. Maiņstrāvas vārteja var atbalstÄ«t jebkuru integrācijas iespēju. Iedomājieties, jÅ«s vienkārÅ”i instalējat Enterprise Service Mesh, un tas ir gatavs mijiedarbÄ«bai ar visiem nepiecieÅ”amajiem protokoliem. Å Ä« pieeja mums ir ļoti svarÄ«ga.

Aptuveni Ŕādi mēs iedomājamies Service Mesh (Enterprise Service Mesh) korporatÄ«vo versiju. AprakstÄ«tā pielāgoÅ”ana atrisina lielāko daļu problēmu, kas rodas, mēģinot izmantot gatavās integrācijas platformas atvērtā pirmkoda versijas. Tikai pirms pāris gadiem ieviestā Service Mesh arhitektÅ«ra turpina attÄ«stÄ«ties, un mēs priecājamies, ka varam sniegt savu ieguldÄ«jumu tās attÄ«stÄ«bā. Mēs ceram, ka mÅ«su pieredze jums noderēs.

Avots: www.habr.com

Pievieno komentāru