Ndërsa kalojmë nga një aplikim monolit në një arkitekturë mikroshërbimesh, ne përballemi me sfida të reja.
Në një aplikacion monolit, zakonisht është mjaft e lehtë të përcaktohet se në cilën pjesë të sistemit ka ndodhur gabimi. Me shumë mundësi, problemi është në kodin e vetë monolitit, ose në bazën e të dhënave. Por kur fillojmë të kërkojmë një problem në një arkitekturë mikroservice, gjithçka nuk është më aq e dukshme. Duhet të gjejmë të gjithë rrugën që kërkoi nga fillimi në fund dhe ta zgjedhim atë nga qindra mikroshërbime. Për më tepër, shumë prej tyre kanë edhe objektet e tyre të ruajtjes, të cilat gjithashtu mund të shkaktojnë gabime logjike, si dhe probleme me performancën dhe tolerancën e gabimeve.
Unë kam qenë duke kërkuar për një kohë të gjatë për një mjet që do të ndihmonte në përballimin e problemeve të tilla (kam shkruar për këtë në Habré: , ), por në fund bëra zgjidhjen time me burim të hapur. Në këtë artikull unë flas për përfitimet e qasjes së rrjetës së shërbimit dhe ndaj një mjet të ri për zbatimin e tij.
Gjurmimi i shpërndarë është një zgjidhje e zakonshme për problemin e gjetjes së gabimeve në sistemet e shpërndara. Por çfarë nëse kjo qasje për mbledhjen e informacionit në lidhje me ndërveprimet e rrjetit nuk është zbatuar ende në sistem, ose, më keq, në një pjesë të sistemit tashmë funksionon siç duhet, por pjesërisht jo, pasi nuk është shtuar në shërbimet e vjetra ? Për të përcaktuar shkakun e saktë rrënjësor të një problemi, është e nevojshme të keni një pamje të plotë të asaj që po ndodh në sistem. Është veçanërisht e rëndësishme të kuptohet se cilat mikroshërbime janë të përfshira në shtigjet kryesore kritike të biznesit.
Këtu mund të na vijë në ndihmë qasja e rrjetës së shërbimit, e cila do të merret me të gjitha makineritë për mbledhjen e informacionit të rrjetit në një nivel më të ulët se sa funksionojnë vetë shërbimet. Kjo qasje na lejon të përgjojmë të gjithë trafikun dhe ta analizojmë atë në fluturim. Për më tepër, aplikacionet as nuk duhet të dinë asgjë për të.
Qasja e rrjetës së shërbimit
Ideja kryesore e qasjes së rrjetës së shërbimit është të shtojmë një shtresë tjetër infrastrukture mbi rrjetin, e cila do të na lejojë të bëjmë çdo gjë me ndërveprimin ndër-shërbues. Shumica e implementimeve funksionojnë si më poshtë: një kontejner shtesë i karriges anësore me një përfaqësues transparent i shtohet çdo mikroservice, përmes të cilit kalohet i gjithë trafiku hyrës dhe dalës i shërbimit. Dhe ky është pikërisht vendi ku ne mund të bëjmë balancimin e klientëve, të aplikojmë politika sigurie, të vendosim kufizime në numrin e kërkesave dhe të mbledhim informacione të rëndësishme për ndërveprimin e shërbimeve në prodhim.
Zgjidhjet
Tashmë ka disa zbatime të kësaj qasjeje: и . Ato ofrojnë shumë veçori jashtë kutisë. Por në të njëjtën kohë, ka një shpenzim të madh mbi burimet. Për më tepër, sa më i madh të jetë grupi në të cilin funksionon një sistem i tillë, aq më shumë burime do të kërkohen për të mirëmbajtur infrastrukturën e re. Në Avito, ne operojmë grupe kubernetes që përmbajnë mijëra raste shërbimi (dhe numri i tyre vazhdon të rritet me shpejtësi). Në zbatimin e tij aktual, Istio konsumon ~ 300 Mb RAM për shembull shërbimi. Për shkak të numrit të madh të mundësive, balancimi transparent ndikon edhe në kohën e përgjithshme të përgjigjes së shërbimeve (deri në 10ms).
Si rezultat, ne shikuam saktësisht se cilat aftësi na duheshin tani dhe vendosëm se arsyeja kryesore pse filluam të zbatonim zgjidhje të tilla ishte aftësia për të mbledhur informacione gjurmuese nga i gjithë sistemi në mënyrë transparente. Ne kemi dashur gjithashtu të kemi kontroll mbi ndërveprimin e shërbimeve dhe të bëjmë manipulime të ndryshme me titujt që transferohen ndërmjet shërbimeve.
Si rezultat, ne arritëm në vendimin tonë: .
Netramesh
është një zgjidhje e lehtë rrjetë shërbimi me aftësinë për të shkallëzuar pafundësisht, pavarësisht nga numri i shërbimeve në sistem.
Qëllimet kryesore të zgjidhjes së re ishin shpenzimet e ulëta të burimeve dhe performanca e lartë. Ndër veçoritë kryesore, ne menjëherë donim të ishim në gjendje të dërgonim në mënyrë transparente hapësirat e gjurmimit në sistemin tonë Jaeger.
Sot, shumica e zgjidhjeve cloud zbatohen në Golang. Dhe, sigurisht, ka arsye për këtë. Shkrimi i aplikacioneve të rrjetit në Golang që funksionojnë në mënyrë asinkrone me I/O dhe shkallëzohen nëpër bërthama sipas nevojës është i përshtatshëm dhe mjaft i thjeshtë. Dhe, ajo që është gjithashtu shumë e rëndësishme, performanca është e mjaftueshme për të zgjidhur këtë problem. Kjo është arsyeja pse ne zgjodhëm edhe Golang.
prodhimtari
Ne i kemi fokusuar përpjekjet tona në arritjen e produktivitetit maksimal. Për një zgjidhje që vendoset pranë çdo shembulli të shërbimit, kërkohet një konsum i vogël i kohës së RAM dhe CPU. Dhe, sigurisht, edhe vonesa e përgjigjes duhet të jetë e vogël.
Le të shohim se çfarë rezultatesh kemi marrë.
RAM
Netramesh konsumon ~ 10 Mb pa trafik dhe 50 Mb maksimum me një ngarkesë deri në 10000 RPS për shembull.
Proxy i dërguar i Istio gjithmonë konsumon ~ 300 Mb në grupet tona me mijëra raste. Kjo nuk lejon që ajo të shkallëzohet në të gjithë grupin.
Me Netramesh kemi një reduktim ~ 10x në konsumin e memories.
CPU
Përdorimi i CPU-së është relativisht i barabartë nën ngarkesë. Varet nga numri i kërkesave për njësi të kohës për karrocën anësore. Vlerat në 3000 kërkesa për sekondë në kulmin:
Ekziston një pikë më e rëndësishme: Netramesh - një zgjidhje pa një plan kontrolli dhe pa ngarkesë nuk konsumon kohën e CPU. Me Istio, karriget anësore përditësojnë gjithmonë pikat fundore të shërbimit. Si rezultat, ne mund ta shohim këtë foto pa ngarkesë:
Ne përdorim HTTP/1 për komunikim ndërmjet shërbimeve. Rritja e kohës së përgjigjes për Istio kur proxying përmes të dërguarit ishte deri në 5-10ms, që është mjaft e madhe për shërbimet që janë gati të përgjigjen në një milisekondë. Me Netramesh kjo kohë është ulur në 0.5-2ms.
Shkallëzueshmëria
Sasia e vogël e burimeve të konsumuara nga çdo proxy bën të mundur vendosjen e tij pranë çdo shërbimi. Netramesh u krijua qëllimisht pa një komponent të aeroplanit të kontrollit për të mbajtur thjesht peshën e lehtë të çdo karrige anësore. Shpesh në zgjidhjet e rrjetës së shërbimit, rrafshi i kontrollit shpërndan informacionin e zbulimit të shërbimit në çdo karrige anësore. Së bashku me të vijnë informacione për afatet dhe cilësimet e balancimit. E gjithë kjo ju lejon të bëni shumë gjëra të dobishme, por, për fat të keq, i fryn karriget anësore në madhësi.
Zbulimi i shërbimit
Netramesh nuk shton asnjë mekanizëm shtesë për zbulimin e shërbimit. I gjithë trafiku kryhet në mënyrë transparente përmes karriges anësore netra.
Netramesh mbështet protokollin e aplikacionit HTTP/1. Për ta përcaktuar atë, përdoret një listë e konfigurueshme portash. Në mënyrë tipike, sistemi ka disa porte përmes të cilave ndodh komunikimi HTTP. Për shembull, ne përdorim 80, 8890, 8080 për ndërveprimin midis shërbimeve dhe kërkesave të jashtme. Në këtë rast, ato mund të vendosen duke përdorur një variabël mjedisi NETRA_HTTP_PORTS.
Nëse përdorni Kubernetes si orkestrues dhe mekanizmin e tij të entitetit të Shërbimit për komunikimin brenda grupit midis shërbimeve, atëherë mekanizmi mbetet saktësisht i njëjtë. Së pari, mikroshërbimi merr një adresë IP shërbimi duke përdorur kube-dns dhe hap një lidhje të re me të. Kjo lidhje vendoset fillimisht me netra-sidecar lokal dhe të gjitha paketat TCP fillimisht arrijnë në netra. Më pas, netra-sidecar vendos një lidhje me destinacionin origjinal. NAT në pod IP në nyje mbetet saktësisht i njëjtë si pa netra.
Gjurmimi i shpërndarë dhe përcjellja e kontekstit
Netramesh ofron funksionalitetin e nevojshëm për të dërguar hapësira gjurmuese rreth ndërveprimeve HTTP. Netra-sidecar analizon protokollin HTTP, mat vonesat e kërkesave dhe nxjerr informacionin e nevojshëm nga titujt HTTP. Në fund të fundit, ne marrim të gjitha gjurmët në një sistem të vetëm Jaeger. Për konfigurim të imët, mund të përdorni gjithashtu variablat e mjedisit të ofruara nga biblioteka zyrtare .
Por ka një problem. Derisa shërbimet të krijojnë dhe dërgojnë një kokë të veçantë uber, ne nuk do të shohim hapësira të lidhura të gjurmimit në sistem. Dhe kjo është ajo që na duhet për të gjetur shpejt shkakun e problemeve. Edhe këtu Netramesh ka një zgjidhje. Proxies lexojnë titujt HTTP dhe, nëse nuk përmbajnë ID-në e gjurmës uber, gjenerojnë një të tillë. Netramesh ruan gjithashtu informacione në lidhje me kërkesat hyrëse dhe dalëse në një karrige anësore dhe i përputh ato duke i pasuruar me titujt e nevojshëm të kërkesave dalëse. Gjithçka që duhet të bëni në shërbime është të dërgoni vetëm një kokë X-Request-Id, i cili mund të konfigurohet duke përdorur një variabël mjedisi NETRA_HTTP_REQUEST_ID_HEADER_NAME. Për të kontrolluar madhësinë e kontekstit në Netramesh, mund të vendosni variablat e mjedisit të mëposhtëm: NETRA_TRACING_CONTEXT_EXPIRATION_MILLISECONDS (koha për të cilën do të ruhet konteksti) dhe NETRA_TRACING_CONTEXT_CLEANUP_INTERVAL (frekuenca e pastrimit të kontekstit).
Është gjithashtu e mundur të kombinoni shtigje të shumta në sistemin tuaj duke i shënuar ato me një shenjë të veçantë sesioni. Netra ju lejon të instaloni HTTP_HEADER_TAG_MAP për të kthyer titujt HTTP në etiketat përkatëse të hapësirës gjurmuese. Kjo mund të jetë veçanërisht e dobishme për testim. Pasi të keni kaluar testin funksional, mund të shihni se cila pjesë e sistemit është prekur nga filtrimi nga çelësi përkatës i sesionit.
Përcaktimi i burimit të kërkesës
Për të përcaktuar se nga erdhi kërkesa, mund të përdorni funksionalitetin e shtimit automatik të një titulli me burimin. Përdorimi i një ndryshoreje mjedisi NETRA_HTTP_X_SOURCE_HEADER_NAME Ju mund të specifikoni një emër titulli që do të instalohet automatikisht. Duke përdorur NETRA_HTTP_X_SOURCE_VALUE ju mund të vendosni vlerën në të cilën do të vendoset titulli X-Source për të gjitha kërkesat dalëse.
Kjo lejon që shpërndarja e këtij titulli të dobishëm të shpërndahet në mënyrë uniforme në të gjithë rrjetin. Më pas mund ta përdorni në shërbime dhe ta shtoni në regjistrat dhe metrikat.
Drejtimi i trafikut dhe të brendshmet e Netramesh
Netramesh përbëhet nga dy komponentë kryesorë. E para, netra-init, vendos rregullat e rrjetit për të përgjuar trafikun. Ai perdor për të përgjuar të gjithë ose një pjesë të trafikut në karrocën anësore, e cila është komponenti i dytë kryesor i Netramesh. Ju mund të konfiguroni se cilat porte duhet të përgjohen për seancat TCP hyrëse dhe dalëse: INBOUND_INTERCEPT_PORTS, OUTBOUND_INTERCEPT_PORTS.
Mjeti gjithashtu ka një veçori interesante - rrugëzimin probabilistik. Nëse përdorni Netramesh ekskluzivisht për mbledhjen e hapësirave gjurmuese, atëherë në një mjedis prodhimi mund të kurseni burime dhe të aktivizoni rrugëzimin probabilistik duke përdorur variabla NETRA_INBOUND_PROBABILITY и NETRA_OUTBOUND_PROBABILITY (nga 0 në 1). Vlera e paracaktuar është 1 (i gjithë trafiku kapet).
Pas përgjimit të suksesshëm, netra sidecar pranon lidhjen e re dhe përdor SO_ORIGINAL_DST opsioni i folesë për të marrë destinacionin origjinal. Netra më pas hap një lidhje të re me adresën IP origjinale dhe vendos komunikim TCP të dyanshëm midis palëve, duke dëgjuar të gjithë trafikun që kalon. Nëse porti është përcaktuar si HTTP, Netra përpiqet ta analizojë dhe gjurmojë atë. Nëse analizimi i HTTP dështon, Netra kthehet në TCP dhe në mënyrë transparente kryen proxy bajt.
Ndërtimi i një grafiku varësie
Pasi kam marrë një sasi të madhe informacioni gjurmues në Jaeger, dua të marr një grafik të plotë të ndërveprimeve në sistem. Por nëse sistemi juaj është mjaft i ngarkuar dhe miliarda hapësira gjurmuese grumbullohen në ditë, grumbullimi i tyre nuk bëhet një detyrë aq e lehtë. Ekziston një mënyrë zyrtare për ta bërë këtë: . Megjithatë, do të duhen orë të tëra për të ndërtuar një grafik të plotë dhe do t'ju detyrojë të shkarkoni të gjithë grupin e të dhënave nga Jaeger për XNUMX orët e fundit.
Nëse po përdorni Elasticsearch për të ruajtur hapësirat e gjurmimit, mund ta përdorni , i cili do të ndërtojë të njëjtin grafik në minuta duke përdorur veçoritë dhe aftësitë e Elasticsearch.
Si të përdorni Netramesh
Netra mund të shtohet lehtësisht në çdo shërbim që drejton çdo orkestrator. Ju mund të shihni një shembull .
Për momentin, Netra nuk ka aftësinë për të zbatuar automatikisht karriget anësore të shërbimeve, por ka plane për zbatim.
E ardhmja e Netramesh
qëllimi kryesor është arritja e kostove minimale të burimeve dhe performanca e lartë, duke ofruar aftësi bazë për vëzhgim dhe kontroll të komunikimit ndër-shërbues.
Në të ardhmen, Netramesh do të mbështesë protokolle të tjera të shtresave të aplikacionit përveç HTTP. Rruga L7 do të jetë e disponueshme në të ardhmen e afërt.
Përdorni Netramesh nëse hasni probleme të ngjashme dhe na shkruani me pyetje dhe sugjerime.
Burimi: www.habr.com