Pse po bëjmë Enterprise Service Mesh?

Service Mesh është një model arkitekturor i njohur për integrimin e mikroshërbimeve dhe migrimin në infrastrukturën cloud. Sot në botën e kontejnerëve të reve është mjaft e vështirë të bësh pa të. Disa implementime rrjete shërbimi me burim të hapur janë tashmë të disponueshme në treg, por funksionaliteti, besueshmëria dhe siguria e tyre nuk janë gjithmonë të mjaftueshme, veçanërisht kur bëhet fjalë për kërkesat e kompanive të mëdha financiare në të gjithë vendin. Kjo është arsyeja pse ne në Sbertech vendosëm të personalizojmë Service Mesh dhe duam të flasim për atë që është interesante për Service Mesh, çfarë nuk është aq interesante dhe çfarë do të bëjmë për të.

Pse po bëjmë Enterprise Service Mesh?

Popullariteti i modelit Service Mesh po rritet me popullaritetin e teknologjive cloud. Është një shtresë e dedikuar infrastrukture që thjeshton ndërveprimin midis shërbimeve të ndryshme të rrjetit. Aplikacionet moderne cloud përbëhen nga qindra apo edhe mijëra shërbime të tilla, secila prej të cilave mund të ketë mijëra kopje.

Pse po bëjmë Enterprise Service Mesh?

Ndërveprimi ndërmjet dhe menaxhimi i këtyre shërbimeve është një detyrë kyçe e Service Mesh. Në fakt, ky është një model rrjeti i shumë proxies, i menaxhuar në mënyrë qendrore dhe që kryen një sërë funksionesh shumë të dobishme.

Në nivelin e përfaqësuesit (rrafshi i të dhënave):

  • Caktimi dhe shpërndarja e politikave të rrugëzimit dhe balancimit të trafikut
  • Shpërndarja e çelësave, certifikatave, shenjave
  • Koleksioni i telemetrisë, gjenerimi i metrikave monitoruese
  • Integrimi me infrastrukturën e sigurisë dhe monitorimit

Në nivelin e planit të kontrollit:

  • Zbatimi i politikave të rrugëzimit dhe balancimit të trafikut
  • Menaxhimi i riprovave dhe afateve, zbulimi i nyjeve "të vdekura" (ndërprerja e qarkut), menaxhimi i gabimeve të injektimit dhe sigurimi i qëndrueshmërisë së shërbimit përmes mekanizmave të tjerë
  • Vërtetimi/autorizimi i thirrjeve
  • Metrikat e rënies (vëzhgueshmëria)

Gama e përdoruesve të interesuar për zhvillimin e kësaj teknologjie është shumë e gjerë - nga startup-et e vogla deri te korporatat e mëdha të internetit, për shembull, PayPal.

Pse nevojitet Service Mesh në sektorin e korporatave?

Ka shumë përfitime të qarta për të përdorur një rrjetë shërbimi. Para së gjithash, është thjesht i përshtatshëm për zhvilluesit: për të shkruar kodin shfaqet një platformë teknologjike, e cila thjeshton ndjeshëm integrimin në infrastrukturën cloud për faktin se shtresa e transportit është plotësisht e izoluar nga logjika e aplikacionit.

Përveç kësaj, Service Mesh thjeshton marrëdhëniet midis furnitorëve dhe konsumatorëve. Sot, është shumë më e lehtë për ofruesit dhe konsumatorët e API të bien dakord për ndërfaqet dhe kontratat vetë, pa përfshirë një ndërmjetës dhe arbitr të veçantë integrimi - autobusin e shërbimit të ndërmarrjes. Kjo qasje ndikon ndjeshëm në dy tregues. Shpejtësia e sjelljes së funksionalitetit të ri në treg (time-to-market) rritet, por në të njëjtën kohë rritet kostoja e zgjidhjes, pasi integrimi duhet të bëhet në mënyrë të pavarur. Përdorimi i Service Mesh nga ekipet e zhvillimit të funksionalitetit të biznesit ndihmon në ruajtjen e një ekuilibri këtu. Si rezultat, ofruesit e API mund të fokusohen ekskluzivisht në komponentin e aplikacionit të shërbimit të tyre dhe thjesht ta publikojnë atë në Rrjetin e Shërbimit - API do të bëhet menjëherë i disponueshëm për të gjithë klientët dhe cilësia e integrimit do të jetë gati për prodhimin dhe nuk do të kërkojë një të vetme rreshti i kodit shtesë.

Avantazhi tjetër është se zhvilluesi, duke përdorur Service Mesh, fokusohet vetëm në funksionalitetin e biznesit — mbi produktin dhe jo komponentin teknologjik të shërbimit të tij. Për shembull, nuk duhet të mendoni më për faktin se në një situatë kur një shërbim thirret përmes rrjetit, diku mund të ndodhë një dështim i lidhjes. Përveç kësaj, Service Mesh ndihmon në balancimin e trafikut midis kopjeve të të njëjtit shërbim: nëse një nga kopjet "vdes", sistemi do të kalojë të gjithë trafikun në kopjet e mbetura të drejtpërdrejta.

Rrjetë e shërbimit - kjo është një bazë e mirë për krijimin e aplikacioneve të shpërndara, i cili fsheh nga klienti detajet e ofrimit të thirrjeve në shërbimet e tij si brenda ashtu edhe jashtë. Të gjitha aplikacionet që përdorin Service Mesh janë të izoluara në nivelin e transportit si nga rrjeti ashtu edhe nga njëri-tjetri: nuk ka asnjë komunikim midis tyre. Në këtë rast, zhvilluesi merr kontroll të plotë mbi shërbimet e tij.

Duhet theksuar se Përditësimi i aplikacioneve të shpërndara në një mjedis rrjetë shërbimi bëhet më i lehtë. Për shembull, një vendosje blu/jeshile, në të cilën dy mjedise aplikacioni janë të disponueshme për instalim, njëri prej të cilëve nuk është përditësuar dhe është në modalitetin e gatishmërisë. Kthimi në versionin e mëparshëm në rast të një lëshimi të pasuksesshëm kryhet nga një ruter special, roli i të cilit Service Mesh përballet mirë me. Për të testuar versionin e ri, mund të përdorni lëshimi i kanarinës — kaloni në versionin e ri vetëm 10% të trafikut ose kërkesave nga një grup pilot klientësh. Trafiku kryesor shkon në versionin e vjetër, asgjë nuk prishet.

Edhe Service Mesh na jep kontrollin SLA në kohë reale. Sistemi proxy i shpërndarë nuk do të lejojë që shërbimi të dështojë kur njëri nga klientët tejkalon kuotën e caktuar për të. Nëse xhiroja e API është e kufizuar, askush nuk do të jetë në gjendje ta mbingarkojë atë me një numër të madh transaksionesh: Rrjeta e Shërbimit qëndron përpara shërbimit dhe nuk lejon trafik të panevojshëm. Ai thjesht do të luftojë në shtresën e integrimit dhe vetë shërbimet do të vazhdojnë të punojnë pa e vënë re.

Nëse një kompani dëshiron të reduktojë kostot për zhvillimin e zgjidhjeve të integrimit, Service Mesh gjithashtu ndihmon: Mund të kaloni në versionin e tij me burim të hapur nga produktet komerciale. Enterprise Service Mesh-i ynë bazohet në versionin me burim të hapur të Service Mesh.

Një avantazh tjetër - disponueshmëria e një grupi të vetëm të plotë të shërbimeve të integrimit. Për shkak se i gjithë integrimi ndërtohet përmes këtij programi ndërmjetës, ne mund të menaxhojmë të gjithë trafikun e integrimit dhe lidhjet midis aplikacioneve që formojnë thelbin e biznesit të kompanisë. Është shumë komode.

Dhe në fund Service Mesh inkurajon një kompani të kalojë në një infrastrukturë dinamike. Tani shumë janë duke kërkuar drejt kontejnerizimit. Prerja e një monolit në mikroshërbime, zbatimi i bukur i gjithë kësaj - tema është në rritje. Por kur përpiqeni të transferoni një sistem që ka qenë në prodhim për shumë vite në një platformë të re, menjëherë hasni një sërë problemesh: ta shtyni të gjithë në kontejnerë dhe ta vendosni në platformë nuk është e lehtë. Dhe zbatimi, sinkronizimi dhe ndërveprimi i këtyre komponentëve të shpërndarë është një tjetër temë shumë komplekse. Si do të komunikojnë me njëri-tjetrin? A do të ketë dështime në kaskadë? Shërbimi Mesh ju lejon të zgjidhni disa nga këto probleme dhe të lehtësoni migrimin nga arkitektura e vjetër në atë të re për shkak të faktit se mund të harroni logjikën e shkëmbimit të rrjetit.

Pse ju nevojitet personalizimi i rrjetës së shërbimit?

Në kompaninë tonë, qindra sisteme dhe module bashkëjetojnë, dhe koha e funksionimit është shumë e ngarkuar. Pra, një model i thjeshtë i një sistemi që thërret një tjetër dhe merr një përgjigje nuk mjafton, sepse në prodhim duam më shumë. Çfarë tjetër ju nevojitet nga rrjeta e shërbimit të ndërmarrjes?

Pse po bëjmë Enterprise Service Mesh?

Shërbimi i përpunimit të ngjarjeve

Le të imagjinojmë se duhet të bëjmë përpunimin e ngjarjeve në kohë reale - një sistem që analizon veprimet e klientit në kohë reale dhe mund t'i bëjë menjëherë një ofertë përkatëse. Për të zbatuar funksione të ngjashme, përdorni modeli arkitektonik i quajtur arkitekturë e drejtuar nga ngjarjet (EDA). Asnjë nga rrjetat aktuale të shërbimit nuk mbështet modele të tilla, por kjo është shumë e rëndësishme, veçanërisht për një bankë!

Është mjaft e çuditshme që Thirrja e Procedurës në distancë (RPC) mbështetet nga të gjitha versionet e Service Mesh, por ato nuk janë miqësore me EDA. Sepse Service Mesh është një lloj integrimi modern i shpërndarë dhe EDA është një model arkitekturor shumë i rëndësishëm që ju lejon të bëni gjëra unike për sa i përket përvojës së klientit.

Rrjeta jonë e shërbimit të ndërmarrjes duhet ta zgjidhë këtë problem. Për më tepër, ne duam të shohim në të zbatimin e shpërndarjes së garantuar, transmetimit dhe përpunimit kompleks të ngjarjeve duke përdorur një sërë filtrash dhe shabllonesh.

Shërbimi i transferimit të skedarëve

Përveç EDA-s, do të ishte mirë që të mund të transferonit skedarë: në një shkallë Enterprise, shumë shpesh është i mundur vetëm integrimi i skedarëve. Në veçanti, përdoret modeli arkitektonik ETL (Extract, Transform, Load). Në të, si rregull, të gjithë shkëmbejnë skedarë ekskluzivisht: përdoren të dhëna të mëdha, gjë që është jopraktike për të shtyrë kërkesa të veçanta. Aftësia për të mbështetur transferimet e skedarëve në mënyrë origjinale në Enterprise Service Mesh ju jep fleksibilitetin që i nevojitet biznesit tuaj.

Shërbim orkestrimi

Organizatat e mëdha pothuajse gjithmonë kanë ekipe të ndryshme që prodhojnë produkte të ndryshme. Për shembull, në një bankë, disa ekipe punojnë me depozita, ndërsa të tjerat punojnë me produkte kredie dhe raste të tilla ka mjaft. Këta janë njerëz të ndryshëm, ekipe të ndryshme që bëjnë produktet e tyre, zhvillojnë API-të e tyre dhe ua ofrojnë të tjerëve. Dhe shumë shpesh ekziston nevoja për të hartuar këto shërbime, si dhe për të zbatuar logjikë komplekse për thirrjen sekuenciale të një grupi API. Për të zgjidhur këtë problem, ju duhet një zgjidhje në shtresën e integrimit që do të thjeshtojë gjithë këtë logjikë të përbërë (thirrja e disa API-ve, përshkrimi i rrugës së kërkesës, etj.). Ky është shërbimi i orkestrimit në Enterprise Service Mesh.

AI dhe ML

Kur mikroshërbimet komunikojnë përmes një shtrese të vetme integrimi, Rrjeta e Shërbimit natyrshëm di gjithçka për thirrjet e secilit shërbim. Ne mbledhim telemetrinë: kush e thirri kë, kur, për sa kohë, sa herë, e kështu me radhë. Kur ka qindra mijëra shërbime të tilla dhe miliarda thirrje, atëherë e gjithë kjo grumbullohet dhe formon Big Data. Këto të dhëna mund të analizohen duke përdorur AI, mësimin e makinerive, etj., dhe më pas mund të bëhen disa gjëra të dobishme bazuar në rezultatet e analizës. Do të ishte e përshtatshme që të paktën pjesërisht t'i dorëzohej inteligjencës artificiale kontrolli i të gjithë këtij trafiku në rrjet dhe thirrje aplikacionesh të integruara në Service Mesh.

Shërbimi i portës API

Në mënyrë tipike, një rrjetë shërbimi ka përfaqësues dhe shërbime që flasin me njëri-tjetrin brenda një perimetri të besuar. Por ka edhe palë të jashtme. Kërkesat për API-të e ekspozuara ndaj këtij grupi të konsumatorëve janë shumë më të rënda. Ne e ndajmë këtë detyrë në dy pjesë kryesore.

  • siguri. Çështje që lidhen me ddos, cenueshmëria e protokolleve, aplikacioneve, sistemeve operative etj.
  • Shkalla. Kur numri i API-ve që duhet t'u shërbehen klientëve shkon në mijëra apo edhe qindra mijëra, ekziston nevoja për një lloj mjeti menaxhimi për këtë grup API-sh. Ju duhet të monitoroni vazhdimisht API-në: nëse ata janë duke punuar apo jo, cili është statusi i tyre, çfarë trafiku po rrjedh, çfarë statistikash, etj. Një portë API duhet të trajtojë këtë detyrë duke e bërë të gjithë procesin të menaxhueshëm dhe të sigurt. Falë këtij komponenti, Enterprise Service Mesh mëson të publikojë lehtësisht API-të e brendshme dhe të jashtme.

Shërbimi mbështetës për protokolle dhe formate të veçanta të të dhënave (AS gateway)

Aktualisht, shumica e zgjidhjeve Service Mesh mund të funksionojnë në mënyrë origjinale vetëm me trafikun HTTP dhe HTTP2 ose në një modalitet të reduktuar në nivelin TCP/IP. Enterprise Service Mesh po shfaqet me shumë protokolle të tjera shumë specifike të transferimit të të dhënave. Disa sisteme mund të përdorin ndërmjetës mesazhesh, të tjerët janë të integruar në nivelin e bazës së të dhënave. Nëse kompania ka SAP, atëherë mund të përdorë edhe sistemin e saj të integrimit. Për më tepër, e gjithë kjo funksionon dhe është një pjesë e rëndësishme e biznesit.

Nuk mund të thuash thjesht: "Le të braktisim trashëgiminë dhe të krijojmë sisteme të reja që mund të përdorin Service Mesh". Për të lidhur të gjitha sistemet e vjetra me ato të reja (në një arkitekturë mikroservice), sistemet që mund të përdorin Service Mesh do të kenë nevojë për një lloj përshtatësi, ndërmjetës, portë. Dakord, do të ishte mirë nëse do të vinte në një kuti së bashku me shërbimin. Porta AC mund të mbështesë çdo opsion integrimi. Vetëm imagjinoni, thjesht instaloni Enterprise Service Mesh dhe është gati të ndërveprojë me të gjitha protokollet që ju nevojiten. Kjo qasje është shumë e rëndësishme për ne.

Kjo është afërsisht se si ne e imagjinojmë versionin e korporatës të Service Mesh (Enterprise Service Mesh). Përshtatja e përshkruar zgjidh shumicën e problemeve që lindin kur përpiqeni të përdorni versione të gatshme me burim të hapur të platformës së integrimit. E prezantuar vetëm disa vjet më parë, arkitektura Service Mesh vazhdon të evoluojë dhe ne jemi të ngazëllyer që mund të kontribuojmë në zhvillimin e saj. Shpresojmë që përvoja jonë të jetë e dobishme për ju.

Burimi: www.habr.com

Shto një koment