Aplikazio monolitiko batetik mikrozerbitzuen arkitekturara pasatzen garen heinean, erronka berriei aurre egiten diegu.
Aplikazio monolitiko batean, normalean nahiko erraza da sistemaren zein zatitan gertatu den errorea zehaztea. Seguruenik, arazoa monolitoaren kodean bertan edo datu-basean dago. Baina mikrozerbitzuen arkitektura batean arazoren bat bilatzen hasten garenean, dena ez da hain agerikoa. Eskaerak hasieratik amaierara arte egin duen bide osoa aurkitu eta ehunka mikrozerbitzuetatik hautatu behar dugu. Gainera, horietako askok biltegiratze-instalazio propioak ere badituzte, akats logikoak ere sor ditzakete, baita errendimendu eta akatsen tolerantzia arazoak ere.
Aspalditik nabil horrelako arazoei aurre egiten lagunduko dien tresna baten bila (HabrΓ©-n idatzi nuen honi buruz: , ), baina azkenean kode irekiko irtenbide propioa egin nuen. Artikulu honetan zerbitzu sarearen ikuspegiaren abantailei buruz hitz egiten dut eta ezartzeko tresna berri bat partekatzen dut.
Banatutako trazadura sistema banatuetan akatsak aurkitzeko arazoari irtenbide arrunta da. Baina zer gertatzen da sare-interakzioei buruzko informazioa biltzeko ikuspegi hori oraindik sisteman ezarri ez bada, edo, okerrago, sistemaren zati batean jada behar bezala funtzionatzen badu, baina neurri batean ez, zerbitzu zaharretara gehitu ez denez? ? Arazo baten kausa zehatza zehazteko, beharrezkoa da sisteman gertatzen ari denaren irudi osoa izatea. Bereziki garrantzitsua da negozio-bide kritikoetan zein mikrozerbitzuk parte hartzen duten ulertzea.
Hemen zerbitzu-sarearen ikuspegia gure laguntza etor daiteke, sareko informazioa biltzeko makineria guztia zerbitzuek funtzionatzen duten baino maila baxuagoan landuko duena. Ikuspegi honi esker, trafiko guztia atzemateko eta hegan aztertzeko aukera dugu. Gainera, aplikazioek ez dute horri buruz ezer jakin behar.
Zerbitzu-sarearen hurbilketa
Zerbitzu-sarearen ikuspegiaren ideia nagusia sarean beste azpiegitura geruza bat gehitzea da, zerbitzuen arteko elkarrekintzarekin edozein gauza egiteko aukera emango diguna. Inplementazio gehienek honela funtzionatzen dute: proxy gardena duen sidecar edukiontzi gehigarri bat gehitzen zaio mikrozerbitzu bakoitzari, eta zerbitzuaren sarrerako eta irteerako trafiko guztia pasatzen da. Eta horixe da bezeroen balantzea egin, segurtasun politikak aplikatu, eskaera kopuruari murrizketak ezarri eta produkzioan zerbitzuen elkarrekintzari buruzko informazio garrantzitsua biltzeko.
Π Π΅ΡΠ΅Π½ΠΈΡ
Dagoeneko planteamendu honen hainbat inplementazio daude: ΠΈ . Ezaugarri asko eskaintzen dituzte kutxatik kanpo. Baina, aldi berean, baliabideen gainkostura handia dakar. Gainera, zenbat eta handiagoa izan sistema horrek funtzionatzen duen klusterra, orduan eta baliabide gehiago beharko dira azpiegitura berria mantentzeko. Avito-n, milaka zerbitzu-instantzia dituzten kubernetes klusterrak kudeatzen ditugu (eta haien kopurua azkar hazten jarraitzen du). Oraingo inplementazioan, Istio-k ~ 300 Mb RAM kontsumitzen ditu zerbitzu-instantzia bakoitzeko. Aukera kopuru handia dela eta, oreka gardenak zerbitzuen erantzun denbora orokorrari ere eragiten dio (10 ms-ra arte).
Ondorioz, oraintxe bertan behar genituen gaitasun zehatzak aztertu genituen, eta erabaki genuen soluzio horiek ezartzen hasi gineneko arrazoi nagusia sistema osoko trazadura-informazioa gardentasunez biltzeko gaitasuna zela. Zerbitzuen elkarrekintzaren kontrola ere izan nahi genuen eta hainbat manipulazio egin zerbitzuen artean transferitzen diren goiburuekin.
Ondorioz, gure erabakira iritsi ginen:β .
Netramesh
zerbitzu-sareko irtenbide arina da, infinitu eskalatzeko gaitasuna duena, sistemako zerbitzu kopurua edozein dela ere.
Soluzio berriaren helburu nagusiak baliabideen gainkostu txikia eta errendimendu handia ziren. Ezaugarri nagusietatik, berehala gure Jaeger sistemara trazadura-tarteak gardentasunez bidaltzeko gai izan nahi genuen.
Gaur egun, hodeiko irtenbide gehienak Golang-en ezartzen dira. Eta, noski, badira horretarako arrazoiak. I/O-rekin modu asinkronoan lan egiten duten eta nukleoen artean eskalatzen duten Golang-en sareko aplikazioak idaztea erosoa eta nahiko erraza da. Eta, gainera, oso garrantzitsua dena, errendimendua nahikoa da arazo hau konpontzeko. Horregatik, Golang ere aukeratu dugu.
produktibitatea
Gure ahaleginak produktibitate handiena lortzera bideratu ditugu. Zerbitzuaren instantzia bakoitzaren ondoan zabaltzen den irtenbide baterako, RAM eta CPU denboraren kontsumo txikia behar da. Eta, noski, erantzunaren atzerapenak ere txikia izan behar du.
Ea zer emaitza lortu ditugun.
RAM
Netramesh-ek ~10Mb kontsumitzen ditu trafikorik gabe eta 50Mb gehienez 10000 RPS-ko kargarekin instantzia bakoitzeko.
Istio envoy proxy-ak beti ~ 300 Mb kontsumitzen ditu milaka instantzia dituzten gure klusteretan. Horrek ez du onartzen kluster osora eskalatzea.
Netramesh-ekin memoria-kontsumoaren ~ 10 aldiz murriztea lortu dugu.
CPU
PUZaren erabilera nahiko berdina da kargapean. Alboko autorako denbora-unitate bakoitzeko eskaera kopuruaren araberakoa da. 3000 eskaera segundoko balioak gailurrean:
Puntu garrantzitsu bat gehiago dago: Netramesh - kontrol-planorik gabeko eta kargarik gabeko irtenbide batek ez du CPU denbora kontsumitzen. Istio-rekin, sidecar-ek beti eguneratzen dituzte zerbitzuaren amaiera-puntuak. Ondorioz, irudi hau kargarik gabe ikus dezakegu:
HTTP/1 erabiltzen dugu zerbitzuen arteko komunikaziorako. Istio-ren erantzun-denbora handitu zen envoy bidez proxy-a 5-10 ms-ra arte, hau da, milisegundo batean erantzuteko prest dauden zerbitzuetarako asko. Netramesh-ekin denbora hau 0.5-2 ms-ra jaitsi da.
Eskalagarritasuna
Proxy bakoitzak kontsumitzen duen baliabide txikiak zerbitzu bakoitzaren ondoan jartzea ahalbidetzen du. Netramesh nahita sortu zen kontrol-hegazkinaren osagairik gabe, sidecar bakoitza arin mantentzeko. Sarritan zerbitzu sareko soluzioetan, kontrol-hegazkinak zerbitzuaren aurkikuntzaren informazioa banatzen du sidecar bakoitzari. Horrekin batera denbora-muga eta orekatze ezarpenei buruzko informazioa dator. Horrek guztiak gauza erabilgarriak egiteko aukera ematen du, baina, zoritxarrez, alboko kotxeak tamainaz puzten ditu.
Zerbitzuaren aurkikuntza
Netramesh-ek ez du zerbitzuen aurkikuntzarako mekanismo gehigarririk gehitzen. Trafiko guztia proxy gardena da netra sidecar bidez.
Netramesh-ek HTTP/1 aplikazio-protokoloa onartzen du. Hori definitzeko, ataken zerrenda konfiguragarria erabiltzen da. Normalean, sistemak hainbat ataka ditu eta horien bidez HTTP komunikazioa gertatzen da. Adibidez, 80, 8890, 8080 erabiltzen ditugu zerbitzuen eta kanpoko eskaeren arteko elkarrekintzarako. Kasu honetan, ingurune-aldagai bat erabiliz ezar daitezke. NETRA_HTTP_PORTS.
Kubernetes orkestratzaile gisa eta bere Zerbitzu entitatearen mekanismoa erabiltzen badituzu zerbitzuen arteko kluster barruko komunikaziorako, orduan mekanismoak berdin jarraituko du. Lehenik eta behin, mikrozerbitzuak zerbitzuaren IP helbide bat lortzen du kube-dns erabiliz eta konexio berri bat irekitzen du. Konexio hau netra-sidecar lokalarekin ezartzen da lehenik eta TCP pakete guztiak hasieran netrara iristen dira. Ondoren, netra-sidecar-ek jatorrizko helmugarekin lotura bat ezartzen du. Nodoko pod IP-en NAT netrarik gabeko berdina izaten jarraitzen du.
Banatutako trazadura eta testuinguruaren birbidaltzea
Netramesh-ek HTTP interakzioei buruzko trazadura-tarteak bidaltzeko behar diren funtzionalitateak eskaintzen ditu. Netra-sidecar-ek HTTP protokoloa analizatzen du, eskaeraren atzerapenak neurtzen ditu eta HTTP goiburuetatik beharrezko informazioa ateratzen du. Azken batean, aztarna guztiak Jaeger sistema bakarrean lortzen ditugu. Konfigurazio zehatza egiteko, liburutegi ofizialak emandako ingurune-aldagaiak ere erabil ditzakezu .
Baina arazo bat dago. Zerbitzuek uber goiburu berezi bat sortu eta bidali arte, ez dugu sisteman konektatutako trazadura tarterik ikusiko. Eta hau da arazoen kausa azkar aurkitzeko behar duguna. Hemen berriro Netramesh-ek badu irtenbide bat. Proxiek HTTP goiburuak irakurtzen dituzte eta, uber traza IDrik ez badute, bat sortzen dute. Netramesh-ek sarrerako eta irteerako eskaerei buruzko informazioa ere gordetzen du sidecar batean eta parekatzen ditu beharrezko irteerako eskaeren goiburuekin aberastuz. Zerbitzuetan egin behar duzun guztia goiburu bakarra bidaltzea da X-Request-Id, ingurune-aldagai bat erabiliz konfigura daitekeena NETRA_HTTP_REQUEST_ID_HEADER_NAME. Netramesh-en testuinguruaren tamaina kontrolatzeko, ingurune-aldagai hauek ezar ditzakezu: NETRA_TRACING_CONTEXT_EXPIRATION_MILLISECONDS (testuingurua gordeko den denbora) eta NETRA_TRACING_CONTEXT_CLEANUP_INTERVAL (testuinguruaren garbiketaren maiztasuna).
Zure sisteman hainbat bide konbinatu ere posible da saio-token berezi batekin markatuz. Netra-k instalatzeko aukera ematen dizu HTTP_HEADER_TAG_MAP HTTP goiburuak dagozkien trazadura-tarte etiketa bihurtzeko. Hau bereziki erabilgarria izan daiteke probak egiteko. Proba funtzionala gainditu ondoren, sistemaren zein zatiri eragin dion ikus dezakezu dagokion saio-gakoaren bidez iragaziz.
Eskaeraren iturria zehaztea
Eskaera nondik datorren zehazteko, iturburuarekin goiburua automatikoki gehitzeko funtzionalitatea erabil dezakezu. Inguruko aldagai bat erabiliz NETRA_HTTP_X_SOURCE_HEADER_NAME Automatikoki instalatuko den goiburuko izena zehaztu dezakezu. Erabiliz NETRA_HTTP_X_SOURCE_VALUE X-Source goiburua irteerako eskaera guztietan ezarriko den balioa ezar dezakezu.
Horri esker, goiburu erabilgarri honen banaketa uniformeki banatu daiteke sarean. Ondoren, zerbitzuetan erabil dezakezu eta erregistro eta metriketan gehi dezakezu.
Trafiko bideratzea eta Netramesh barnekoak
Netramesh-ek bi osagai nagusi ditu. Lehenengoak, netra-init, sareko arauak ezartzen ditu trafikoa atzemateko. Erabiltzen du sidecar-eko trafiko osoa edo zati bat atzematea, Netramesh-en bigarren osagai nagusia baita. Sarrerako eta irteerako TCP saioetarako zein ataka atzeman behar diren konfigura dezakezu: INBOUND_INTERCEPT_PORTS, OUTBOUND_INTERCEPT_PORTS.
Tresnak ezaugarri interesgarri bat ere badu - bideratze probabilista. Netramesh trazadura-tarteak biltzeko soilik erabiltzen baduzu, ekoizpen-ingurunean baliabideak aurreztu eta bideratze probabilista gaitu aldagaiak erabiliz. NETRA_INBOUND_PROBABILITY ΠΈ NETRA_OUTBOUND_PROBABILITY (0tik 1era). Balio lehenetsia 1 da (trafiko guztia atzematen da).
Harrapaketa arrakastatsuaren ondoren, netra sidecar-ek konexio eta erabilera berriak onartzen ditu SO_ORIGINAL_DST socket aukera jatorrizko helmuga lortzeko. Ondoren, Netra-k konexio berri bat irekiko du jatorrizko IP helbidera eta bi norabideko TCP komunikazioa ezartzen du alderdien artean, pasatzen den trafiko guztia entzunez. Portua HTTP gisa definitzen bada, Netra hura analizatzen eta trazatzen saiatzen da. HTTP analizatzeak huts egiten badu, Netra TCPra erortzen da eta byteak gardentasunez proxy egiten ditu.
Mendekotasun grafikoa eraikitzea
Jaeger-en trazadura-informazio ugari jaso ondoren, sistemako interakzioen grafiko osoa lortu nahi dut. Baina zure sistema nahiko kargatuta badago eta egunean milaka milioi trazadura-tarte pilatzen badira, horiek batzea ez da hain lan erraza bihurtzen. Horretarako modu ofizial bat dago: . Hala ere, orduak beharko dira grafiko osoa eraikitzeko eta azken XNUMX orduetan Jaeger-en datu-multzo osoa deskargatzera behartuko zaitu.
Elasticsearch erabiltzen ari bazara trazadura-tarteak gordetzeko, erabil dezakezu , grafiko bera minututan eraikiko duena Elasticsearch-en ezaugarriak eta gaitasunak erabiliz.
Nola erabili Netramesh
Netra erraz gehi daiteke edozein orkestratzaile exekutatzen duen edozein zerbitzutan. Adibide bat ikus dezakezu .
Momentuz, Netrak ez du zerbitzuetarako sidecar-ak automatikoki ezartzeko gaitasunik, baina ezartzeko planak daude.
Netramesh-en etorkizuna
helburu nagusia Baliabideen kostu minimoak eta errendimendu handia lortzea da, zerbitzuen arteko komunikazioaren behagarritasuna eta kontrolatzeko oinarrizko gaitasunak eskainiz.
Etorkizunean, Netramesh-ek HTTP gain beste aplikazio-geruzako protokolo batzuk onartuko ditu. L7 bideratzea eskuragarri egongo da etorkizun hurbilean.
Erabili Netramesh antzeko arazoak aurkitzen badituzu eta idatzi iezaguzu galdera eta iradokizunekin.
Iturria: www.habr.com