Kui liigume monoliitsest rakendusest mikroteenuste arhitektuurile, seisame silmitsi uute väljakutsetega.
Monoliitses rakenduses on tavaliselt üsna lihtne kindlaks teha, millises süsteemiosas viga tekkis. Tõenäoliselt on probleem monoliidi enda koodis või andmebaasis. Kuid kui hakkame mikroteenuse arhitektuuris probleemi otsima, pole kõik enam nii ilmne. Peame leidma kogu tee, mille taotlus algusest lõpuni viis, ja valima selle sadade mikroteenuste hulgast. Pealegi on paljudel neist ka oma laoruumid, mis võivad samuti põhjustada loogikavigu ning probleeme jõudluse ja tõrketaluvusega.
Olen pikka aega otsinud tööriista, mis aitaks selliste probleemidega toime tulla (kirjutasin sellest Habré lehel: , ), kuid lõpuks tegin oma avatud lähtekoodiga lahenduse. Selles artiklis räägin teenindusvõrgu lähenemisviisi eelistest ja jagan uut tööriista selle rakendamiseks.
Hajutatud jälgimine on levinud lahendus hajutatud süsteemides vigade leidmise probleemile. Aga mis siis, kui seda lähenemisviisi võrgu interaktsioonide kohta teabe kogumiseks pole süsteemis veel rakendatud või, mis veelgi hullem, see töötab osa süsteemist juba korralikult, kuid osaliselt mitte, kuna seda pole vanadele teenustele lisatud ? Probleemi täpse algpõhjuse kindlakstegemiseks on vaja süsteemis toimuvast täielikku ülevaadet. Eriti oluline on mõista, millised mikroteenused on seotud võtmetähtsusega ärikriitiliste teedega.
Siin võib meile appi tulla teenindusvõrgu lähenemine, mis tegeleb kõigi võrguteabe kogumise masinatega madalamal tasemel, kui teenused ise töötavad. See lähenemine võimaldab meil kogu liiklust pealt vaadata ja seda käigu pealt analüüsida. Pealegi ei pea rakendused sellest isegi midagi teadma.
Teenindusvõrgu lähenemisviis
Teenindusvõrgu lähenemisviisi põhiidee on lisada võrku veel üks infrastruktuurikiht, mis võimaldab meil teenustevahelise suhtlusega kõike teha. Enamik juurutusi toimib järgmiselt: igale mikroteenusele lisatakse läbipaistva puhverserveriga täiendav külgkorvi konteiner, mille kaudu juhitakse kogu teenuse sissetulev ja väljaminev liiklus. Ja see on just see koht, kus saame teha klientide tasakaalustamist, rakendada turvapoliitikaid, kehtestada päringute arvule piiranguid ja koguda olulist teavet teenuste koostoime kohta tootmises.
Lahendused
Sellel lähenemisviisil on juba mitu rakendust: и . Need pakuvad karbist väljas palju funktsioone. Kuid samal ajal kaasneb sellega suur ülekulu ressurssidele. Veelgi enam, mida suurem on klaster, milles selline süsteem töötab, seda rohkem on uue infrastruktuuri hooldamiseks vaja ressursse. Avitos käitame kubernetese klastreid, mis sisaldavad tuhandeid teenusejuhte (ja nende arv kasvab jätkuvalt kiiresti). Praeguses teostuses tarbib Istio ~300 Mb RAM-i teenuse eksemplari kohta. Tänu võimaluste suurele hulgale mõjutab läbipaistev tasakaalustamine ka teenuste üldist reageerimisaega (kuni 10ms).
Sellest tulenevalt vaatasime täpselt, milliseid võimeid me praegu vajame ja otsustasime, et peamiseks põhjuseks, miks me selliseid lahendusi juurutama hakkasime, oli võimalus koguda kogu süsteemist läbipaistvalt jälgimisinfot. Samuti soovisime omada kontrolli teenuste interaktsiooni üle ja teha erinevaid manipuleerimisi teenuste vahel ülekantavate päistega.
Selle tulemusena jõudsime oma otsusele: .
Netramesh
on kerge teenindusvõrgu lahendus, mida saab skaleerida lõputult, sõltumata teenuste arvust süsteemis.
Uue lahenduse peamised eesmärgid olid madalad ressursikulud ja kõrge jõudlus. Peamiste funktsioonide hulgas soovisime kohe, et saaksime oma Jaegeri süsteemi läbipaistvalt saata jälgimisvahemikke.
Tänapäeval rakendatakse enamus pilvelahendusi Golangis. Ja loomulikult on sellel oma põhjused. Võrgurakenduste kirjutamine Golangis, mis töötavad asünkroonselt I/O-ga ja skaleerivad vastavalt vajadusele üle tuumade, on mugav ja üsna lihtne. Ja mis on samuti väga oluline, jõudlus on selle probleemi lahendamiseks piisav. Seetõttu valisime ka Golangi.
Производительность
Oleme suunanud oma jõupingutused maksimaalse tootlikkuse saavutamisele. Iga teenuse eksemplari kõrval juurutatud lahenduse jaoks on vaja vähe RAM-i ja protsessori aega. Ja loomulikult peaks ka reageerimise viivitus olema väike.
Vaatame, mis tulemused oleme saanud.
RAM
Netramesh tarbib ilma liikluseta ~10 Mb ja maksimaalselt 50 Mb koormusega kuni 10000 XNUMX RPS eksemplari kohta.
Istio envoy puhverserver tarbib meie tuhandete eksemplaridega klastrites alati ~300Mb. See ei võimalda seda kogu klastrile skaleerida.
Netrameshiga saime mälutarbimist ~10x väiksemaks.
Protsessor
Protsessori kasutus on koormuse all suhteliselt võrdne. See sõltub taotluste arvust külgkorvile ajaühiku kohta. Väärtused 3000 päringul sekundis tipphetkel:
On veel üks oluline punkt: Netramesh - lahendus ilma juhttasandita ja ilma koormuseta ei kuluta protsessori aega. Istio puhul värskendavad külgkorvid alati teenuse lõpp-punkte. Selle tulemusel näeme seda pilti ilma koormuseta:
Teenustevaheliseks suhtluseks kasutame HTTP/1. Istio reageerimisaja pikenemine saadiku vahendusel oli kuni 5-10 ms, mis on üsna palju teenuste jaoks, mis on valmis reageerima millisekundiga. Netrameshiga on see aeg vähenenud 0.5-2 ms-ni.
Skaalautuvus
Iga puhverserveri väike ressursside hulk võimaldab selle paigutada iga teenuse kõrvale. Netramesh loodi tahtlikult ilma juhttasandi komponendita, et hoida iga külgkorv lihtsalt kergena. Tihti teenindusvõrgu lahendustes jagab juhttasand igale külgkorvile hoolduse tuvastamise teabe. Sellega kaasneb teave ajalõppude ja tasakaalustamise seadete kohta. Kõik see võimaldab teha palju kasulikke asju, kuid paraku ajab see külgkorvikeste mõõtu.
Teenuse avastamine
Netramesh ei lisa teenuse tuvastamiseks täiendavaid mehhanisme. Kogu liiklus toimub läbipaistvalt läbi netra külgkorvi.
Netramesh toetab HTTP/1 rakendusprotokolli. Selle määratlemiseks kasutatakse konfigureeritavat portide loendit. Tavaliselt on süsteemil mitu porti, mille kaudu toimub HTTP-side. Näiteks teenuste ja väliste päringute vaheliseks suhtluseks kasutame 80, 8890, 8080. Sel juhul saab neid määrata keskkonnamuutuja abil NETRA_HTTP_PORTS.
Kui kasutate Kubernetest orkestreerijana ja selle teenuse olemi mehhanismi teenustevaheliseks klastrisiseseks suhtluseks, jääb mehhanism täpselt samaks. Esiteks hangib mikroteenus kube-dns-i abil teenuse IP-aadressi ja avab sellega uue ühenduse. See ühendus luuakse esmalt kohaliku netra-külgkorviga ja kõik TCP-paketid saabuvad esialgu netrasse. Järgmisena loob netra-külgkorv ühenduse algse sihtkohaga. NAT sõlme IP-l jääb täpselt samaks, mis ilma netrata.
Hajutatud jälgimine ja konteksti edastamine
Netramesh pakub HTTP-interaktsioonide jälgimisvahemike saatmiseks vajalikke funktsioone. Netra-sidecar parsib HTTP-protokolli, mõõdab päringu viivitusi ja eraldab vajaliku teabe HTTP-päistest. Lõppkokkuvõttes saame kõik jäljed ühes Jaegeri süsteemis. Täpse konfiguratsiooni jaoks saate kasutada ka ametliku teegi pakutavaid keskkonnamuutujaid .
Kuid on probleem. Kuni teenused loovad ja saadavad spetsiaalse uber-päise, ei näe me süsteemis ühendatud jälgimisvahemikke. Ja see on see, mida me vajame probleemide põhjuse kiireks leidmiseks. Siin on Netrameshil jälle lahendus. Puhverserverid loevad HTTP päiseid ja genereerivad selle, kui need ei sisalda uberi jälgimise ID-d. Samuti salvestab Netramesh info sissetulevate ja väljaminevate päringute kohta külgkorvis ning sobitab need, rikastades neid vajalike väljuvate päringu päistega. Kõik, mida teenustes tegema pead, on saata ainult üks päis X-Request-Id, mida saab konfigureerida keskkonnamuutuja abil NETRA_HTTP_REQUEST_ID_HEADER_NAME. Konteksti suuruse juhtimiseks Netrameshis saate määrata järgmised keskkonnamuutujad. NETRA_TRACING_CONTEXT_EXPIRATION_MILLISECONDS (aeg, milleks konteksti salvestatakse) ja NETRA_TRACING_CONTEXT_CLEANUP_INTERVAL (konteksti puhastamise sagedus).
Samuti on võimalik oma süsteemis kombineerida mitut teed, märkides need spetsiaalse seansimärgiga. Netra võimaldab teil installida HTTP_HEADER_TAG_MAP HTTP-päiste muutmiseks vastavateks jälgimisvahemiku siltideks. See võib olla testimisel eriti kasulik. Pärast funktsionaalse testi läbimist näete, millist süsteemi osa vastava seansivõtmega filtreerimine mõjutas.
Päringu allika määramine
Et teha kindlaks, kust päring pärineb, saate kasutada päise automaatse allika lisamise funktsiooni. Keskkonnamuutuja kasutamine NETRA_HTTP_X_SOURCE_HEADER_NAME Saate määrata päise nime, mis installitakse automaatselt. Kasutades NETRA_HTTP_X_SOURCE_VALUE saate määrata väärtuse, millele X-Source päis määratakse kõigi väljaminevate päringute jaoks.
See võimaldab selle kasuliku päise levitamist kogu võrgus ühtlaselt jaotada. Seejärel saate seda teenustes kasutada ning logidesse ja mõõdikutesse lisada.
Liikluse suunamine ja Netrameshi sisemised
Netramesh koosneb kahest põhikomponendist. Esimene, netra-init, määrab võrgureeglid liikluse pealtkuulamiseks. Ta kasutab peatada kogu või osa liiklusest külgkorviga, mis on Netrameshi teine põhikomponent. Saate konfigureerida, millised pordid tuleb sissetulevate ja väljaminevate TCP-seansside jaoks kinni pidada. INBOUND_INTERCEPT_PORTS, OUTBOUND_INTERCEPT_PORTS.
Tööriistal on ka huvitav funktsioon – tõenäosuslik marsruutimine. Kui kasutate Netrameshi ainult jälgimisvahemike kogumiseks, saate tootmiskeskkonnas säästa ressursse ja lubada muutujate abil tõenäosuslikku marsruutimist NETRA_INBOUND_PROBABILITY и NETRA_OUTBOUND_PROBABILITY (0 kuni 1). Vaikeväärtus on 1 (kogu liiklus peatatakse).
Pärast edukat pealtkuulamist aktsepteerib netra külgkorv uue ühenduse ja kasutab SO_ORIGINAL_DST pistikupesa valik, et saada algne sihtkoht. Seejärel avab Netra uue ühenduse algse IP-aadressiga ja loob osapoolte vahel kahesuunalise TCP-suhtluse, kuulates kogu läbivat liiklust. Kui port on määratletud kui HTTP, proovib Netra seda sõeluda ja jälgida. Kui HTTP-parsimine ebaõnnestub, naaseb Netra TCP-le ja puhverdab baidid läbipaistvalt.
Sõltuvusgraafiku koostamine
Pärast suure hulga jälgimisteabe saamist Jaegeris tahan saada täieliku süsteemi interaktsioonide graafiku. Kuid kui teie süsteem on üsna koormatud ja päevas koguneb miljardeid jälgimisvahemikke, ei ole nende koondamine nii lihtne ülesanne. Selleks on ametlik viis: . Täieliku graafiku koostamine võtab aga tunde ja sunnib teid viimase XNUMX tunni jooksul kogu andmestikku Jaegerist alla laadima.
Kui kasutate jälgimisvahemike salvestamiseks Elasticsearchi, saate kasutada , mis koostab sama graafiku mõne minutiga, kasutades Elasticsearchi funktsioone ja võimalusi.
Kuidas Netrameshi kasutada
Netra saab hõlpsasti lisada mis tahes teenusele, mis töötab mis tahes orkestraatoriga. Näete näidet .
Hetkel puudub Netral võimalus külgkorve automaatselt teenustesse juurutada, kuid plaanid on olemas.
Netrameshi tulevik
peamine eesmärk eesmärk on saavutada minimaalsed ressursikulud ja kõrge jõudlus, pakkudes põhilised võimalused talitustevahelise suhtluse jälgimiseks ja juhtimiseks.
Tulevikus toetab Netramesh peale HTTP ka muid rakenduskihi protokolle. L7 marsruutimine on saadaval lähitulevikus.
Sarnaste probleemide korral kasutage Netrameshi ja kirjutage meile küsimuste ja soovitustega.
Allikas: www.habr.com