Përshëndetje, Habr! Unë paraqes në vëmendjen tuaj një përkthim të artikullit autori Matt Klein.
Këtë herë, "dëshirova dhe përktheva" përshkrimin e të dy komponentëve të rrjetës së shërbimit, planit të të dhënave dhe planit të kontrollit. Ky përshkrim më dukej më i kuptueshëm dhe interesant, dhe më e rëndësishmja çoi në të kuptuarit e "A është fare e nevojshme?"
Ndërsa ideja e një "rrjete shërbimi" është bërë gjithnjë e më popullore gjatë dy viteve të fundit (Artikulli origjinal 10 tetor 2017) dhe numri i pjesëmarrësve në hapësirë është rritur, unë kam parë një rritje të përpjesshme të konfuzionit në të gjithë komuniteti teknologjik në lidhje me mënyrën se si të krahasohen dhe të krahasohen zgjidhjet e ndryshme.
Situata përmblidhet më së miri nga seria e mëposhtme e cicërimave që shkrova në korrik:
Konfuzioni i rrjetës së shërbimit #1: Linkerd ~ = Nginx ~ = Haproxy ~ = Dërguar. Asnjë prej tyre nuk është i barabartë me Istio. Istio është diçka krejtësisht ndryshe. 1 /
Të parat janë thjesht plane të dhënash. Vetë ata nuk bëjnë asgjë. Ata duhet të jenë në humor për diçka më shumë. 2/
Istio është një shembull i një rrafshi kontrolli që lidh pjesët së bashku. Kjo është një shtresë tjetër. /fund
Tweet-et e mëparshme përmendin disa projekte të ndryshme (Linkerd, NGINX, HAProxy, Envoy dhe Istio), por më e rëndësishmja prezantojnë konceptet e përgjithshme të planit të të dhënave, rrjetës së shërbimit dhe planit të kontrollit. Në këtë postim, unë do të bëj një hap prapa dhe do të flas për atë që dua të them me termat "avioni i të dhënave" dhe "avioni i kontrollit" në një nivel shumë të lartë, dhe më pas do të flas se si zbatohen termat për projektet e përmendura në tweet.
Çfarë është një rrjetë shërbimi, në të vërtetë?
Figura 1: Pasqyrë e përgjithshme e rrjetës së shërbimit
Figura 1 ilustron konceptin e rrjetës së shërbimit në nivelin më themelor. Ekzistojnë katër grupe shërbimesh (AD). Çdo shembull shërbimi është i lidhur me një server lokal proxy. I gjithë trafiku i rrjetit (HTTP, REST, gRPC, Redis, etj.) nga një shembull i vetëm aplikacioni kalohet përmes një përfaqësuesi lokal në grupet e duhura të shërbimeve të jashtme. Në këtë mënyrë, shembulli i aplikacionit nuk është në dijeni të rrjetit në tërësi dhe vetëm në dijeni të përfaqësuesit të tij lokal. Në fakt, rrjeti i sistemit të shpërndarë u hoq nga shërbimi.
Plani i të dhënave
Në një rrjetë shërbimi, një server proxy i vendosur lokalisht për aplikacionin kryen detyrat e mëposhtme:
- Zbulimi i shërbimit. Cilat shërbime/aplikacione janë të disponueshme për aplikacionin tuaj?
- Kontrolli i shëndetit. A janë rastet e shërbimit të kthyera nga zbulimi i shërbimit të shëndetshëm dhe të gatshëm për të pranuar trafikun e rrjetit? Kjo mund të përfshijë kontrolle shëndetësore aktive (p.sh. përgjigje/kontroll shëndetësor) dhe pasiv (p.sh. përdorimi i 3 gabimeve të njëpasnjëshme 5xx si tregues i një gjendjeje jo të shëndetshme të shërbimit).
- Drejtimi. Kur merrni një kërkesë për "/foo" nga një shërbim REST, cilit grup shërbimi duhet të dërgohet kërkesa?
- Balancimi i ngarkesës. Pasi të jetë zgjedhur një grup shërbimi gjatë rrugëtimit, në cilin instancë shërbimi duhet të dërgohet kërkesa? Me çfarë timeout? Me cilat cilësime të ndërprerjes së qarkut? Nëse kërkesa dështon, a duhet të riprovohet?
- Autentifikimi dhe autorizimi. Për kërkesat hyrëse, a mund të identifikohet/autorizohet kriptografikisht shërbimi i thirrjeve duke përdorur mTLS ose ndonjë mekanizëm tjetër? Nëse njihet/autorizohet, a lejohet thirrja e operacionit të kërkuar (pika fundore) në shërbim apo duhet të kthehet një përgjigje e paautenifikuar?
- Vëzhgueshmëria. Statistikat e detajuara, regjistrat/regjistrat dhe të dhënat e gjurmëve të shpërndara duhet të gjenerohen për secilën kërkesë në mënyrë që operatorët të kuptojnë rrjedhën e trafikut të shpërndarë dhe problemet e korrigjimit kur ato lindin.
Plani i të dhënave është përgjegjës për të gjitha pikat e mëparshme në rrjetën e shërbimit. Në fakt, përfaqësuesi lokal i shërbimit (anësor) është rrafshi i të dhënave. Me fjalë të tjera, plani i të dhënave është përgjegjës për transmetimin me kusht, përcjelljen dhe monitorimin e çdo pakete rrjeti që dërgohet në ose nga një shërbim.
Aeroplani i kontrollit
Abstraksioni i rrjetit që ofron një përfaqësues lokal në planin e të dhënave është magjik(?). Megjithatë, si e di në të vërtetë përfaqësuesi për rrugën "/foo" për në shërbimin B? Si mund të përdoren të dhënat e zbulimit të shërbimit që janë të mbushura me kërkesa për përfaqësues? Si janë konfiguruar parametrat për balancimin e ngarkesës, kohën e ndërprerjes, ndërprerjen e qarkut, etj.? Si e vendosni një aplikacion duke përdorur metodën blu/jeshile ose metodën e hijshme të tranzicionit të trafikut? Kush i konfiguron cilësimet e vërtetimit dhe autorizimit në të gjithë sistemin?
Të gjithë artikujt e mësipërm janë nën kontrollin e rrafshit të kontrollit të rrjetës së shërbimit. Avioni i kontrollit merr një grup përfaqësuesish të izoluar pa shtetësi dhe i kthen ato në një sistem të shpërndarë.
Mendoj se arsyeja pse shumë teknologë i shohin konceptet e veçanta të planit të të dhënave dhe planit të kontrollit të ngatërruar është sepse për shumicën e njerëzve rrafshi i të dhënave është i njohur ndërsa rrafshi i kontrollit është i huaj/i pakuptueshëm. Ne kemi punuar me ruterë dhe ndërprerës fizikë të rrjetit për një kohë të gjatë. Ne e kuptojmë se paketat/kërkesat duhet të kalojnë nga pika A në pikën B dhe se ne mund të përdorim harduer dhe softuer për ta bërë këtë. Gjenerata e re e proxy-ve të softuerit janë thjesht versione fantastike të mjeteve që kemi përdorur për një kohë të gjatë.
Figura 2: Aeroplani i kontrollit njerëzor
Megjithatë, ne kemi përdorur plane kontrolli për një kohë të gjatë, megjithëse shumica e operatorëve të rrjetit mund të mos e lidhin këtë pjesë të sistemit me ndonjë komponent teknologjik. Arsyeja është e thjeshtë:
Shumica e avionëve të kontrollit në përdorim sot jemi... ne.
Mbi Figura 2 tregon atë që unë e quaj "avioni i kontrollit njerëzor". Në këtë lloj vendosjeje, i cili është ende shumë i zakonshëm, një operator njerëzor me gjasë inatosur krijon konfigurime statike - potencialisht nëpërmjet skripteve - dhe i shpërndan ato përmes një procesi të veçantë për të gjithë përfaqësuesit. Më pas përfaqësuesit fillojnë të përdorin këtë konfigurim dhe fillojnë të përpunojnë planin e të dhënave duke përdorur cilësimet e përditësuara.
Figura 3: Plani i kontrollit të rrjetës së shërbimit të avancuar
Mbi Figura 3 tregon rrafshin e kontrollit “të zgjatur” të rrjetës së shërbimit. Ai përbëhet nga pjesët e mëposhtme:
- Njeri: Ka ende një person (shpresojmë më pak i zemëruar) që merr vendime të nivelit të lartë në lidhje me të gjithë sistemin në tërësi.
- UI rrafshi i kontrollit: Një person ndërvepron me një lloj ndërfaqeje përdoruesi për të kontrolluar sistemin. Ky mund të jetë një portal në internet, një aplikacion i linjës komanduese (CLI) ose ndonjë ndërfaqe tjetër. Duke përdorur ndërfaqen e përdoruesit, operatori ka akses në parametrat e konfigurimit global të sistemit si:
- Kontrolli i vendosjes, tranzicioni blu/jeshile dhe/ose gradual i trafikut
- Opsionet e vërtetimit dhe autorizimit
- Specifikimet e tabelës së rrugëtimit, për shembull kur aplikacioni A kërkon informacion për "/foo" çfarë ndodh
- Cilësimet e balancuesit të ngarkesës, të tilla si ndërprerjet, riprovimet, cilësimet e ndërprerjes së qarkut, etj.
- Programuesi i ngarkesës së punës: Shërbimet ekzekutohen në infrastrukturë përmes një lloj sistemi planifikimi/orkestrimi, si Kubernetes ose Nomad. Planifikuesi është përgjegjës për ngarkimin e shërbimit së bashku me përfaqësuesin e tij lokal.
- Zbulimi i shërbimit. Kur programuesi fillon dhe ndalon rastet e shërbimit, ai raporton gjendjen shëndetësore në sistemin e zbulimit të shërbimit.
- API-të e konfigurimit të përfaqësuesit anësor : Përfaqësuesit lokalë nxjerrin në mënyrë dinamike gjendjen nga komponentë të ndryshëm të sistemit duke përdorur një model përfundimisht të qëndrueshëm pa ndërhyrjen e operatorit. I gjithë sistemi, i përbërë nga të gjitha instancat aktuale të shërbimit dhe serverët lokalë proxy, përfundimisht konvergjon në një ekosistem. API i planit universal të të dhënave të Envoy është një shembull se si funksionon kjo në praktikë.
Në thelb, qëllimi i planit të kontrollit është të vendosë politikën që përfundimisht do të pranohet nga plani i të dhënave. Avionët më të avancuar të kontrollit do të heqin më shumë pjesë të disa sistemeve nga operatori dhe do të kërkojnë më pak funksionim manual, me kusht që të punojnë siç duhet!...
Plani i të dhënave dhe rrafshi i kontrollit. Përmbledhje e planit të të dhënave kundrejt planit të kontrollit
- Plani i të dhënave rrjetë i shërbimit: Ndikon në çdo paketë/kërkesë në sistem. Përgjegjës për zbulimin e aplikacionit/shërbimit, kontrollin shëndetësor, rrugëzimin, balancimin e ngarkesës, vërtetimin/autorizimin dhe vëzhgueshmërinë.
- Plani i kontrollit të rrjetës së shërbimit: Ofron politikën dhe konfigurimin për të gjitha planet e të dhënave që funksionojnë brenda rrjetit të shërbimit. Nuk prek asnjë paketë/kërkesë në sistem. Plani i kontrollit i kthen të gjitha planet e të dhënave në një sistem të shpërndarë.
Peizazhi aktual i projektit
Duke kuptuar shpjegimin e mësipërm, le të shohim gjendjen aktuale të projektit të rrjetës së shërbimit.
- Planet e të dhënave: Linkerd, NGINX, HAProxy, Envoy, Traefik
- Avionët e kontrollit: Istio, Nelson, SmartStack
Në vend që të shkoj në një analizë të thellë të secilës prej zgjidhjeve të mësipërme, unë do të trajtoj shkurtimisht disa nga pikat që besoj se po shkaktojnë shumë konfuzion në ekosistem tani.
Linkerd ishte një nga serverët e parë proxy të planit të të dhënave për rrjetën e shërbimit në fillim të vitit 2016 dhe ka bërë një punë fantastike për të rritur ndërgjegjësimin dhe vëmendjen ndaj modelit të dizajnit të rrjetës së shërbimit. Rreth 6 muaj pas kësaj, Envoy iu bashkua Linkerd (megjithëse ai kishte qenë me Lyft që nga fundi i 2015). Linkerd dhe Envoy janë dy projektet që përmenden më shpesh kur diskutohen rrjetat e shërbimit.
Istio u shpall në maj 2017. Qëllimet e projektit Istio janë shumë të ngjashme me planin e zgjeruar të kontrollit të paraqitur në Figura 3. I dërguari për Istio është përfaqësuesi i paracaktuar. Kështu, Istio është rrafshi i kontrollit, dhe Envoy është rrafshi i të dhënave. Në një kohë të shkurtër, Istio gjeneroi shumë eksitim dhe avionët e tjerë të të dhënave filluan të integrohen si një zëvendësim për Envoy (si Linkerd ashtu edhe NGINX demonstruan integrimin me Istio). Fakti që plane të ndryshme të të dhënave mund të përdoren brenda të njëjtit plan kontrolli do të thotë që rrafshi i kontrollit dhe plani i të dhënave nuk janë domosdoshmërisht të lidhur ngushtë. Një API si API gjenerike e të dhënave të Envoy mund të formojë një urë ndërmjet dy pjesëve të sistemit.
Nelson dhe SmartStack ndihmojnë në ilustrimin e mëtejshëm të ndarjes së planit të kontrollit dhe planit të të dhënave. Nelson përdor Envoy si përfaqësuesin e tij dhe ndërton një plan kontrolli të besueshëm për rrjetën e shërbimit bazuar në pirgun HashiCorp, d.m.th. Nomad etj. SmartStack ishte ndoshta i pari i një vale të re rrjetash shërbimi. SmartStack ndërton një plan kontrolli rreth HAProxy ose NGINX, duke demonstruar aftësinë për të shkëputur planin e kontrollit nga rrjeta e shërbimit nga rrafshi i të dhënave.
Arkitektura e mikroserviseve me rrjetë shërbimi po fiton gjithnjë e më shumë vëmendje (me të drejtë!), dhe gjithnjë e më shumë projekte dhe shitës po fillojnë të punojnë në këtë drejtim. Gjatë viteve të ardhshme do të shohim shumë risi si në planin e të dhënave ashtu edhe në atë të kontrollit, si dhe përzierje të mëtejshme të komponentëve të ndryshëm. Në fund të fundit, arkitektura e mikroshërbimit duhet të bëhet më transparente dhe magjike (?) për operatorin.
Shpresojmë gjithnjë e më pak të irrituar.
Marrëdhëniet kryesore
- Një rrjetë shërbimi përbëhet nga dy pjesë të ndryshme: plani i të dhënave dhe rrafshi i kontrollit. Të dy komponentët kërkohen, dhe pa to sistemi nuk do të funksionojë.
- Të gjithë janë të njohur me planin e kontrollit, dhe në këtë pikë, avioni i kontrollit mund të jeni ju!
- Të gjitha planet e të dhënave konkurrojnë me njëri-tjetrin për veçoritë, performancën, konfigurimin dhe shtrirjen.
- Të gjithë avionët e kontrollit konkurrojnë me njëri-tjetrin në veçoritë, konfigurimin, shtrirjen dhe lehtësinë e përdorimit.
- Një plan kontrolli mund të përmbajë abstraksionet dhe API-të e duhura në mënyrë që të mund të përdoren plane të shumta të dhënash.
Burimi: www.habr.com